Workflows

PSA → Workflows is the single home for everything that fires automatically when something happens on a ticket. Three pages live underneath:

• Workflows — every "when X, do Y" rule, yours and the built-in system notifications together. One list, nothing hidden.
• Email templates — reusable email bodies your workflows send. One screen for all of them, system and custom.
• Scheduled tickets — recurring tickets created automatically on a cadence.

If you're coming from an older version of OpsMerge and look for "Settings → PSA → Notifications", the separate "Notifications" page, or the old "Email templates" page under Workflows — the URLs all redirect here. There is no longer a split between "automation rules" and "notification rules"; a rule is a rule, whatever its actions do.

Workflows (ticket rules)

A rule has three parts:

1. Trigger — what kicks it off. Seven choices:
   • ticket.created — a new ticket lands (from email, portal, API, or manual creation).
   • ticket.updated — a field changes on an existing ticket.
   • ticket.commented — someone posts a comment (public or internal).
   • ticket.sla_warning — the ticket is approaching an SLA breach.
   • ticket.scheduled_stale — the ticket has been idle for N days (you set N).
   • ticket.scheduled_customer_silence — the ticket is waiting on the customer and they haven't replied for N days.
   • ticket.scheduled_resolved_aging — the ticket has sat in Resolved for N days with no customer reply.
2. Conditions — a tree of AND/OR groups. Each leaf compares one ticket field (status, priority, client, queue, requester, subject, etc.) with an operator (=, !=, in, is_empty, and so on). Leave the conditions empty and the rule matches every event of its trigger kind.
3. Actions — what to do. Thirteen choices, each with its own form:
   • send_email — pick an email template and one or more recipients (literal address, {{.requester_email}}, {{.watchers}}, etc.).
   • send_webhook — POST a JSON payload to a URL you supply.
   • assign_to_user, assign_to_team, assign_round_robin — change the assignee.
   • set_status, set_priority, set_category — patch the ticket (closing a ticket is set_status → Closed).
   • add_note — append an internal note as the rule's audit trail.
   • escalate_to_team — bump the ticket up the priority + assignment chain.
   • create_child_ticket — spin off a related ticket linked back to this one.
   • run_ai_action — sentiment, summarise, draft reply, or classify.
   • spawn_project_from_template — kick off a project using a template.

The list shows each rule with its trigger, last-fired timestamp, and a toggle. Built-in system notifications carry a System badge — they're ordinary rules underneath, so you can open them, see exactly what they do, and tune when they fire. System rules can't be deleted, only disabled.

Click into a rule to edit conditions or actions; the dry-run panel on the right lets you test the rule against an existing ticket before you save.

Worked example — chase a silent customer, then close

Ticket is Waiting for Client. After 4 days, email the customer and note the ticket. After 10 days of continued silence, close it.

Two rules:

1. Chase. Trigger ticket.scheduled_customer_silence, silence days = 4. Actions: send_email (your "Are you still there?" template, recipient {{.requester_email}}), add_note "Chase email sent automatically." Max fires per ticket = 1.
2. Close. Trigger ticket.scheduled_customer_silence, silence days = 10. Actions: send_email (your "Closing due to no response" template), set_status → Closed. Max fires per ticket = 1.

Worked example — greet new email tickets and tell the team

New ticket comes in by email: acknowledge the sender and notify the support inbox.

The acknowledgement half already exists — enable the Auto-acknowledge new email ticket system rule and edit its template to taste. For the team notification, add a rule: trigger ticket.created, condition source_type = email, action send_email to [email protected].

Rule guards

• Cooldown — minimum gap between fires per ticket (e.g. 3600 seconds = "don't fire on this same ticket more than once an hour").
• Max fires per ticket — lifetime cap (e.g. 1 = "fire exactly once, ever, for this ticket"). This is the "send once per ticket" control.
• Email sending panel (shows when the rule has a send_email action):
  • Throttle (seconds) — per-recipient minimum gap for this rule's emails. Stops a busy ticket mail-bombing one address.
  • Business hours — only send between the hours/days you set, in the timezone you set.

Email templates

PSA → Workflows → Email templates lists every reusable email body a workflow can send — the built-in system ones (badged System) and your own. Create, edit, and delete from one screen. System templates can be edited (subject and body) but not renamed or deleted.

Each template is just content:

• Name — what you'll pick in the Send email action.
• Subject — the email subject line, with placeholders.
• Body — rich-text HTML body.

When it fires, how often, and to whom is the workflow's job, not the template's — those controls live on the rule.

Variables

The editor's Available variables panel lists every placeholder, grouped (Ticket / People / Client & organisation / Comment). Click one to copy it, then paste into the subject or body. Templates use Go template syntax with flat, single-dotted names. Highlights:

