A form submission can succeed while a later AI-powered action fails. The entry may be safely stored, but the summary, classification, quality check, or routing step did not finish as expected.
That distinction matters. If staff treat every action failure as a lost submission, they may ask the visitor to submit again, create duplicates, or repeat a downstream side effect. A better recovery process starts with the record you already have and gives the unresolved work a human owner.
Identify which part failed
| What you observe | Likely operating state | First question |
|---|---|---|
| No source submission exists | The form intake itself may have failed | Can the visitor path be reproduced safely? |
| The source submission exists, but no action result appears | The later action may not have started or completed | Is there a Sentient Forms action record to inspect? |
| An action result exists, but a later business step is missing | The action may have completed while a downstream side effect failed | Would repeating the whole workflow duplicate anything? |
| The result exists but is unusable | The action completed technically but missed the acceptance rule | Can a human finish the case without another model request? |
This article begins with the second, third, or fourth row: the visitor’s submission exists. If intake itself is unavailable, use the separate WordPress form outage recovery plan.
Preserve the source record first
Open the original entry or submission record before changing settings. Capture its identifier, submission time, form, expected action, and the visible action state. Do not copy more visitor data than the recovery owner needs.
The exact screen depends on the Form Source. Gravity Forms has the deepest native entry integration. Other supported sources can use the Sentient Forms Submission Ledger as the common review surface. In either case, the recovery record should point back to the source submission rather than becoming an unattached screenshot or chat message.
Give the exception an owner and deadline
A failed action is unfinished customer work, not just a technical alert. Assign a person who can decide whether to complete the task manually, retry a bounded step, or escalate the underlying configuration problem. Add a deadline based on the submission’s business value, not the convenience of the technical team.
- Owner: one named person or active queue.
- Deadline: the latest useful time for follow-up.
- Manual fallback: the smallest safe way to finish the case.
- Escalation: who investigates repeated failures.
- Closure note: what was done and whether any automated step was repeated.
Classify the failure before changing anything
Use a small set of operational categories. The goal is not to guess at internals; it is to choose a safe next action.
- Configuration: a credential, model, mapping, or required setting is missing or no longer valid.
- Input: the submission lacks enough usable information or contains an unexpected format.
- Temporary provider condition: the request did not complete and may succeed later, but the evidence does not yet justify a blind retry.
- Output acceptance: a response exists but does not meet the written business rule.
- Downstream side effect: the AI result exists, but a later notification, webhook, or handoff may not have completed.
If the same category appears repeatedly, move it into a regular exception review rather than treating each case as unrelated. The weekly WordPress form exception report gives a lightweight structure for that review.
Decide whether a retry is safe
Do not retry merely because a button or request is available. First determine whether any part of the action already produced an external effect. A repeated summary is usually different from a repeated email, CRM update, webhook, or status change.
- Confirm the source submission exists and will not be recreated.
- Check for an existing action result or partial downstream effect.
- Correct only the setting or input that caused the exception.
- Choose the smallest step that needs to run again.
- Record who authorized the retry and what outcome appeared.
If duplicate intake is already part of the problem, use the duplicate WordPress form submission guide before repeating any workflow. Sentient Forms does not make every external side effect automatically safe to repeat; that decision belongs to the operation you configured.
Record the resolution where reviewers can find it
Close the loop with a compact record: source submission ID, failed action, observed state, classification, manual work, retry decision, final outcome, owner, and completion time. Keep sensitive form data in its governed system instead of duplicating it in the exception note.
A reviewable history helps an agency distinguish an isolated provider interruption from a recurring mapping or acceptance problem. It also gives the next person evidence instead of a vague “AI failed” message. See the AI form review and audit-trail guide for a practical pattern.
Test the recovery path before you need it
Use a synthetic submission that contains no real customer data. Confirm that staff can find the source record, identify the action state, assign the exception, complete the manual fallback, and document the result. If a retry is part of the plan, use a test action whose downstream effect cannot contact a customer or alter a live business record.
The test is successful when a new team member can follow the record and finish the case without asking where the submission went. That is a stronger recovery measure than a green status screen alone.
Not automatically. First confirm whether the original submission was stored. If it exists, recover from that record so you do not create duplicate submissions or repeat downstream effects.
Only after you check whether the action or any later step already produced an effect. Correct the known cause, repeat the smallest necessary step, and record the outcome. External emails, webhooks, CRM updates, and status changes need particular care.
Record the source submission ID, expected action, observed state, failure category, owner, deadline, manual work, retry decision, final outcome, and completion time. Avoid copying sensitive form data into the exception note.
Turn the next exception into owned work
Pick one important form and write down where its source submissions live, who owns failed actions, which side effects must never be repeated blindly, and how a reviewer closes the record. Then test the handoff with a synthetic entry.
