View Categories

Lifecycle, Scheduling, Deletion & Edge Cases

Table of Contents

This set of explanations provides the mental model behind Recurring Form Submissions for Gravity Forms. It covers how a series progresses, how time and catch‑up work, what happens on deletes/deactivations, how data persists, and which practical limitations to expect.

Series Lifecycle (Conceptual) #

  • Start: A form submission occurs on a form with an active Recurring Submissions feed. The feed evaluates conditional logic on the parent submission only. If conditions pass, a series is created for that entry.
  • Cadence: The series defines a cadence (every N days/weeks/months/years) plus an end condition (resubmission count or end date).
  • Run: On eligible days, the plugin generates a new child entry (a normal GF submission), runs all enabled feeds/notifications for that form, and logs the outcome.
  • Track: Parent/child entries maintain bi‑directional links and notes. The series accumulates progress until the end condition is met or the series is canceled.
  • Complete: When the final resubmission succeeds, the series is marked complete.

Scheduling, Time Storage & Catch‑Up #

  • Time model: All times are stored in UTC and displayed in the site’s configured time zone.
  • Daily scan: The plugin’s daily process looks for series with occurrences due that day or earlier.
  • Missed days: If the site was down or cron didn’t run, missed occurrences are picked up on the next run.
  • Manual run semantics: Manually processing the next submission does not change the long‑term cadence; the following occurrence remains scheduled relative to its original plan.

Deletion, Deactivation & Uninstall #

  • Delete vs. Trash:
    • If the source entry or form is deleted permanently (not just trashed), the series stops.
    • If either is trashed, nothing changes; the series continues.
  • Feed deactivation: If the feed is deactivated after a series has started, that series continues and must be manually canceled if you want it to stop.
  • Feed deletion: Deleting the feed cancels any active series associated with that feed.
  • Plugin deactivation: While deactivated, no submissions are processed. Upon reactivation, overdue occurrences are picked up on the first run (data remains intact in the database).
  • Plugin uninstall: Removes plugin data and tables; the system is cleaned as if the plugin was never installed (aside from the entries it created!).

Data Model & Persistence #

  • Storage: Series and state are stored in custom database tables managed by the plugin.
  • Parent/Child linkage: Parent entries record series metadata; each child is linked back to its parent. Links are visible via entry notes and used internally for auditing and progress computation.
  • Form duplication: Duplicating a form duplicates feeds but not existing series. New series begin only on new submissions that meet the feed’s conditions.

Custom Entry Meta Fields #

The plugin exposes the following entry meta fields for search, filtering, and merge tags.

Parent Entries #

  1. rfsfgf_is_parent_submission Label: Is Parent Submission Values: 'true' or 'false' Filterable: is, isnot
  2. total_resubmissions Label: Total Resubmissions Type: Numeric Filterable: is, isnot, >, <, contains

Child / Auto‑submitted Entries #

  1. is_auto_submission Label: Is Auto Submission Values: 'true' or 'false' Filterable: is, isnot
  2. resubmission_progress Label: Resubmissions Progress Format: e.g., 3 of 10 or 5 until Dec 31, 2025 Filterable: is, isnot, contains

Both Parent and Child #

  1. rfsfgf_feed_label Label: Feed Label Behavior: Entry‑specific; supports merge tags Filterable: is, isnot, contains

Availability:

  • Searchable/filterable in the Gravity Forms entry list
  • Usable via custom merge tags in notifications/confirmations
  • Accessible via GFAPI and GF entry‑meta functions or our GravityOps Search plugin
  • Optional columns in the entry list view

Interaction With Gravity Forms Features (Concepts) #

  • Conditional Logic: Evaluated on the parent submission only to determine whether a series starts.
  • Calculation Fields: Recomputed on each submission.
  • Unique ID & GPPA: Unique ID fields produce a new unique value per resubmission; GPPA re‑hydrates in dynamic mode; Snapshot mode copies stored values, but Unique ID still remains unique for resubmissions.
  • Notifications & Feeds: Each resubmission is a normal GF submission, so all active feeds/notifications execute accordingly.

Limitations & Edge Cases #

  • No pause state: Series can be canceled, not paused.
  • Manual next run: Manually processing a run does not shift the schedule anchor; the next occurrence follows the original cadence.
  • No backfills: The system never creates retroactive runs for dates in the past.
  • Feed edits: When a series starts, it takes a snapshot of the feed’s configuration (cadence, limits, etc.) and stores it in the series record. Subsequent edits to the feed settings do not retroactively affect active series. Only new series created after the edit will use the new settings.
  • Snapshot vs. Dynamic Inputs:
    • If Snapshot Entry Inputs Now is enabled, the plugin stores a fixed copy of all entry values at the moment the series starts. Every future resubmission will use these exact values.
    • If Snapshot Entry Inputs Now is disabled, the plugin reads the current values from the parent entry in the database at the moment of each resubmission. This allows you to update the parent entry to change values for future runs in that series.
  • Parent deletion impact: Deleting the parent stops the series and leaves child entries intact for audit history.
  • Validation failures: A failed resubmission does not create an entry; failure is logged. The behavior of the series then depends on its limit type:
    • Number-based limits: A failure does not increment the total_resubmissions count. The series will reschedule the attempt for the next interval and continue until the required number of successful (or skipped by conditional logic) resubmissions is reached. This effectively “retries” the failed slot at the next scheduled time.
    • Date-based limits: A failure does not increment the count, but the end date remains fixed. The series will be deleted once the end date is reached, regardless of whether any scheduled runs failed.

Design Rationale (Why It Works This Way) #

  • Reliability first: Using a daily scan with catch‑up ensures missed days (downtime, cron hiccups) are accounted for on the next run.
  • Auditability: Parent/child linkage, entry notes, and explicit failure states guarantee traceability across the series lifecycle.
  • Operational safety: Deactivation preserves data and catches up later; uninstall removes all traces for clean hand‑offs.
What are your Feelings