• {{.ticket_ref}} — the human ticket reference, e.g. "INC-1042".
• {{.ticket_number}} — the short threading id used in subject prefixes (see below); not the human reference.
• {{.ticket_subject}}, {{.ticket_status}}, {{.ticket_priority}}, {{.ticket_url}}
• {{.requester_name}} / {{.requester_email}}, {{.assignee_name}} / {{.assignee_email}}
• {{.inbound_sender_name}} / {{.inbound_sender_email}} — the original email sender.
• {{.client_name}}, {{.org_name}}, {{.support_email}}
• {{.comment_body}} / {{.comment_body_html}}, {{.comment_author_name}} — for ticket.commented rules.
• {{.watchers}} — expands to the watcher email list (used as a recipient, not a body variable).

Unknown variables render empty. Use the dry-run panel on the rule editor to see exactly what gets rendered before you save.

Subject prefix and threading

Keep [#{{.ticket_number}}] in the subject of any client-facing template. Without it, client replies don't thread back correctly when no Reply-To match exists — the inbound matcher parses that [#<id>] token from the subject as a fallback. Use {{.ticket_number}} here, not {{.ticket_ref}}: the human reference is display-only and isn't recognised by the threading parser.

System notifications

Three built-in notifications ship as System-badged rules in the Workflows list, disabled by default:

System rule	Fires on
Auto-acknowledge new email ticket	Inbound email creates a new ticket
Notify requester on public reply	Staff posts a public comment
Notify assignee on comment	Anyone other than the assignee comments

Each pairs with a System email template on the Email templates screen. Edit the template for the wording; open the rule for the firing behaviour (enable, throttle, business hours, max sends). Watcher notifications are handled by a separate always-on worker and don't appear as a rule.

RFC 3834 mail-loop guard

Inbound mail flagged Auto-Submitted: auto-replied or Precedence: bulk (out-of-office replies, mailing lists, other auto-responders) is detected on receipt. The auto-ack rule sees the flag and skips the outbound — preventing the infamous "out-of-office bounces auto-ack bounces out-of-office..." loop. You don't have to configure this. It's on. As a second line of defence, the auto-ack keeps a 6-hour per-recipient throttle even if you clear the rule's throttle setting.

Monitoring workflows

A separate engine fires on RMM events rather than PSA tickets. It lives at Monitoring → Workflows. Triggers there are check_failure, agent_status, eventlog, schedule, and webhook_inbound. Actions include run_script, create_alert, fire_webhook, and create_ticket — so a check failing can create a PSA ticket which a rule on this page then reacts to.

Full reference at Monitoring → Workflows.

Audit log

Every rule firing writes a row to ticket_rule_runs capturing:

• Which rule fired
• Which ticket it matched
• Timestamp
• Per-action outcome (success / error / skipped) with detail
• Whether it was a dry-run preview or a real fire

The audit drawer on each rule's edit page is the way to view this. A dedicated org-wide audit page is on the roadmap.

Common patterns

"Auto-ack should look like our brand"

PSA → Workflows → Email templates → the System-badged auto-acknowledge template. Edit the subject and body. Keep the variables that matter ({{.ticket_ref}}, {{.ticket_url}}) and the [#{{.ticket_number}}] subject prefix so replies still thread.

"Different auto-ack per client"

Don't edit the system auto-ack. Instead, create a rule: trigger ticket.created, conditions client_id = X AND source_type = email, action send_email with a client-specific template. Give it a lower priority number than the system auto-ack and enable Stop processing so the generic ack doesn't also fire.

"Round-robin assignment within a team"

New workflow. Trigger ticket.created. Conditions: whatever filters this to the team's relevant queue. Action: assign_round_robin.

Migration from older versions

• The Workflows landing page, the separate Notifications page, and the old Email templates page are gone — everything is on the three pages above. All old URLs redirect.
• Settings → PSA → Rules → PSA → Workflows. Legacy URL still redirects.
• Alerts → Templates → still there, for asset-alert templates only.
• Rules that only sent email used to be re-filed onto a separate "Notifications" surface automatically. That behaviour is gone: a rule stays on the Workflows list whatever its actions are.

Common issues

A rule fires but the email doesn't arrive. Check the per-rule audit drawer. If the action shows "auto-reply suppressed", the RFC 3834 guard fired, the rule's throttle or business-hours gate applied, or the recipient was on the noreply pattern blocklist. If it shows a render error, check the template syntax in the dry-run panel.

"Template not found" in the audit. The rule's send_email action refers to a template that was deleted. Open the rule, repick a template. (Templates picked since the 2026-07 update are referenced by id, so renaming a template no longer breaks the rules that send it.)

My asset-alert template doesn't appear under Email templates. Correct — asset-alert templates power the RMM alert engine and live at Alerts → Templates.

Variables show literal {{.ticket.subject}} in the email. Variables are flat, single-dotted ({{.ticket_subject}}, not {{.ticket.subject}}). The Available variables panel in the template editor has the exact names — click to copy.

Next

• Notifications — conceptual flow of ticket email notifications
• Connected mailboxes — outbound mechanics, how rendered emails leave the building
• Scheduled tickets — recurring tickets on a cadence
• Tickets — the things rules act on