> 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/publish-readiness-checklist.md).

# Publish Readiness Checklist

## Publish Readiness Checklist

Use this checklist before publishing an automation app, live demo, or template.

![Validation ready state.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/J4yDDbTlZPwWWYg09Of3/assets/approval-management/maker-builder/04-procurement-approval-desk-validation-ready.jpg)

*Validation should be clean before publish.*

### Required checks

| Area             | Pass condition                                                                        |
| ---------------- | ------------------------------------------------------------------------------------- |
| Trigger          | The workflow starts from the exact user action.                                       |
| Source record    | Test data is realistic and visible to the correct roles.                              |
| Recipient        | Recipient resolves through role, team, owner, requester, reviewer, or selected field. |
| Destination      | The correct native screen receives the work or message.                               |
| Messages         | Messages use plain business language and link to the work.                            |
| Permissions      | Requester and recipient roles have exactly the access they need.                      |
| Status           | Source record or Workflow Status shows progress.                                      |
| Decision actions | Approve, reject, request changes, or complete actions update the record.              |
| Exceptions       | Missing data, missing recipient, failed message, and failed handoff are visible.      |
| Live test        | A fresh test request appears and can be completed without backend edits.              |

### Publish blockers

Do not publish when:

* Validation says the submit button is not connected.
* A recipient cannot be resolved.
* The destination screen is missing.
* The reviewer can only see the item as app owner.
* The requester cannot see the final result.
* A repair was run but no fresh live test followed it.
* A failure requires backend inspection to understand.

### Final sign-off

A maker should be able to say: I tested this as the requester and the recipient. I know what starts the workflow, where the item appears, who can act, what message is sent, what status changes, and where failures appear.