Configure workflows and automation

Workflows apply repeatable rules when records change or when a supported schedule or SLA event is evaluated. Use them to route cases, keep record values consistent, notify the right people, and connect supported events to external systems.

Before you begin

• Write the intended rule in one sentence: When this event happens, if these conditions are true, perform these actions.
• Create or confirm the queues, teams, users, custom fields, surveys, and integrations the rule will use.
• Review other workflows for the same record type and event. Their order and Stop When Hit settings can affect the outcome.
• Plan test records and expected results, including a case that should not match. Actions can change records, send messages, or call external systems.
• Build and review a new rule while inactive. Activate it in a test environment to verify execution before enabling it for production work.

Create and verify a workflow

1. Open Settings → Configuration → Workflows. Use search and the scope, event, and status filters to find related rules.
2. Create a workflow and enter a meaningful Name and Description. A useful name describes the outcome, such as “Route urgent onboarding cases.”
3. Choose What record type is evaluated and When the rule runs. The editor adjusts its available settings.
4. Set the execution Order, review Stop When Hit, and leave the rule inactive while preparing it.
5. Configure the Trigger settings required by the event, such as a schedule or SLA target.
6. Add Requirements that must all match, then any alternative Conditionals and exclusions.
7. Add the required Actions and review recipients and external destinations.
8. Save. Resolve validation errors and review any confirmation about removing incompatible settings after a scope/event change.
9. In a test environment, activate the rule and exercise matching and nonmatching records. Check the resulting records, audit history, and actual message/provider outcomes.
10. Enable the verified rule for the intended users and records. Review its early results and interactions with other workflows.

Details and execution order

A new workflow starts with Case / Created, Order 1, Stop When Hit off, and Active on. Change Active before saving an unfinished rule. Existing workflows retain their saved values.

Choose the record type and event

Choose from the options supplied by your editor. A similarly named event on another record type does not imply that the same conditions or actions are supported.

Follow up after a chat times out

Chat timed out is a Case event for an unanswered waiting chat that reaches its configured timeout and is converted to a support case. It runs after the transcript and follow-up routing are ready. It also applies when the chat was already linked to a case. Normal chat closure and historical timeouts do not trigger it.

To give clients a clear ticket title, choose What: Case and When: Chat timed out, then add Change case subject with Support Request Created. Add Send notification and select Case contact to email the primary contact. Review the reply address, email subject and message. Leave Secondary contacts off for a confirmation only to the primary contact; Creator refers to the record creator and is not the customer recipient. The event itself does not send email. Test with a valid contact email and check both the case audit and the received message before activating the workflow.

Limit run times

Enable Limit run times to reveal Timezone, Permitted from, Permitted until, and Permitted days. Blank timezone means UTC. Blank time boundaries allow the corresponding start or end of the day. Select at least one permitted day: an enabled restriction with no days selected does not match.

These restrictions control when evaluation is permitted. They do not define the SLA clock. Overnight windows are not supported, and Asset workflows do not expose this restriction group.

Scheduled workflows

If an older schedule contains mixed or unset patterns, review the editor's explanation and cleanup confirmation. Do not assume opening and saving a historical rule leaves an ambiguous schedule unchanged.

SLA target settings

For the supported Case SLA events, configure SLA target (minutes) and SLA clock. Clock choices are 24/7 and Business Hours. Zero minutes is labeled Expired. Business-hours evaluation depends on the relevant schedule and holiday configuration.

Sticky SLA target is retained for compatibility but currently has no effect on SLA timing. Historical Target Resolution Time/Clock fields are read-only. Use the active SLA target and clock controls for current rules.

Survey settings

For Case / Survey sent, select an active Survey, the Wait after case closure delay, and Send frequency. Frequency choices are All the time, Random, Every second closed case, and Every third closed case. The delay picker provides defined intervals from 15 minutes through 7 days; select the labeled value that matches your follow-up process.

Requirements, alternatives, and exclusions

