Setting Up Basic Automations

Creating and Managing Automations

When you want an action to happen automatically after an event is detected within DevStride, Automations are the answer.

Automations live on the Automate Workflows page. Open it from the left sidebar under the Admin section by clicking Automate Workflows (flowchart icon). An Automation watches for a trigger and, when that trigger fires, runs one or more actions. You can optionally add conditions so the Automation only runs when specific criteria are met.

Triggers are organized into six categories:

• Time Based — for example, Every Time Period (a schedule) or Due Date Arrived.
• Work Item — events on items, such as Work Item Created, Subtask Created, Status Changed, Priority Changed, Assignee Updated, Tags Updated, and more.
• Workstream — events on workstreams, such as Workstream Created or Workstream Parent Changed.
• Item Request — Item Request Submitted.
• Service Desk — events on customer tickets: Customer Replied, Customer Marked Solved, and Ticket Time Sweep. (Only available once Service Desk is enabled.)
• Github — events from a connected GitHub repository, such as Pull Request Opened, Branch Created, or All Reviews Approved.

In this guide, you will create an Automation from a trigger that automates a task for you.

Add a New Automation Group

By default, every Automation is placed in the Other group. You can also create your own groups to keep things organized, which becomes especially helpful as the number of Automations grows.

Click the green + Group button in the top right of the Automate Workflows page. This opens the New Automation Group dialog, where you name the group. Once created, you can assign existing and new Automations to it.

Add an Automation

To create an Automation, click the + Automation button in the top right of the Automate Workflows page. This opens the Add Automation dialog.

Configure the Automation

At the top of the dialog you set two fields:

• Description — the name shown for this Automation in the list. (Placeholder: Add a Description.)
• Automation Group — which group the Automation belongs to in the list. (Placeholder: Select Automation Group.)

Below those fields, the builder is laid out in two numbered columns:

• 1. When this happens... — choose the trigger. Use the Trigger selector (placeholder Select a trigger) to pick from the categories above.
• 2. Then do this: — choose the action that runs when the trigger fires.

To save the Automation, click Create (the button reads Update when you are editing an existing one).

For example: any time a Work Item Created event occurs anywhere under your Product workstream hierarchy, change the team to Product.

Refine the trigger with conditions (optional)

Conditions let you narrow when an Automation fires. Rather than being a separate numbered step, conditions appear as optional And only if cards inside the When this happens column. Add one with the Add Condition button, then pick a field, an operator, and a value.

You can add up to 10 conditions per trigger. When you reach that limit, Add Condition is disabled and shows a tooltip explaining that the maximum number of conditions has been reached.

The fields available as conditions depend on the trigger:

• Work Item, Due Date, and GitHub triggers can be refined by fields such as Direct Parent, Parent Hierarchy, Color, Item Type, Priority, Author, Tags, Time Estimate, Effort Points, Status, Team, Board, Cycle, Assignee, Custom Field, Due Date, and Time Spent.
• The Subtask Created trigger has its own four conditions: Subtask Assignee, Subtask Team, Parent Item Assignee, and Parent Item Team.
• Workstream triggers support only the shared conditions: Direct Parent, Parent Hierarchy, and Color.
• Service Desk triggers add ticket fields — most usefully Customer Status (Open / Solved / Closed, as your work type maps it). Ticket Time Sweep also adds four elapsed-time conditions of its own; see below.
• Schedule (Every Time Period) and Item Request Submitted triggers take no conditions.

Operators vary by field — for example, equality (is equal to / is not equal to), contains / does not contain (Tags and Parent Hierarchy), numeric comparisons (Time Estimate, Effort Points, Time Spent), date comparisons (Due Date), and is set / is not set.

Elapsed-time conditions (Ticket Time Sweep)

The Ticket Time Sweep trigger runs hourly over your open tickets and asks "how long since…", which is what makes automatic ticket closure, first-response escalations, and no-reply nudges possible. It adds four conditions — Hours Since Created, Hours Since Status Changed, Hours Since Staff Reply, and Hours Since Customer Reply — each taking is at least or is less than, a number of hours, and a choice between Calendar hours and Business hours (your team's working calendar, so a timer doesn't run overnight or over a weekend).

A Ticket Time Sweep must have at least one condition: with none, it wouldn't match nothing — it would match every open ticket, every hour. Full guide: Time-Based Ticket Automations.

Choose one or more actions

In the Then do this column, pick the action to run. Actions are grouped by what they affect:

• Messaging — Send Notification. When the notification goes to Slack or Microsoft Teams, any value it fills in from the item or trigger — a title, a custom field, a ticket subject from a customer's email — appears as plain text, so it can never become a clickable link or an @channel / @here mention. In Microsoft Teams, two kinds of value stay clickable: the item's own title and hierarchy, which link to the item in DevStride, and a web-address custom field holding a plain address such as https://example.com or www.example.com, shown as a link whose text is the address itself, so it can't disguise where it goes. An address with anything unusual in it, and every file custom field, stays plain text. The wording and formatting you write yourself in the notification are sent as written.
• Service Desk — Send Customer Reply, which emails the ticket's requester directly. Because it reaches the customer, it always sends as a public reply (never an internal note) and requires the Send Public Replies permission.
• Integrations — Call Webhook.
• Work Item — Create Work Item, Create Subtask, Change Subtask Assignee, Change Subtask Status, Set Subtask Due Date, Complete Child Items or Subtasks, Change Item Parent, Change Item Color, Change Status, Change Item Type, Change Priority, Change Team, Change Assignee, Change Point Effort, Change Time Estimate, Change Cycle/Board, Change Custom Field, Add Tags, Remove Tags, Set Due Date, and Change Time Spent.
• Workstream — Create Workstream, Change Workstream Parent, Change Workstream Color.
• Relationships — Create Relationships.

