Lifecycle, Scheduling, Deletion & Edge Cases

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 #

3. is_auto_submission
   Label: Is Auto Submission
   Values: 'true' or 'false'
   Filterable: is, isnot
4. 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 #

5. 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.