Available Automation Triggers

It triggers the rule when all or some subitems get the status(es) that you define.

E.g., "When all direct subtask statuses change to Completed, then..."

In the drop-down select All subitems if you want to trigger the rule when all subitems get the relevant status(es). Or select Any subitem to trigger the rule when at least one subitem gets such status.

Select at least one status group (e.g., Any completed). In this case, the rule is triggered by statuses included in this group in any workflow.

Click Select specific statuses to choose at least one specific status that will trigger the rule.

If at least one of the selected specific workflow statuses is deleted from the account, the rule will be disabled.

It triggers the rule when all predecessors of tasks change their status to the status(es) you define.

Task predecessors are a part of the Gantt chart. You can read more about them here.

E.g., "When all task predecessors' statuses change to Completed, then..."

Select at least one status group (e.g., Any completed). In this case, the rule is triggered by statuses included in this group in any workflow.

Click Select specific statuses to choose at least one specific status that will trigger the rule.

The trigger only checks direct predecessors.

If at least one of the selected specific workflow statuses is deleted from the account, the rule will be disabled.

It triggers the rule whenever a task or project status changes to a status(es) that you define.

E.g., "When project status changes to Completed or Canceled, then..."

Select at least one status group (e.g., Any completed). In this case, the rule is triggered by statuses included in this group in any workflow

Click Select specific statuses to choose at least one specific status that will trigger the rule.

The rule dependent on this trigger won’t work if the relevant status is set automatically while a task or project is being created or duplicated.

If at least one of the selected specific workflow statuses is deleted from the account, the rule will be disabled.

It triggers the rule when a task or project spends too much time in the same status(es) that you define. The countdown restarts each time the status changes to a new one.

E.g., "When task status doesn’t change in 5 days from In progress, then..."

Set the number of calendar days during which the status should stay the same for the rule to be triggered.

Next, select at least one status group (e.g., Any active). In this case, the rule is triggered by statuses included in this group in any workflow.

Click Select specific statuses to choose at least one specific status that will trigger the rule.

If you create a rule with this trigger, it won't be applied to tasks or projects retrospectively. This means that the rule won't be triggered if the status of a task hadn't been changed for the defined number of days before you created the rule.

E.g., the trigger was set to five days. If a task had already had the same status for five days before the rule was created, it wouldn't be triggered. But if the task had the same status for three days, and then you created the rule, it'll be triggered in two days.

It triggers the rule when a value in a custom field changes.

E.g., "When custom field Urgency changes to any value, then..."

Select the custom field.

For single-select fields, choose whether the rule should be triggered by any value change or by a change to a specific value.

For checkbox fields, choose whether the rule should be triggered when it changes to any value or specifically to checked or unchecked.

The trigger only works for single-select and checkbox custom fields that are added to the project, folder, or space that you select in the Apply to section of the rule constructor.

It triggers the rule when a new task or project is created in the source location(s) you select in the Apply to section of the rule constructor.

E.g., "When a new task is created (in the selected location), then ..."

-

The rule dependent on this trigger won’t work if tasks and projects are created via Excel import or API.

The rule dependent on this trigger also won’t work if tasks and projects are created via duplication or request forms/blueprints, which are set up to create 250 or more work items at a time.

It triggers the rule when a task/project start or due date or a date in a custom field is approaching or is already overdue.

E.g., "When the task’s due date will be within the next 1 day, then..."

Select if the trigger depends on Due date, Start date, or Custom field (date). For the custom field option, select the relevant date-type custom field.

Select one of the options that will trigger the rule: the date Has passed or Will be within the next. For the latter option, set the amount of time, e.g. 1d 12h.

Select the relevant time zone.

The rule dependent on this trigger won't work if the changes to the items were made by automatic task rescheduling.

The trigger counts calendar days (24h) and doesn't take into account work schedule settings.

The trigger will only work for tasks and projects with a status from an active group.

For the Custom field (date) option, the relevant date-type custom field should be added to the location you specified in the Apply to section of the rule constructor. Otherwise, you won't be able to select it for the trigger.

It triggers the rule when a project's risk level changes.

E.g., "When project risk level changes to high, then..."

Select the change in the risk level that should trigger the rule: if it raises or lowers. Or choose the exact risk level: low, medium, or high.

This trigger will work only for projects that:

It triggers the rule when the item's location changes.

E.g., "When a task in "Creative assets" is added to another folder, then..."

-

The rule is triggered when changes are made to the Location field of items within the rule's scope. For instance, if the rule applies to tasks in "Folder 1," any addition or removal of locations from the tasks will trigger the rule. This includes adding or moving a task in "Folder 2" to "Folder 1." However, the rule won't be triggered if tasks are removed from "Folder 1" or if new tasks are created directly within "Folder 1."

It triggers the rule when a value in a custom field is changed: added, edited, or removed.

No settings are needed for these triggers. However, you can add conditions if you want the rule to react to a specific field change.

E.g., "(trigger) When the custom field Urgency changes, (condition) and it's set to Critical, then..."

The trigger only works for fields that are added to the project, folder, or space that you select in the Apply to section of the rule constructor.

This group of triggers sets the rule off when a value of a field is changed in any way: added, edited, or removed.

No settings are needed for these triggers. However, you can add conditions to the assignee, start date, due date, completed date changes, and importance triggers if you want the rule to react to a specific field change.

E.g., "(trigger) When the Importance of a task, changes, (condition) and if it's set to High, then..."

All triggers from this group work for tasks and task-based custom items.

Duration and importance triggers are not available for projects and project-based custom items.

It triggers the rule when an item's billing type changes.

No settings are needed for this trigger. However, you can add conditions if you want the rule to react to billing type changing specifically to billable or non-billable.

E.g., "(trigger) When the billing type of a task, changes, (condition) and if it's set to non-billable, then..."

This trigger is accessible to accounts that have the Billable Time in Wrike feature.