> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/automation/testing-preflight-and-repair.md).

# 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.

![Readiness and repair screen.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/C2pKJlnbPbSyj51ASGn9/assets/automation-wizard-e2e/13-readiness-and-repair-destination.png)

*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

| Check                       | Why it matters                                                 |
| --------------------------- | -------------------------------------------------------------- |
| 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:

1. Open the app in the builder.
2. Open the screen where the normal user starts the process.
3. Preview as the normal user, not as the owner.
4. Create or choose one realistic record.
5. Start the process with the real button, form, status change, launcher, or webhook.
6. Confirm the user sees an immediate result, such as Submitted, Waiting for review, Message sent, Routed, or Needs attention.
7. Switch preview to the recipient role.
8. Open the correct user-facing automation screen.
9. Confirm the item appears without editing hidden backend data.
10. Open the item and make sure the recipient can understand what to do.
11. Complete the action: approve, reject, reply, claim, retry, acknowledge, or complete.
12. Return to the source record and confirm the status, message, or activity changed.
13. Run validation again before publishing.
14. 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:

    1. **Generate** the route from the wizard or builder.
    2. **Save** the generated setup.
    3. **Preview** the route explanation in plain language.
    4. **Run preflight** to check generated objects, access, screen bindings, channels, and workflow state.
    5. **Repair setup** if the builder reports missing generated pieces.
    6. **Test as a real persona** from the app, not only from the builder.
    7. **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:

    1. **Generate** the route from the wizard or builder.
    2. **Save** the generated setup.
    3. **Preview** the route explanation in plain language.
    4. **Run preflight** to check generated objects, access, screen bindings, channels, and workflow state.
    5. **Repair setup** if the builder reports missing generated pieces.
    6. **Test as a real persona** from the app, not only from the builder.
    7. **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:

1. **Generate** the route from the wizard or builder.
2. **Save** the generated setup.
3. **Preview** the route explanation in plain language.
4. **Run preflight** to check generated objects, access, screen bindings, channels, and workflow state.
5. **Repair setup** if the builder reports missing generated pieces.
6. **Test as a real persona** from the app, not only from the builder.
7. **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.