🎛️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 is the starting point for guided setup.
Automation Home
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
This screen connects the real trigger, recipient, destination, messages, validation, repair, and test path.
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
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
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
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
Choose the wizard that matches the business outcome.
Fill in When this happens.
Choose the source page or record type.
Choose recipient.
Choose destination screen.
Write requester and recipient messages.
Save.
Run Validate.
Fix blockers.
Run Repair only when validation says a generated piece is missing or disconnected.
Run Validate again.
Create a test request.
Preview as recipient.
Open the destination screen.
Confirm the item appears and can be acted on.
Preview as requester.
Confirm the requester sees the result.
Check Exception Resolution.