Two ways to build
Use a simple rule for a straightforward trigger and action, or the visual editor for a branching workflow.
AMS · Connected business workflows
Automations — Set the rule. Keep work moving.
Turn repeatable decisions into workflows your team can inspect, test and control.
Who this helps
Team leads who repeat the same task handoff and want an explicit, inspectable rule.
The situation
High-priority work needs Layla’s review, but someone has to remember to assign it every time its status changes.
Fictional example: a high-priority task entering In review is assigned to Layla by a configured workflow. This website example makes no live changes.
Follow the example, step by step
Add a trigger
- What you do
- Drag Task Status Changed from the library onto the canvas.
- What changes
- A trigger node becomes the starting point of the workflow.
- Why it helps
- The rule starts from a specific event in the team’s work.
Set the event
- What you do
- Set To status to In review.
- What changes
- The trigger now identifies the review handoff it should respond to.
- Why it helps
- Unrelated status changes do not start this configured path.
Add a condition
- What you do
- Add a condition that checks whether task priority equals High.
- What changes
- The Yes branch represents matching work; other tasks stop on this example’s unconnected branch.
- Why it helps
- The assignment applies to the work you intended to escalate.
Choose the action
- What you do
- Add Assign Task and select Layla as the assignee.
- What changes
- The action node states exactly who should own the next step.
- Why it helps
- The team can inspect the assignment before any real workflow runs.
Connect the nodes
- What you do
- Connect the trigger to the condition, then connect Yes to Assign Task.
- What changes
- One connected path now links the event, decision and assignment.
- Why it helps
- You can check the complete handoff before enabling the rule.
Follow the result
- What you do
- Follow the sample high-priority task as it enters In review.
- What changes
- The demonstration shows Layla assigned while the brief, deadline and context remain with the task.
- Why it helps
- You can explain what the configured rule changes and why.
What your team gains
The chosen event, condition and assignment form one visible rule that the team can inspect before enabling it.
Define the event, check the conditions and carry out the configured actions consistently.
Inside Automations
Task & time triggers
Respond to task creation, assignments, status changes, overdue work and scheduled events.
Conditions & delays
Use field conditions, all/any logic, branches and timed waits to shape the path.
Useful actions
Create or assign tasks, change priority, add tags or comments, stop a timer and send notifications.
Connected workflows
Supported messaging, social and webhook actions can extend workflows when the necessary access is configured.
Test & execution history
Review node results, status, duration and trigger context when checking a workflow.
Questions and requirements
Will this demonstration assign someone in my workspace?
No. It is a local simulation. A real workflow must be configured and enabled in AMS, with the relevant access and an eligible paid plan.
Can every team member use every trigger and action?
Available operations depend on permissions, scope and configuration. Provider actions also depend on connected-account capabilities.
Requirements and limits
Automations require a paid plan. Triggers and actions are filtered by permissions, scope, connected account capabilities and configuration.
This page simulates a task-status rule locally; it does not execute a server workflow or send notifications.
Understand the next tool here
Read how each connection helps before choosing whether to open another page. Moving between tools does not itself configure an automatic handoff.
Projects & tasks — read how it fits
Agree on task statuses and ownership before automating the handoff.
Give every task an owner, a deadline and the context to move forward.
Fictional example: Nour moves the Autumn launch creative brief from In progress to Review.
Before you use it
Available views and actions depend on your access. Time tracking and automations require an eligible paid plan.
Optional: explore the full Projects & tasks story ↗Custom fields — read how it fits
Use a supported field-change trigger when a structured value should start a separately configured rule.
Extend supported records with the information that makes your way of working specific.
Fictional example: a task records Autumn collection, 12 assets and a Ready for review checkbox.
Before you use it
Field types and scope depend on the entity and configuration. Custom fields do not bypass record permissions.
Optional: explore the full Custom fields story ↗Permissions & scopes — read how it fits
Check the access required for the actions your workflow will perform.
Control who can act, which project details they can change and what data they can see.
Fictional example: compare the displayed Project manager matrix with a Member view and assigned-record scope.
Before you use it
The displayed role matrix is an example, not the default of a named system profile. Access follows the configured project snapshot and applicable organization controls.
Optional: explore the full Permissions & scopes story ↗