Sign Up
Automation

Build and manage automations

Automation rules should be specific, testable, and easy to explain. A strong rule uses a clear trigger, narrow conditions, a safe action, and a controlled scope.

A safe automation setup should help you:

  1. Plan a new automation rule.
  2. Build a rule in the automation builder.
  3. Review and change an existing rule.
  4. Confirm access, plan, and network requirements.
  5. Test behavior before relying on it.

Builder State Reference

StateWhat to do
LoadingWait for the builder to initialize.
RetrySelect Retry. If it repeats, refresh the app and confirm network access.
No internetReconnect before opening or changing rules.
No accessAsk a Space admin to review your role.
Upgrade promptAsk the billing owner to review plan availability.
Builder loadedCreate, review, and manage rules from the builder.

Rule Design Reference

PartDefinitionGood practice
NameThe label people see in the builder.Use a plain-language purpose, such as Assign reviewer when task moves to Review.
TriggerThe event that starts the rule.Choose the most specific event available.
ConditionRequirements that must be true before the action runs.Add conditions to prevent accidental matches.
ActionThe update, notification, assignment, reminder, or other operation performed.Keep the first version low-risk.
ScopeThe Space, List, or work area where the rule applies.Start narrow, then expand only after testing.
StatusWhether the rule can run.Pause or disable rules while investigating unexpected behavior.

Before you start

  • You must be in the correct Space.
  • Your role must allow automation access.
  • Your plan must include automation access.
  • Use safe test items before relying on the rule for real work.

Plan the rule before building

Write the rule in this format:

When [trigger] happens, if [condition] is true, then [action].

Examples

  • When a task moves to Review, assign the reviewer.
  • When a task is marked blocked, notify the team.
  • When a follow-up date is added, create a reminder.

Create an automation

  1. Open Automations.
  2. Wait for the builder to load.
  3. Start a new rule.
  4. Name the rule clearly.
  5. Choose the trigger.
  6. Add conditions.
  7. Choose the action.
  8. Confirm scope.
  9. Save the rule.
  10. Test with a safe item.

Expected outcome: The automation is saved and only affects matching work.

Manage an existing automation

  1. Open Automations.
  2. Select the rule you want to review.
  3. Check name, trigger, conditions, action, scope, and status.
  4. Pause or disable the rule if behavior is uncertain.
  5. Edit one part at a time.
  6. Save and retest.

Safe setup checklist

Before relying on a rule, confirm:

  1. The trigger is specific.
  2. Conditions prevent broad matches.
  3. The action is safe.
  4. Scope is limited to the intended area.
  5. A test item produced the expected result.
  6. The affected team understands the automatic update.
  7. You know how to pause or disable the rule if needed.

Troubleshooting

Builder keeps showing Retry

  • Symptom: The builder does not open after retrying.
  • Cause: Session, network, service availability, or initialization details may be missing.
  • Resolution:
    1. Confirm you are online.
    2. Refresh the app.
    3. Confirm the current Space loaded correctly.
    4. Try again.
    5. Report the approximate time and Space if it still fails.

Rule affects too much work

  • Symptom: More items change than expected.
  • Cause: Trigger, conditions, or scope are too broad.
  • Resolution:
    1. Pause or disable the rule if available.
    2. Narrow scope.
    3. Add stricter conditions.
    4. Test with one matching and one non-matching item.

People are surprised by automatic changes

  • Symptom: Team members do not know why work changed.
  • Cause: The rule name or team process may not explain the automation.
  • Resolution:
    1. Rename the rule so its purpose is clear.
    2. Tell affected users what trigger causes the action.
    3. Keep high-risk decisions manual.

FAQ

How broad should a new rule be?

Start narrow. Expand only after a safe test proves the behavior.

Should I edit a rule while it is causing unexpected updates?

Pause or disable it first if the builder provides that option. Then edit, test, and re-enable.