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: Changes to feed settings affect future occurrences only.
  • 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; payment (or other) feeds do not run; failure is logged and must be retried or marked fixed before the series can be considered complete.

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