> 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/builder-controls-visual-guide.md). # Builder Controls Visual Guide ## Builder Controls Visual Guide This page explains the automation builder controls in plain language. Use it when you are asking, Where do I click, what does this control mean, and how do I know it worked? ![Automation Home wizard catalog.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/DxhQc0b6wKhbev9QV4Ax/assets/automation-wizard-e2e/00-automation-home-wizard-catalog.png) *Automation Home is the starting point for guided setup.* ### Automation Home | Control or area | What it means | How to use it | | ----------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Wizard card | A guided path for a business outcome. | Choose the card that describes what the user wants to happen. | | What NotionApps handles | The generated or connected pieces. | Read this so you know whether the wizard creates workflow routes, messages, screens, approval items, or exceptions. | | Setup steps | The expected build sequence. | Use it as your checklist before saving. | | Start button | Opens the selected wizard. | Click after you know the trigger, recipient, and destination. | ### Approval setup controls ![Approval workflow setup screen.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/kPhC9GrOLlzI30v2hkd5/assets/approval-management/maker-builder/03-procurement-approval-desk-approval-workflow-setup.jpg) *This screen connects the real trigger, recipient, destination, messages, validation, repair, and test path.* | Control | Plain-language meaning | Good setup | | --------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | When this happens | The exact event that starts the automation. | Select the real submit button, form submission, status change, launcher, or webhook. | | Submitted status | The value that means the request is ready for review. | Match the exact value the app writes. | | Destination | Where the work appears. | Use Decision for reviewer action, Work Queue for team work, Notification Center for alerts, Conversation for discussion, Workflow Status for progress. | | Reviewer or recipient | Who receives the work. | Prefer role, team, owner, requester, reviewer, or selected user field. | | Messages | What users are told. | Write business language with a link back to the work. | | Validate | Checks whether the setup is connected. | Run after every important change. | | Repair setup | Reconnects missing generated pieces. | Read validation first, run repair only when it fits, then retest. | | Create test request | Creates or starts a realistic test path. | Use it to prove the destination screen receives the item. | ### Validation controls ![Validation ready state.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/J4yDDbTlZPwWWYg09Of3/assets/approval-management/maker-builder/04-procurement-approval-desk-validation-ready.jpg) *A clean validation state means the maker can explain the connected pieces before publishing.* Validation is not optional. A blocker means the setup is not ready to demo or publish. A warning means the setup may work, but the maker must understand the risk and test the visible result. A useful validation result should tell you: * Whether the trigger is connected. * Whether the destination screen exists. * Whether the recipient can be resolved. * Whether the user and recipient have permission. * Whether messages can be delivered. * Whether exceptions are visible. ### Live test controls ![Live test opening the reviewer destination.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/vd7tOeGGavRjUmWWnyEJ/assets/approval-management/maker-builder/05-procurement-approval-desk-live-test-approval-inbox.jpg) *A live test passes only when the visible result appears on the correct screen for the correct role.* A workflow run is not enough. The user-facing proof is what matters: * Approval work appears on Decision. * Team work appears on Work Queue. * Messages appear in Conversation or Notification Center. * Progress appears on Workflow Status. * Failures appear on Exception Resolution. * Handoffs appear on Linked App Exchange or webhook delivery status. ### Repair controls ![Readiness and repair screen.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/C2pKJlnbPbSyj51ASGn9/assets/automation-wizard-e2e/13-readiness-and-repair-destination.png) *Use readiness and repair before publishing templates, demos, or customer apps.* Repair should help with generated setup, such as missing screens, missing message routes, missing exception paths, or disconnected generated pieces. Repair should not silently choose business rules for you. You still decide who approves, which status means submitted, which screen users see, and what messages say. ### Control-by-control test script 1. Choose the wizard that matches the business outcome. 2. Fill in When this happens. 3. Choose the source page or record type. 4. Choose recipient. 5. Choose destination screen. 6. Write requester and recipient messages. 7. Save. 8. Run Validate. 9. Fix blockers. 10. Run Repair only when validation says a generated piece is missing or disconnected. 11. Run Validate again. 12. Create a test request. 13. Preview as recipient. 14. Open the destination screen. 15. Confirm the item appears and can be acted on. 16. Preview as requester. 17. Confirm the requester sees the result. 18. Check Exception Resolution.