---
title: Shortcodes
description: "Two shortcodes place recurring-submission surfaces on a front-end page. | Shortcode | Renders | | --- | --- | | `[rfsfgf_overview]` | A read-only table of series. | | `[rfsfgf_entry_widget]` | The entry cards, with a subset of their controls.…"
url: "https://brightleafdigital.io/docs/shortcodes/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Settings Reference
---

# Shortcodes

Two shortcodes place recurring-submission surfaces on a front-end page.

| Shortcode | Renders |
| --- | --- |
| `[rfsfgf_overview]` | A read-only table of series. |
| `[rfsfgf_entry_widget]` | The entry cards, with a subset of their controls. |

---

## Read This First: They Are Administrative Views

Both shortcodes render **only** for a user holding `recurring_form_submissions_manage_resubmissions`.

For anyone else — signed out, or signed in without the capability — they output **nothing at all**. Not a stripped-down version, not a table without buttons. Nothing.

That means a series' entry, form, feed and failure state are never exposed by the page's own access controls alone.

> Page-level access control is still worth applying on top. It is simply no longer the only thing standing between a visitor and your series data.

Neither shortcode adds a new schedule-management endpoint: operational requests go through the same capability-checked and nonce-checked handler as the dashboard.

---

## `[rfsfgf_overview]`

A summary table of series.

```
[rfsfgf_overview]
[rfsfgf_overview status="failed"]
```

### Columns

| Column | Contents |
| --- | --- |
| **Entry** | The parent entry. |
| **Form** | The form it belongs to. |
| **Feed Name** | The feed's name. |
| **Feed Label** | The feed's label, with merge tags resolved. |
| **Next Submission** | Date, time and timezone of the next target. |
| **Progress** | `3 of 12` against a counted limit, or `3 successful submissions` without one. |
| **Status** | The lifecycle state. |

### Attributes

| Attribute | Default | Notes |
| --- | --- | --- |
| `status` | `active` | `active` lists everything except completed and canceled. `all` lists every series still inside the retention window. Or name one exact status: `scheduled`, `processing`, `paused`, `failed`, `completed`, `canceled`. |

> Because completed and canceled series are **retained** for the history window, `status="all"` lists more than you might expect. Ask for the status you actually want.

This is a read-only summary, not the Queue editor. It offers no actions.

### Plan requirement

The overview table requires the Premium plan or higher. On a lower plan it renders an upgrade message in place of the table.

---

## `[rfsfgf_entry_widget]`

Renders the recurring cards for **one** parent entry, with working controls.

```
[rfsfgf_entry_widget form_id="12" entry_id="345"]
[rfsfgf_entry_widget entry_id="current"]
```

### Attributes

| Attribute | Default | Notes |
| --- | --- | --- |
| `entry_id` | *(required)* | The parent entry to show. `entry_id="current"` reads it from the request — `rfsfgf_entry` first, then `lid`, then `entry_id`. |
| `form_id` | The entry's own form | Optional. A value that disagrees with the entry's form renders nothing, rather than another form's feeds. |

### Available actions

| In the widget | Stays in Queue |
| --- | --- |
| Run Next Submission Now | Pause |
| Retry Failed Submission | Resume |
| Cancel Series *(Premium plan)* | Change next submission |
| Start Series From Now | Attempt history |
|  | Copy Diagnostics |

The split is deliberate: routine per-entry operations belong wherever your team works, while schedule editing and forensics belong on the operations screen.

### Behaviour

- Actions use AJAX and refresh the cards **in place**, on the page they were performed on.
- Without JavaScript, the ordinary form submission returns to that same page with its result notice rather than redirecting into the dashboard.

---

## A List-and-Detail Pattern

`entry_id="current"` exists so one page can serve a whole list.

1. Build a list of parent entries — a GravityView view, a loop, whatever you prefer.
2. Link each row to a detail page with `?rfsfgf_entry=123`.
3. Put `[rfsfgf_entry_widget entry_id="current"]` on that detail page.

`rfsfgf_entry` is the unambiguous argument; `lid` is supported because that's what Gravity Forms uses on its own entry screens.

---

## Widening or Narrowing Access

`rfsfgf_shortcode_can_view` filters the decision **before anything is rendered**.

It receives:

1. the capability check's result,
2. the context — `overview` or `entry_widget`,
3. for the entry widget, an array holding the `entry` and `form`.

Returning `true` for a user without the management capability shows them series state, so scope any widening to the entries that user should actually see:

```
add_filter( 'rfsfgf_shortcode_can_view', function ( $can_view, $context, $args ) {
    if ( 'entry_widget' === $context && ! $can_view ) {
        return get_current_user_id() && (int) rgar( $args['entry'], 'created_by' ) === get_current_user_id();
    }
    return $can_view;
}, 10, 3 );
```

> **Widening the read does not widen the write.** The action buttons, and the request handler behind them, still require the management capability. A user you let *see* a card cannot use it to submit anything.