These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Form Builder Platform
- Features
- Execution history
Execution history
Trace what happened to an approved action.
OverviewFailed operation runs×
Form Builder Platform · Execution history
New
Failed operation runs
Operation runs
Failed3
OK-887FD-61474
480
OK-592FD-23814
470
OK-609FD-99449
830
Add
Reconciliation required3
OK-594FD-53545
770
OK-502FD-81001
380
OK-249FD-89021
150
Add
What you can do
Trace what happened to an approved action
Operation Runs identify an action by operation key, source revision, start and completion time, status and input hash. Numbered Operation Steps record the action name, input and output references, external receipt and status. Execution Attempts preserve attempts against a form revision and operation key, including provider reference and failure reason. State History records the transition, actor, source revision and reason.
The run and its numbered steps explain which source revision an action used and whether it succeeded. Attempts record repeated execution against an operation key. A failed or uncertain attempt calls for an inspection of its reference and reason before anyone tries the action again.
How the work is organized
- Identify the operation. Start with the source form, revision and operation key.
- Inspect each step. Follow numbered inputs, outputs, status and any external receipt.
- Resolve uncertainty. Compare attempts and state history before recording another action.
What to agree during setup
The Operator agrees how to identify a repeated request and who investigates a failed or uncertain result. A run marked reconciliation required calls for checking the recorded steps and any external receipt before taking another action. A failed attempt and its reason are evidence for diagnosis; they should not be mistaken for a completed publication or accepted submission.
Agree how the Operator distinguishes a retry from a new action. A run marked reconciliation required needs a check of its steps and receipts. Keep the source revision on the run so the team can trace which definition was published, accepted or superseded.
Check the handoff on an actual case
Publish a validated form in a rehearsal and inspect the resulting run, its numbered steps and the state transition. Next, inspect a failed attempt and confirm that the source revision and operation key identify the affected action. For a documented correction, keep the prior run visible and compare it with the successor Draft revision.
Compare the publish run with its state transition and the later correction run. The correction leaves the earlier run in place and starts a successor Draft. For a failed attempt, inspect its reason and provider reference before retrying.
What your team sees
- Failed operation runs — Inspect Failed and reconciliation required runs by source revision and reason.
- Execution attempt queue — Follow Queued, Running and Unknown attempts by operation key.
Follow the work through
See definition and publication and submission review for the decisions that connect this module to the next one.
What it keeps track of
Data model- Operation runs
- Immutable operation run record per source and approved action revision.
- Operation steps
- Numbered step trace within an operation run with persisted input/output identities.
- Execution attempts
- Every execution attempt against a form definition revision and operation key.
- State history
- Immutable state transitions recorded for each form definition revision.
- Form definitions
- Versioned published form schemas with conditional logic and validation rules.
Who uses it
Permissions- Operator
- Inspects runs and attempts.
- Form Owner
- Checks the affected revision; Admin maintains access.
Set up Form Builder Platform your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.