To run more than one action, add another and DevStride joins them with And Then.

Complete a Story's child work

To complete QA work when its Story is completed:

1. Choose Status Changed as the trigger. Leave the previous status unrestricted and select your completed status, such as Complete, as the new status.
2. Add an Item Type condition matching Story.
3. Choose Complete Child Items or Subtasks as the action.
4. Select Child items and subtasks, Child items only, or Subtasks only, then save the automation.

The action completes work directly under the triggering item. Child items move to the Done status available on their own board or team. Already-completed work and archived child items are left alone. The action itself does not complete deeper descendants or the Story's parent project.

Child status changes can trigger matching automations. The Story condition keeps this recipe from matching QA Task children. If a child is also a Story, it can match and start another run. Each action invocation completes direct children only.

This action works with Automate New/Done switched off. That organization setting controls separate upward completion; if you leave it enabled, its parent-completion behavior still applies. Leave it off when maintenance projects should stay open while this automation completes their Stories' QA work.

An action supports up to 100 selected direct child items and subtasks combined, including completed entries; archived child items do not count. A larger selection fails before changing any selected work, and the automation remains enabled.

If a child's status configuration is unavailable, the action also leaves its selected work unchanged and records a failed run. The automation stays enabled for future triggers. Check Run history for the reason.

Give new subtasks their parent's assignee

To have every new subtask start with the person who owns its parent item:

1. Choose Work Item → Subtask Created as the trigger.
2. Optionally add conditions, such as Subtask Assignee is not set so subtasks someone already assigned are left alone, or Parent Item Team to limit the rule to one team.
3. Choose Change Subtask Assignee as the action. Use the parent item's assignee is selected by default; leave it on.
4. Save and enable the automation.

When someone adds a subtask, it takes whoever the parent item is assigned to. A parent with no assignee leaves the subtask unchanged. To assign a specific person instead, clear Use the parent item's assignee and choose them; if that person is not on the parent item's team, the action does not run.

The same trigger can also set a new subtask's status with Change Subtask Status (New, In Progress, or Done), or give it a due date a number of days after it is created with Set Subtask Due Date (0 means the same day).

Ordinary item automations, such as Work Item Created, can also refer to the Parent Item Assignee and Parent Item Team when you choose a reference value, for example to assign a new item to its parent's assignee.

Remove completed work from a board after a delay

To keep a perpetual board focused on current work:

1. Choose Time Based → Item Stays Done on Board as the trigger.
2. Select the Source board and enter Time spent Done on this board in Hours or Days, such as seven days.
3. Choose Change Cycle/Board as the action, then Remove Cycle/Board. To move the item elsewhere instead, choose Set to Cycle/Board and the destination.
4. Save and enable the automation.

The rule is checked hourly, so removal happens on a check after the chosen delay, not at an exact minute. It runs once per qualifying stretch in Done. Only items completed after the automation is enabled qualify; existing Done items are not swept up retroactively. Reopening an item or changing its board starts a new waiting period. Re-enabling the rule or changing its source, delay, or conditions starts fresh.

Removing board placement does not delete the item or its history. You can still find it in its workstream. Review Run history to check the rule's results.

For the separate task of removing an archived board or folder, see permanent board and folder deletion.

Work with personas in Automations

Use Persona Updated to react when an item's chosen persona changes, Persona conditions to narrow the rule, and Change Persona to assign the required kind of work. Persona values can also be used in supported automation references.

These changes follow the same assignment rules as the chooser: selecting a persona preserves a compatible person and clears an incompatible one. Clearing the persona while keeping a person with personas applies that person's first active persona. Personas grant no extra permissions to the automation or to members.

Work with Tags in Automations

You can use Tags in a trigger, a condition, or an action. The Tag Selector lets you choose from all tag types consistently across every part of the Automation:

• In the Tags Updated trigger, set From any of and To any of (placeholder Any Tag).
• In the Tags condition, match Any of these tags (placeholder Select Tags).
• In the Add Tags or Remove Tags action, choose the tags under Tags to Add or Tags to Remove.

Monitor Automation Run History

To check how an Automation has been behaving, click the Run history (history) icon on the Automation's row. This opens the Automation Runs dialog, where you can review each run to confirm it matches your expectations or to help diagnose why it may not be firing.

Each run shows one of three results:

• Completed — the actions ran. A run can still carry a Note, for example when one of several actions had nothing to do.
• Skipped — nothing could be done, and the Reason says why in plain words. A Change Cycle/Board action that points at a cycle with no board — say current cycle + 6 when only five cycles are scheduled — is skipped rather than reported as a success, and the reason names the board folder and the cycle. The item stays where it was. A skipped move still counts toward your monthly automation actions, which is what stops an automation that keeps retriggering itself.
• Failed — an action hit an Error; the message tells you which one.

Each Automation row also offers a Duplicate action to copy an existing rule, and an enable/disable toggle to turn an Automation on or off without deleting it.