What happens to a schedule when the things it depends on go away — and what survives.
The Quick Table #
| Event | Effect on the series | Child entries |
|---|---|---|
| Parent trashed | All unfinished series canceled immediately — including paused and processing | Kept |
| Parent permanently deleted | Same | Kept |
| Parent restored | Series are not restarted | Kept |
| Child trashed or deleted | No effect. Progress is not decremented | — |
| Feed deactivated | Scheduled series paused as feed_inactive |
Kept |
| Feed reactivated | Only feed_inactive series resume |
Kept |
| Feed deleted | Its series end | Kept |
| Form trashed | Submission is prevented | Kept |
| Plugin deactivated | Operational data preserved; nothing runs | Kept |
| Plugin reactivated | May process one overdue occurrence | Kept |
| Plugin uninstalled | Plugin-owned tables, cron events, options and dismissals removed | Kept |
Parent Entries #
Trashing or deleting #
Trashing or permanently deleting a parent immediately cancels every unfinished series belonging to it, including paused and processing ones.
A submission already in flight may still finish. Its child entry and attempt record remain; cancellation prevents future scheduling, not work already under way.
Restoring #
Restoring a parent never restarts its series automatically.
That’s deliberate. An accidental restore — or a routine trash-and-restore during cleanup — must not silently resume automated submissions. Use Start Series From Now when you actually want it back.
Permanent deletion and notes #
Permanently deleting an entry removes that entry’s native Gravity Forms notes. Retained operational attempts and other child entries are untouched.
Child Entries #
Children are ordinary Gravity Forms entries. Deleting or trashing one:
- does not cancel the parent’s series,
- does not decrement the successful progress count.
Progress counts submissions that succeeded, not entries that currently exist. If you delete a child, the series still regards that occurrence as done.
Feeds #
| Action | Result |
|---|---|
| Deactivate | Scheduled series are paused with reason feed_inactive. A claimed series is stopped at the final active-feed guard before it can submit. |
| Reactivate | Only feed_inactive series resume. User-paused and failed series do not. |
| Delete | Its series end. There is no undo. |
Both the native Gravity Forms toggle and the GravityOps Feeds tab use the same public lifecycle, so there’s no divergent second path.
Feed lifecycle changes are recorded in the add-on log — which is otherwise the only place attempts stop with no visible action in Queue.
Forms #
A missing, trashed or inactive parent, form or feed prevents submission.
A series whose required parent or feed no longer exists moves to completed, retaining its attempts and child-entry audit links.
Plugin Deactivation and Uninstall #
Deactivation #
Operational data is preserved. Nothing runs while the plugin is inactive.
On reactivation, an eligible overdue series can process one occurrence — subject to its missed-run policy. Reactivation never replays an outage.
Uninstall #
Uninstall removes what the plugin owns:
- its series and attempt tables,
- its cron events,
- worker health, issue and migration options,
- per-user notice dismissal metadata.
Child entries remain. They are Gravity Forms entries, not plugin data.
Storage Failures: the Ambiguous Case #
A storage failure is not a rejected submission. It means a child entry may have been created before its operational records could be saved.
The plugin refuses to guess:
| Behaviour | Reason |
|---|---|
| Reports the known child entry ID | So you can check whether the submission really happened |
| Blocks further submissions | So a blind retry can’t create a duplicate |
| Keeps Cancel available | Cancelling never deletes children |
| Labels older unfinished attempts as requiring review | They are not proof that nothing was submitted |
Repairing the database schema does not clear this. A blocked series stays blocked until someone reviews the existing children and attempts.
Locks #
If a series is locked, another request may be processing it.
- Don’t click Run repeatedly. The interface reports a lock rather than pretending to queue work.
- Claims older than 30 minutes can be recovered.
- Before retrying an uncertain result, inspect child entries and interrupted attempt records.
Concurrency #
Every claim is atomic and per-request, so the same occurrence cannot be submitted twice by two overlapping requests.
When you apply a saved feed schedule in bulk, locked or concurrently changed series are skipped and reported rather than forced — you’ll see exactly which ones didn’t take.
