Publish Readiness Checklist
Publish Readiness Checklist
Section titled “Publish Readiness Checklist”Use this checklist before publishing an automation app, live demo, or template.
Validation should be clean before publish.
Required checks
Section titled “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
Section titled “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
Section titled “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.