> 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/start-from-a-wizard.md). # Start From a Wizard ## Start From a Wizard ### Start From a Wizard Use a wizard when you know the business result you want but do not want to assemble every workflow piece by hand. Wizards are the recommended starting point for most makers because they keep the trigger, recipient, destination screen, message, validation, and exception path together. ![Approval workflow wizard card.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/onRLcwcwMS5FgTSUGvNN/assets/automation-wizard-e2e/02-approval-workflow-card.png) *Choose the card by business outcome. For approvals, the outcome is that someone can review and decide.* #### Why wizards matter Many automation problems happen because one piece is created without the others. A maker creates a workflow but not a visible screen. A button saves a record but does not start the route. A message is sent but does not link to the item. A reviewer exists but does not have permission. A wizard prevents that by asking for the pieces together. #### Choose the right wizard | Business situation | Wizard to start with | Expected screen or result | | ------------------------------------------------ | ----------------------------------- | ------------------------------------------------ | | Someone must approve, reject, or request changes | Approval workflow | Decision, plus Workflow Status for the requester | | A team needs to claim or complete work | Queue or dispatch workflow | Work Queue | | A user needs a notification or reminder | Notification route | Notification Center | | Two people need to discuss a record | Conversation or clarification route | Conversation | | A user needs to manually start a process | Launcher workflow | Automation Launcher | | Work must move to another app | Linked app handoff or webhook route | Linked App Exchange or webhook delivery result | | A route can fail and needs recovery | Exception recovery | Exception Resolution | | You are preparing to publish | Readiness and repair | Validation and preflight results | #### Step-by-step setup 1. Open the app in the builder. 2. Open Automation from the builder navigation. 3. Read the wizard card titles as business outcomes, not technical objects. 4. Choose the wizard that matches what the user expects to happen. 5. Fill in When this happens. This must be the exact button, form, status change, launcher, or webhook the user will use. 6. Choose the source page or source record type. 7. Choose the recipient. Prefer role, team, owner, requester, reviewer, or a selected user field instead of one hard-coded person. 8. Choose the destination. Use the actual screen name from the builder: Decision, Work Queue, Conversation, Notification Center, Workflow Status, Exception Resolution, Automation Launcher, Linked App Exchange, or Operator Console. 9. Write the recipient message in business language. 10. Write the requester result in business language. 11. Save the wizard. 12. Run validation. 13. Fix blockers. 14. Create a test request or preview the real user action. 15. Confirm the result appears on the destination screen. ![Approval workflow setup destination controls.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/rejdqrxvGQLyYof5HL31/assets/automation-wizard-e2e/02-approval-workflow-destination.png) *The setup screen should make the trigger, destination, recipient, and visible result clear before you save.* #### How to know the wizard worked A wizard worked when the app has visible proof. For approvals, the reviewer can open a Decision screen and act on the request. For queues, the item appears in Work Queue. For notifications, the recipient sees the message in Notification Center. For conversations, the thread appears. For failures, Exception Resolution explains what needs attention. #### Common wizard mistakes | Mistake | What the user sees | Fix | | ------------------------------------------------------ | --------------------------------------------------- | --------------------------------------------------------------------- | | Choosing a status value but not the real submit button | Submit saves the record, but nothing routes. | Reopen When this happens and choose the actual user action. | | Choosing a named recipient who later leaves | Requests stop routing or route to the wrong person. | Use a role, team, owner, requester, reviewer, or selected user field. | | Skipping the destination screen | The workflow runs but nobody can find the work. | Generate or select the right native automation screen. | | Testing only as owner | Owner sees everything; customer roles see nothing. | Preview as requester and recipient. | | Running repair without retesting | Setup says repaired, but the demo still fails. | Always create a fresh test request after repair. | #### Next step Build Create your first approval workflow if you want a complete example from data page to working review\.Current wizard behavior: NotionApps assembles the route The wizard is now designed to feel like a guided conversation with the maker. The maker should not need to know whether the final setup requires a workflow, a message route, an approval route, a publisher, a subscriber, a contract, or a notification screen before they begin. Use the wizard this way: 1. **Tell NotionApps what should happen.** Start with the business result, such as "notify the right person," "request approval," "broadcast an announcement," or "start a conversation around this record." 2. **Answer the numbered questions.** The wizard asks for the source, destination, audience, data, timing, or recipient only when those details are needed. 3. **Use context-aware choices.** When a field asks for a screen, form, workflow, data source, or channel, start typing the friendly name. The builder uses the current application context instead of asking the maker to remember raw IDs. 4. **Review the route explanation.** The wizard explains what NotionApps will build in plain language before advanced objects are generated. 5. **Build and preview.** NotionApps creates the recipe or route objects, then asks the maker to run preview or guided testing before publishing live. 6. **Verify Activity.** After the maker tests as a real app user, Activity should show the accepted message, workflow run, waiting approval, delivered announcement, or setup blocker. A good wizard result should answer four questions for the maker: | Question | What the maker should see | | ------------------------ | ------------------------------------------------------------------------------------------------ | | What starts this? | The selected screen, form, button, workflow event, message, or external trigger. | | Who receives it? | The reviewer, role, user, app audience, webhook, workflow, screen, or linked app. | | What will happen? | The plain-language action NotionApps will perform. | | How do I know it worked? | A proof step in Activity, a visible screen update, a delivered message, or a guided test result. | If the wizard shows a blocker, follow the **Fix this next** action first. It is intentionally ordered so makers solve setup problems before they publish.Current wizard behavior: NotionApps assembles the route The wizard is designed to behave like a guided conversation. The maker should not need to remember IDs, channels, screen names, workflow names, or payload paths before they can begin. Use the wizard this way: 1. Tell NotionApps what business outcome you want. 2. Answer the numbered questions one at a time. 3. Use context-aware choices for screens, forms, controls, roles, people, channels, and app objects. 4. Review the route explanation before creating anything. 5. Build the route when the explanation matches the process you expect. 6. Run the guided proof steps so the maker knows the setup works. The wizard should feel simple on purpose. It asks business questions and creates the technical objects behind the scenes. | Wizard question | What it means | | ------------------------ | ---------------------------------------------------------------------------------------------------- | | What starts this? | The user action, form submission, screen event, or data change that begins the process. | | Who receives it? | The person, role, team, app owner, requester, reviewer, or fallback audience. | | What should happen? | The notification, approval, workflow step, message route, or screen action NotionApps should create. | | How do I know it worked? | The Activity, notification, screen result, or test step the maker should verify. | If a route is incomplete, use the visible fix action rather than editing raw JSON first. ### Current wizard behavior: NotionApps assembles the route The wizard is designed to behave like a guided conversation. The maker should not need to remember IDs, channels, screen names, workflow names, or payload paths before they can begin. Use the wizard this way: 1. Tell NotionApps what business outcome you want. 2. Answer the numbered questions one at a time. 3. Use context-aware choices for screens, forms, controls, roles, people, channels, and app objects. 4. Review the route explanation before creating anything. 5. Build the route when the explanation matches the process you expect. 6. Run the guided proof steps so the maker knows the setup works. The wizard should feel simple on purpose. It asks business questions and creates the technical objects behind the scenes. | Wizard question | What it means | | ------------------------ | ---------------------------------------------------------------------------------------------------- | | What starts this? | The user action, form submission, screen event, or data change that begins the process. | | Who receives it? | The person, role, team, app owner, requester, reviewer, or fallback audience. | | What should happen? | The notification, approval, workflow step, message route, or screen action NotionApps should create. | | How do I know it worked? | The Activity, notification, screen result, or test step the maker should verify. | If a route is incomplete, use the visible fix action rather than editing raw JSON first.