🧪Testing, Preflight, and Repair
Testing, Preflight, and Repair
Testing, Preflight, and Repair
Testing proves the workflow works from the user interface. Preflight checks whether the app is safe to publish or demo. Repair reconnects generated pieces when validation finds something missing or disconnected.
Run readiness before publishing customer apps, demos, and templates.
The rule
Do not publish an automation because the setup looks complete. Publish it because the visible user journey works.
That means:
The requester can start it.
The recipient can see it.
The action can be completed.
The requester can see the result.
Validation has no blockers.
Exceptions are visible and explain the next step.
What preflight should check
Submit button connected
Prevents the most common broken approval demo.
Trigger matches user action
Prevents workflows that only work after manual database edits.
Destination screen exists
Prevents hidden workflow runs.
Recipient resolves
Prevents requests going nowhere.
Permissions match roles
Prevents owner-only demos.
Messages route correctly
Prevents users from missing work.
Decision actions are mapped
Prevents reviewer buttons that do nothing.
Exception path exists
Prevents silent failures.
Test request appears
Proves the user-facing path.
When to use repair
Use Repair setup when validation says a generated piece is missing or disconnected. Examples: missing Decision screen, missing Work Queue binding, missing message route, missing exception screen, or disconnected test request action.
Do not use repair to avoid choosing business rules. A maker still needs to choose the trigger, recipient, status values, destination screen, and message language.
The standard automation test
Use this same test whenever you build, change, repair, or publish an automation:
Open the app in the builder.
Open the screen where the normal user starts the process.
Preview as the normal user, not as the owner.
Create or choose one realistic record.
Start the process with the real button, form, status change, launcher, or webhook.
Confirm the user sees an immediate result, such as Submitted, Waiting for review, Message sent, Routed, or Needs attention.
Switch preview to the recipient role.
Open the correct user-facing automation screen.
Confirm the item appears without editing hidden backend data.
Open the item and make sure the recipient can understand what to do.
Complete the action: approve, reject, reply, claim, retry, acknowledge, or complete.
Return to the source record and confirm the status, message, or activity changed.
Run validation again before publishing.
Open Exception Resolution and confirm there are no unexpected failures.Current proof loop
The newest Automation experience makes testing more guided. The builder should not leave a maker wondering whether a route is complete. It should show the next proof step.
Use this loop before publishing:
Generate the route from the wizard or builder.
Save the generated setup.
Preview the route explanation in plain language.
Run preflight to check generated objects, access, screen bindings, channels, and workflow state.
Repair setup if the builder reports missing generated pieces.
Test as a real persona from the app, not only from the builder.
Check Activity for the workflow run, message delivery, approval decision, or exception.
If a check fails, use the suggested action closest to the failure. For example, use Fix setup when generated objects are missing, Fix access when an entitlement or permission is missing, and Run preview when the maker needs to verify the route before publishing.
Preflight is not a replacement for testing. It is a readiness gate that helps the maker find broken setup before an end user does.Current proof loop
The newest Automation experience makes testing more guided. The builder should not leave a maker wondering whether a route is complete. It should show the next proof step.
Use this loop before publishing:
Generate the route from the wizard or builder.
Save the generated setup.
Preview the route explanation in plain language.
Run preflight to check generated objects, access, screen bindings, channels, and workflow state.
Repair setup if the builder reports missing generated pieces.
Test as a real persona from the app, not only from the builder.
Check Activity for the workflow run, message delivery, approval decision, or exception.
If a check fails, use the suggested action closest to the failure. For example, use Fix setup when generated objects are missing, Fix access when an entitlement or permission is missing, and Run preview when the maker needs to verify the route before publishing.
Preflight is not a replacement for testing. It is a readiness gate that helps the maker find broken setup before an end user does.
Current proof loop
The newest Automation experience makes testing more guided. The builder should not leave a maker wondering whether a route is complete. It should show the next proof step.
Use this loop before publishing:
Generate the route from the wizard or builder.
Save the generated setup.
Preview the route explanation in plain language.
Run preflight to check generated objects, access, screen bindings, channels, and workflow state.
Repair setup if the builder reports missing generated pieces.
Test as a real persona from the app, not only from the builder.
Check Activity for the workflow run, message delivery, approval decision, or exception.
If a check fails, use the suggested action closest to the failure. For example, use Fix setup when generated objects are missing, Fix access when an entitlement or permission is missing, and Run preview when the maker needs to verify the route before publishing.
Preflight is not a replacement for testing. It is a readiness gate that helps the maker find broken setup before an end user does.
Last updated