> 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.md). # Automation ## Automation ### Automation #### Automation Automation turns a normal NotionApps app into a working business process. A user can submit a request, route it to the right person, notify a team, collect a decision, start a conversation, update a status, send work to another app, and recover from failures without asking an administrator to inspect hidden records. The most important idea is this: automation is not finished when a workflow exists. Automation is finished when a real user can start it, the right recipient can see it, the app explains what happened, and the maker can test and repair the setup from visible screens. ![Automation Home showing wizard cards for approvals, messaging, routing, recovery, and readiness.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/DxhQc0b6wKhbev9QV4Ax/assets/automation-wizard-e2e/00-automation-home-wizard-catalog.png) Latest builder behavior: outcome-first automation Automation now starts from the maker's business outcome instead of asking the maker to choose low-level workflow or messaging objects first. A maker can begin with a sentence such as: ``` When an employee submits a timecard, route it to their supervisor, open a private conversation, and notify payroll after approval. ``` NotionApps then helps the maker move through the setup in plain language: 1. **Describe the result.** The maker writes what should happen in normal business language. 2. **Use app-aware suggestions.** The builder suggests screens, forms, controls, workflows, channels, data sources, and other objects from the current application. 3. **Review what NotionApps will build.** The builder explains whether the result will use Workflow, Messaging, Approval Management, or a combination. 4. **Prove the setup.** Proof steps show whether the recipe is saved, previewed, generated, and visible in Activity. 5. **Fix the next blocker.** If something is missing, the builder points the maker to the next action, such as fixing access, completing setup, running preview, or opening Activity. The important product promise is: ``` Maker describes the business outcome. NotionApps assembles the engine. Maker reviews, tests, and publishes. ``` Advanced objects still exist because they make the app supportable. Channels, contracts, workflow steps, publishers, subscribers, approval routes, and activity logs remain available for advanced makers and support teams. The difference is that normal makers no longer need to start there.*Start on Automation Home. Pick the business outcome first, then let the wizard connect the trigger, recipient, destination, message, and validation path.* **The recommended learning path** Read the automation docs in this order when you are new or when you are handing the app to a customer: 1. Automation Overview - learn what automation does and how the pieces fit together. 2. Automation Glossary - learn the words used in the builder, in plain language. 3. Start From a Wizard - use guided setup instead of wiring every piece by hand. 4. Create your first approval workflow - build one complete approval process from a normal data page. 5. Builder Controls Visual Guide - match each visible control to what it does. 6. Approval Workflows - build supervisor, finance, manager, or policy approval flows. 7. Messaging and Notifications - send useful messages and alerts as part of the process. 8. Native Automation Screens - choose the screen users and makers need to see work, status, messages, or failures. 9. Testing, Preflight, and Repair - prove the process before publishing. 10. Troubleshooting Automation - diagnose the common failure cases from the user interface. 11. Security and Permissions - make sure each role can see only what it should see. **The five pieces every automation needs** Every working automation has five visible pieces: | Piece | Plain-language meaning | Example | | ------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Trigger | The thing that starts the automation. The builder may label this When this happens. | A user clicks Submit on a purchase request. | | Source record | The record the automation is about. | The purchase request with amount, vendor, requester, and reason. | | Recipient | The person, role, or team that receives the work or message. | Supervisor, Finance approver, Technician, Request owner. | | Destination | The screen or delivery place where the result appears. | Decision, Work Queue, Conversation, Notification Center, Workflow Status. | | Proof | The visible result that tells you it worked. | The item appears for the reviewer, a status changes, a message is delivered, or an exception appears with a fix. | If one of those pieces is missing, the workflow may technically exist, but users will experience it as broken. **Pick the right automation path** | If you need to... | Start here | User-facing screen to expect | | ------------------------------------------ | ----------------------------------- | --------------------------------------------------- | | Ask someone to approve or reject a request | Create your first approval workflow | Decision, optionally Work Queue and Workflow Status | | Send a message, reminder, or announcement | Messaging and Notifications | Notification Center or Conversation | | Assign operational work to a team | Native Automation Screens | Work Queue | | Show a requester what happened | Native Automation Screens | Workflow Status or source record status | | Let users intentionally start a process | Start From a Wizard | Automation Launcher | | Send data to another app | Webhooks and Integrations | Linked App Exchange or webhook delivery status | | Find and repair failures | Testing, Preflight, and Repair | Exception Resolution and validation results | **Important naming note** You may hear people say review queue. In the builder, the real native automation screen names are the nine screen types documented in Automation Screens. For approvals, the inbox experience is usually made from a Decision screen, a Work Queue when a team handles many requests, and Workflow Status so the requester can see progress. Use those actual screen names when configuring or troubleshooting. **Definition of done** A customer-ready automation passes this test: a normal user can start it from the app, the correct recipient can find and act on it, the requester can see the result, validation is clean, and failures appear in Exception Resolution with a clear next step. ### Latest builder behavior: outcome-first automation Automation now starts with the maker's intended business outcome. The maker can describe the result they want, and NotionApps guides them through the objects needed to make it real: workflow routes, messaging routes, approval routes, screen bindings, proof steps, and repair checks. Example outcome: > When an employee submits a timecard, route it to their supervisor, open a private conversation, and notify payroll after approval. Use this pattern when building new automation: 1. Describe the result in plain language. 2. Use app-aware suggestions for screens, forms, controls, users, roles, channels, and payload values. 3. Review what NotionApps will build. 4. Save or generate the route. 5. Run preview, preflight, or guided testing. 6. Fix the next blocker shown by the builder. 7. Publish only after the flow works for the real personas. The goal is simple: the maker describes the business outcome, NotionApps assembles the engine, and the maker proves the result from the app experience.