---
title: Deletions, Trashing and Edge Cases
description: "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 | | --- | --- | --- |…"
url: "https://brightleafdigital.io/docs/deletions-trashing-and-edge-cases/"
updated: "2026-10-18"
category: "Recurring Form Submissions for Gravity Forms / Explanations & Concepts"
---

# Deletions, Trashing and Edge Cases

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.