---
title: "Put Recurring Controls on a Front-End Page"
description: "**Goal:** let a team operate schedules without sending them into the WordPress admin. **Before you start:** both shortcodes are administrative views. They render **only** for users holding `recurring_form_submissions_manage_resubmissions`, and output nothing at all for anyone else. --- ## Option 1…"
url: "https://brightleafdigital.io/docs/put-recurring-controls-on-a-front-end-page/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / How To Guides Recurring Form Submissions For Gravity Forms
---

# Put Recurring Controls on a Front-End Page

**Goal:** let a team operate schedules without sending them into the WordPress admin.

**Before you start:** both shortcodes are administrative views. They render **only** for users holding `recurring_form_submissions_manage_resubmissions`, and output nothing at all for anyone else.

---

## Option 1 — A Read-Only Dashboard

One page, one shortcode:

```
[rfsfgf_overview]
```

Columns: Entry, Form, Feed Name, Feed Label, Next Submission, Progress, Status.

Narrow it with the `status` attribute:

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

`active` (the default) lists everything except completed and canceled. Because completed and canceled series are **retained** for the history window, `all` lists more than it used to — ask for the status you actually want.

This table requires the Premium plan or higher.

---

## Option 2 — Controls for One Entry

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

This renders the same cards as the entry page, with:

- **Run Next Submission Now**
- **Retry Failed Submission**
- **Start Series From Now**
- **Cancel Series** *(Premium plan)*

Pause, Resume, Change next submission, attempt history and diagnostics deliberately stay in Queue.

---

## Option 3 — A List-and-Detail Pattern

The useful combination: one page that lists series, and one that operates a chosen entry.

### The list page

Add `[rfsfgf_overview]`, or build your own list (a GravityView view works well), and link each row to your detail page with the entry ID:

```
https://example.com/schedules/detail/?rfsfgf_entry=345
```

### The detail page

```
[rfsfgf_entry_widget entry_id="current"]
```

`current` reads the entry from the request, checking `rfsfgf_entry` first, then `lid`, then `entry_id`.

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

---

## Behaviour on the Front End

| Aspect | 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 the same page with its result notice — never a redirect into the dashboard. |
| **Security** | Operational requests go through the same capability-checked and nonce-checked handler as the dashboard. No new endpoint is added. |
| **Mismatched `form_id`** | Renders nothing, rather than another form's feeds. |

---

## Access Control

### The default

No management capability → nothing renders. That's the whole widget, not just the buttons.

### Granting access to a team

Give the role the `recurring_form_submissions_manage_resubmissions` capability with your role editor. Those users then get both the view **and** the actions.

### Letting someone view only their own

Use `rfsfgf_shortcode_can_view` to widen the **read** without widening the **write**:

```
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 );
```

The buttons and the handler behind them still require the management capability, so a user you let *see* a card cannot submit from it.

> Scope any widening tightly. Returning a bare `true` shows every user every series' entry, form, feed and failure state.

### Page-level protection

Still worth applying — a members-only page, a password, a restricted menu. It is no longer the only thing protecting the data, but it's a sensible second layer.

---

## A Sensible Setup

| Page | Who can reach it | Contents |
| --- | --- | --- |
| **Schedules** | Operations team | `[rfsfgf_overview]` |
| **Schedule detail** | Operations team | `[rfsfgf_entry_widget entry_id="current"]` |
| **Needs attention** | Operations team | `[rfsfgf_overview status="failed"]` |

Keep Queue as the place for schedule editing and forensics. The front-end pages are for the routine day-to-day.