Automations

Overview

Core Automations let you build workflows that run automatically based on a trigger (what happened) and a set of actions (what to do next).

You can use automations to:

• Create tickets from inbound emails (including parsing common alert formats)
• Notify your team when important ticket events happen
• Route work by assigning a technician automatically
• Integrate with external systems via webhooks
• Run on a schedule for recurring operational workflows

Where to manage automations

In the main app navigation, go to Automation. From there you can:

• View all automations and their recent execution stats
• Create a new automation
• Browse Automation Templates to start from a pre-built workflow
• Review execution history (including failures and retries)

Creating an automation

1. Navigate to Automation
2. Click New Automation
3. Set:
   • Name (required)
   • Description (optional, but recommended)
   • Active/Inactive toggle
4. Click the trigger node to Select Trigger, then configure it
5. Add one or more Actions (steps) and configure each step
6. Click Create Automation

Triggers

Email Received

Use this when you want Core to react to inbound emails (alerts, contact forms, monitoring systems, etc.).

You can configure:

• From Address: limit this automation to a specific sender (exact email or regex pattern). Leave empty to fire on every inbound email.
• Subject Pattern (Regex): limit this automation to subjects matching a regex. Leave empty to fire on every subject.

Everything else — parsing the email body, detecting service-account senders, extracting structured fields — happens automatically before your steps run. Your downstream actions can reference email.from, email.subject, email.body_text, email.is_service_account, email.service_contact_id, and email.parsed.* directly.

New workspaces ship with a working "Email received" automation: a locked system step that routes service-account senders (NinjaOne, Defender, etc.) at ingest, followed by customer-editable Resolve Contact and Create Ticket steps. Tweak those steps, add your own, or start from scratch.

Test against a past email. On any of your customer steps in an email automation, hover the step and click the flask icon in the row menu to replay a past email-sourced ticket through the saved automation. You'll see whether the trigger would match, the resolved contact, and what the ticket would look like — without writing anything.

Ticket Event

Use this when you want Core to react to ticket lifecycle events. You can choose an event like:

• Ticket created / updated
• Status changed
• Priority changed
• Technician assigned / unassigned

You can also add optional conditions so the automation only triggers when the ticket matches your criteria.

Schedule

Use this when you want an automation to run on a recurring schedule.

Options include:

• Cron expression (with common presets)
• Fixed interval (run every X minutes)
• Timezone (IANA identifier, e.g. America/New_York)

Webhook

Use this when you want Core to expose an endpoint and run an automation when it receives an HTTP request.

You can configure the expected HTTP method. Payload validation may be added over time.

Actions

Actions are the steps Core runs after a trigger matches. Available actions include:

• Create Ticket
• Send Email
• Send Notification
• Call Webhook
• Assign Technician

Some actions may appear in the builder but have limited configuration while still under development.

Using variables in actions

In action editors you can click Insert Variable to include values from the trigger data — or from earlier steps in the same automation — in your action fields (title, description, message bodies, webhook payloads, etc.). Once inserted, variables appear as labeled pills (e.g. "Email Subject") rather than raw {{...}} syntax.

The picker groups variables by source:

• Triggering event — data from whatever kicked off the automation. Email trigger: {{email.subject}}, {{email.from}}, {{email.body_text}}. Ticket trigger: {{ticket.id}}, {{ticket.priority}}, {{ticket.status}}. Parsed email fields: {{parsed.email}}, {{parsed.description}}, {{parsed.first_name}}.
• Previous step — output of the step that runs immediately before this one. For example, after a Resolve Contact step you can use {{last_result.customer_id}} and {{last_result.contact_id}} in the following action.
• Earlier steps — output of any non-immediate prior step, addressed by its ID: {{results.step_abc123.ticket_number}}.

Below the fields, a Preview pane shows how each field will render when the step runs, using values from the automation's most recent successful run. If the automation hasn't run yet, example values are shown instead.

Testing an automation

From an automation, click Test to simulate a trigger event using sample data (or your own JSON). This lets you confirm:

• Whether the automation would match
• Which actions would run
• What parsed trigger fields look like

Retry configuration

You can configure automatic retry behavior for each automation to handle transient failures:

• Max Retries: How many times to retry a failed execution (0-5)
• Retry Delay: Initial delay in seconds before the first retry (15-300 seconds)
• Backoff Multiplier: How much longer each retry waits (1.0x-3.0x)

For example, with a 60-second delay and 1.5x multiplier:

• First retry: waits 60 seconds
• Second retry: waits 90 seconds (60 × 1.5)
• Third retry: waits 135 seconds (90 × 1.5)

Configure retry settings from the automation header menu. Failed executions will automatically retry according to these settings, or you can manually retry from execution history.

Execution history, failures, and retries

Every run of an automation is logged as an execution. In execution history you can:

• Filter by status (success / failed / skipped / retry states)
• Expand an execution to inspect input data and results
• Export executions to JSON or CSV
• Retry a failed execution, or cancel a pending retry

If you see repeated failures:

• Verify the trigger matches what you expect (patterns, event type, conditions)
• Check variable usage in actions (missing fields can lead to empty values)
• Use Test with a real payload to reproduce and adjust safely
• Review and adjust retry configuration if failures persist

Best practices

• Start inactive, test, then enable once results look correct.
• Keep triggers narrow (patterns + conditions) so you don’t create noisy automations.
• Use variables to avoid hardcoding and to include context in tickets/notifications.
• Prefer templates for common workflows, then customize.

See also

• Managing Tickets
• Ticket automations