The picker is the reference for fields available to the selected event in your account. Company and Contact workflows do not expose the standard record-condition fields used by Case workflows. Up to ten new custom-field rows per rule/action group can be added in one save; custom-field actions are Case-only.

Some historical fields remain visible read-only. Owner counts, legacy article vote counts, email-form conditions, the legacy hashtag condition, scheduled stop fields, SMS sender, resolution targets, and view ID must not be treated as active automation controls merely because an old value exists.

Actions and notifications

Add only actions offered for the selected scope and event. Each action type can be configured once. The editor presents configured actions in their execution sequence; it does not provide an arbitrary drag-to-reorder control.

Jira, Support Level, Vendor Company, and legacy Template ID action controls are retired in this editor; retained historical values can be read-only. Do not build a new rule around a retired control.

Change case subject

For supported Case events, enter the exact title to store on the case, for example Support Request Created or Chat Converted to Support Case. Use one line of up to 250 characters. Leading and trailing spaces are removed; variable placeholders are stored as literal text. Removing or leaving this action blank preserves the existing subject.

The action runs after a case template and before workflow notifications. A real title change is recorded in the case audit. This changes the case title shown in My Tickets; the notification email subject is configured separately. Later workflows may change the title again, so review execution order and Stop When Hit.

Webhook actions

Enable the Webhook card, enter the destination URL, choose the supported event context, and select None, Basic, Bearer, or custom-header authentication. Prefer HTTPS for external endpoints.

Webhook context is available for supported Company, Contact, and Asset events and many Case events. It is unavailable for Article workflows and Case SLA, Scheduled, Survey sent, and Integration export events. The server validates compatibility when you save.

Asset workflow configuration

Where supported, Asset workflows expose event type, expiry days, Include expired, linked records, Only active linked assets, asset categories, Must have tags, and Must not have tags. Expiry days apply to Expiring or Expiring or expired modes.

A new asset configuration starts with Expiring, 60 expiry days, expired assets excluded, company-or-contact links, and active assets only. Create case starts enabled; notification and webhook start disabled. Review the case subject/summary, queue, ownership, and other enabled fields rather than relying on these starting values.

Dependent action groups include case creation, notification recipients/content, company/contact notes and support levels, and tag additions/removals. Case workflows can also contain linked-asset Requirements and Conditionals. Historical Division IDs remain read-only.

Recommendations

• Start narrowly: build a rule for one identifiable event and outcome. Expand only after matching and nonmatching tests behave as expected.
• Prefer explicit requirements: constrain broad events such as Updated to avoid repeated notifications or changes.
• Review chains: an action can trigger another event. Stop When Hit affects the current scope/event processing; it is not a universal loop-prevention switch.
• Separate clocks: document whether a time refers to UTC scheduling, permitted evaluation hours, or an SLA's business-hours clock.
• Verify delivery: a saved workflow or created activity does not prove an email, SMS, Slack message, or webhook was delivered.

Example: route urgent onboarding cases

1. Create an inactive Case / Created workflow named “Route urgent onboarding cases.”
2. Add Requirements for the intended onboarding queue and urgent priority, using values available in your account.
3. Add the supported owner/team or queue action needed by your routing process. Add a notification only if the receiving team needs a separate alert.
4. Review its order among other Case / Created workflows. Use Stop When Hit only if lower-priority rules should not run after this rule matches.
5. Save and activate it in a test environment. Create an urgent onboarding case, a normal-priority onboarding case, and an urgent case in another queue.
6. Confirm only the intended record receives the routing change. Review any subsequent workflow effects and notification delivery.

Troubleshooting

Detailed field reference

The complete field tables are organized into two companion articles: Workflow field reference: triggers and conditions and Workflow field reference: actions and exclusions. Search these titles in the knowledge base for the detailed field choices and availability.

Related configuration

• Organization → Queues, Teams, Roles, and Agent Status.
• Cases → States, Priorities, Templates, and Policy.
• Configuration → Custom fields and Messaging & Notifications.
• Calendar → Holiday schedules; Customer surveys → Survey forms.
• API → Webhooks; Integrations → the provider used by your actions.