Automations run configured actions when an email, ticket event, schedule, webhook, or device-policy check matches its trigger. Open Automation to manage workflows, browse templates, and review execution history.

Create a workflow

Open Automation and choose New Automation.
Enter a name and optional description.
Select and configure the trigger.
Add actions and configure the fields each needs.
Save with Create, or Submit for review if you are a technician.

Only workspace admins can activate or deactivate automations. A technician's submission stays inactive as Pending review until an admin activates it. Its submitter can edit it while inactive; other technicians cannot edit it.

Some workflows and leading system steps are locked because Core needs them for ticket ingestion. Add or edit the customer-controlled steps around them.

Choose a trigger

Trigger	Use it for
Email Received	Inbound email that matches sender and subject patterns
Ticket Event	Ticket creation, updates, status or priority changes, assignment, unassignment, or the first detailed customer reply
Schedule	Recurring work using a cron expression, interval, and timezone
Webhook	Requests sent to the workflow's signed endpoint
Device Policy Violation	Device policy checks such as OS compliance or hardware age

Ticket-event workflows are unique per event. If an event is already in use, the trigger picker opens its existing workflow. Add conditions or Path branches there instead of creating a competing workflow. Device-policy workflows are also unique; email, webhook, and schedule workflows can have separate configurations.

Run on a schedule

Choose an interval or a five-field cron expression and a timezone. Cron schedules honor the minute, hour, day of month, month, and weekday. For example, 0 9 * * 1-5 runs weekdays at 9am in the selected timezone, including daylight-saving changes. A local time skipped when clocks move forward does not run that day. A repeated local time when clocks move back can run twice.

Activating a schedule sets its next run. Changing the schedule recalculates that time; deactivating it clears the next run. Core checks for due work every minute, so runs can begin after their scheduled time. Each due run targets its own workflow.

Settings → Policies → Automatic Violation Tickets uses the same scheduler. Its checks start weekdays at 9am in America/New_York and continue in batches when more devices need tickets. Rate limits defer remaining work to a later check.

Route inbound email

New workspaces include an email workflow. Review it before creating an additional rule.

From Address limits the sender by exact address or regex; empty matches all senders.
Subject Pattern limits the subject by regex; empty matches all subjects.
Parsed email values are available to later steps, including sender, subject, text body, service-account context, and parsed fields.

Email Received runs before the default ticket exists. To update that ticket, use the Ticket Created workflow. Alternatively, create a ticket within the email workflow and target that step's result.

On a customer-editable step, choose Test with past email using the flask control. Select an email-sourced ticket to replay the saved workflow without writes. The preview shows the trigger match, contact resolution, and proposed ticket.

Add actions and paths

Actions include Create Ticket, Update Ticket, Transform Ticket Title, Add Comment, Assign Technician, Send Email, Send Notification, Call Webhook, Request Approval, Send Survey, Service Account Routing, and Core AI Triage.

Assign Technician can assign a specific technician, rotate through staff (round robin), pick the least busy technician, or use the company's primary and secondary technicians. Round robin, least busy, and primary/secondary pick technicians who are within their working hours first. When no one in the pool is on shift, urgent and high priority tickets go to whoever is on call in the team calendar, or to the After-hours dispatcher you choose if no one is on call. Other tickets are assigned as usual. With no one on call and no dispatcher, every ticket is assigned as usual.

Send Notification can target a specific staff user, a role, internal followers, external followers, or all followers of a ticket. Choose in-app notifications, email, or both. External followers receive email only. Results distinguish queued emails, created inbox alerts, and skipped recipients.

To notify copied contacts when a ticket opens, add Send Notification to a Ticket Created workflow, choose External followers, and select email. Creation notifications to followers stay off until you configure and enable that workflow. An existing contact with active portal access can open tickets they follow and participate in the public conversation. Copied email addresses never create contacts or portal accounts automatically. Outside vendors can remain email-only recipients.

Use Path to branch on conditions. The first matching path runs. Keep conditions narrow enough that the intended branch is clear, and review the action order because later steps can use earlier results.

Transform Ticket Title supports regex find/replace and a sample preview. Core AI Triage can suggest ticket classifications and optionally related knowledge, fixes, or a runbook. Review each action's editor for its available settings.

When categories use support levels, Core AI Triage uses the ticket's required skills and scope. L1 covers checklist setup and checks, L2 standard administration and troubleshooting, and L3 advanced diagnosis and recovery. Architecture and environment-wide recovery use Senior when available, or the highest suitable advanced level. Other category schemes use domain fit. Priority remains separate; customer identity, SLA, and vendor names alone do not raise the level.

Insert variables

Use Insert Variable in action fields to add data from the trigger or earlier steps. Variables appear as labeled pills in the editor.

Triggering event: {{email.subject}}, {{email.from}}, {{email.body_text}}, or ticket fields such as {{ticket.id}}.
Previous step: {{last_result.customer_id}} or another output of the immediately preceding step.
Earlier steps: {{results.step_abc123.ticket_number}}, using that step's ID.

The preview uses the latest successful run when available, or example data otherwise. A missing source value can leave a field empty, so check the preview and execution input before enabling a workflow.

Receive a signed webhook

After saving a Webhook trigger, Core provides its Webhook URL and Signing secret. The request method must match the configured method.

Every request needs an HMAC-SHA256 signature of the raw body, computed with the signing secret:

x-webhook-signature: <hex-encoded HMAC-SHA256>

Core also accepts x-hub-signature-256. Requests without a configured secret, without a signature, or with an invalid signature receive HTTP 401. Keep the secret in the sending system's secret store.

For outbound requests, add Call Webhook and configure its URL, method, headers, and body. Use variables to include the triggering record or prior action result.

Review executions and retries

Open the workflow's execution history to filter results, inspect input and action output, and export JSON or CSV. Failures that Core identifies as safe to repeat retry automatically when the workflow has retries enabled. The same execution records its retry status and action results.

Configure retries from the header settings:

Max retries: 0–5.
Retry delay: 30 seconds, 1 minute, 5 minutes, 15 minutes, or 1 hour.
Backoff: 1×, 1.5×, 2×, or 3×.

For a 60-second delay and 1.5× backoff, successive waits are 60, 90, and 135 seconds. Core checks due retries every minute, so these are minimum waits. Set Max retries to 0 to disable automatic retries. Disabling a workflow stops its pending retries.

Retries retain the original input and action configuration, resume failed actions, and reuse successful results. Completed actions do not run again. An interrupted action or an error after a possible external write stops the run for inspection. Core does not repeat an action whose outcome is unknown. Check the destination service before repeating work manually.

If a workflow does not behave as expected, inspect its active status, trigger conditions, variable values, and action results. Use the read-only past-email preview for email rules; use a deliberately scoped test record for other workflows and review its actual execution.

Automations