1. Form Builder Platform
  2. Features
  3. Execution history
Feature · Execution history

Execution history

Trace what happened to an approved action.

OverviewFailed operation runs
Form Builder Platform · Execution history

Failed operation runs

Operation runs

New
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
Example screen with sample data

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.

How to get started