> 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/automation-overview.md). # Automation Overview ## Automation Overview ### Automation Overview Automation is the part of NotionApps that moves work forward after a user takes an action. It connects data pages, buttons, roles, messages, status changes, and native automation screens into one business process. A data page answers: what records can users view, add, or edit? Automation answers: what should happen next? ![Automation Home with guided setup cards.](https://content.gitbook.com/content/5ZqDXcVVffWUqEIZVhmn/blobs/DxhQc0b6wKhbev9QV4Ax/assets/automation-wizard-e2e/00-automation-home-wizard-catalog.png) *Automation Home is the safest starting point because each wizard is organized around a business outcome.* #### What automation can do Automation can help you build processes such as: * Purchase approvals where an employee submits a request and a supervisor makes a decision. * Timecard approvals where an employee submits hours and a manager approves or requests changes. * Inventory exception handling where a count issue routes to an operations queue. * Customer service handoffs where a new request creates work, sends a message, and tracks status. * Notifications where users receive updates when a record changes. * Linked app handoffs where one app sends approved work to another app. #### How the pieces fit together Think of automation as a sentence: When this happens, use this record, send this work to this person, show it on this screen, send this message, update this status, and show this failure if something goes wrong. In builder language, that sentence becomes: | Builder concept | Plain-language meaning | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Trigger or When this happens | The exact user action or data event that starts the process. | | Workflow | The saved route that decides what happens after the trigger. | | Recipient | The role, team, owner, requester, reviewer, or field value that receives work or a message. | | Destination | The screen or external place where the result appears. | | Message | The words the user or recipient sees. Good messages explain the business event, not the internal workflow. | | Validation | A check that tells the maker whether required pieces are connected. | | Repair | A guided fix for missing generated pieces. Repair should never replace business choices like reviewer or status without the maker knowing. | | Exception | A visible failure record that explains what needs attention. | #### The maker journey A maker usually builds automation in this order: 1. Prepare the data page. Make sure the app has the fields users and reviewers need. 2. Decide the starting event. For approvals, this is usually Submit, not a manual database edit. 3. Choose a wizard. Use the wizard that matches the business outcome. 4. Choose the recipient. Prefer roles or teams over one named person. 5. Choose the destination screen. Use the actual native screen name: Decision, Work Queue, Conversation, Notification Center, Workflow Status, Exception Resolution, Automation Launcher, Linked App Exchange, or Operator Console. 6. Write the messages. The recipient should know what happened and what to do. 7. Run validation. 8. Create a test request or preview the real user action. 9. Test as each role. 10. Publish only after the visible app result works. #### What good automation feels like Good automation does not require a maker to explain hidden behavior. The app itself should show what happened. A requester sees Submitted or Waiting for review. A reviewer sees the item on a Decision screen. A team sees work in a Work Queue. A user receives a Notification Center item or Conversation message. A maker sees failed routes in Exception Resolution. If the only proof is a backend record, the setup is not self-service yet. #### Next step If this is your first automation, read Automation Glossary, then build Create your first approval workflow\.Outcome-first builder model The current Automation builder is designed so a maker can begin with a business outcome instead of a technical object. A maker should be able to say something like: > When a stock count is submitted below the expected quantity, alert operations, create an exception review, and let the team discuss the issue. NotionApps then helps assemble the working pieces behind that outcome. The maker still reviews and publishes the result, but the first experience should feel like guided setup, not like configuring infrastructure. A good automation setup follows this path: 1. Describe the business outcome. 2. Choose the source screen, form, role, or data object from app-aware suggestions. 3. Review what NotionApps will build: workflow route, message route, approval route, screen binding, or guided test. 4. Save the generated setup. 5. Run the preview or guided test. 6. Fix the next visible blocker if readiness is not green. 7. Publish only after the user journey works for the right persona. For makers, the important promise is simple: describe what should happen, let NotionApps assemble the engine, then test the result from the app experience.Outcome-first builder model The current Automation builder is designed so a maker can begin with a business outcome instead of a technical object. A maker should be able to say something like: > When a stock count is submitted below the expected quantity, alert operations, create an exception review, and let the team discuss the issue. NotionApps then helps assemble the working pieces behind that outcome. The maker still reviews and publishes the result, but the first experience should feel like guided setup, not like configuring infrastructure. A good automation setup follows this path: 1. Describe the business outcome. 2. Choose the source screen, form, role, or data object from app-aware suggestions. 3. Review what NotionApps will build: workflow route, message route, approval route, screen binding, or guided test. 4. Save the generated setup. 5. Run the preview or guided test. 6. Fix the next visible blocker if readiness is not green. 7. Publish only after the user journey works for the right persona. For makers, the important promise is simple: describe what should happen, let NotionApps assemble the engine, then test the result from the app experience. ### Outcome-first builder model The current Automation builder is designed so a maker can begin with a business outcome instead of a technical object. A maker should be able to say something like: > When a stock count is submitted below the expected quantity, alert operations, create an exception review, and let the team discuss the issue. NotionApps then helps assemble the working pieces behind that outcome. The maker still reviews and publishes the result, but the first experience should feel like guided setup, not like configuring infrastructure. A good automation setup follows this path: 1. Describe the business outcome. 2. Choose the source screen, form, role, or data object from app-aware suggestions. 3. Review what NotionApps will build: workflow route, message route, approval route, screen binding, or guided test. 4. Save the generated setup. 5. Run the preview or guided test. 6. Fix the next visible blocker if readiness is not green. 7. Publish only after the user journey works for the right persona. For makers, the important promise is simple: describe what should happen, let NotionApps assemble the engine, then test the result from the app experience.