Skip to main content
Workflows & automation

Business rules

Event-driven when/then automation — twelve triggers, eleven operators, and a dry-run mode that shows what a rule would have done.

Settings → Rules (permission settings.tenant.update) is TENSOR's automation builder. A rule is declarative: when a trigger event occurs and all conditions match, then run the actions. There is no scripting and no expression language — a rule can only do what the closed catalogs of triggers, operators, and actions allow, which is what makes rules safe to audit and impossible to hide logic in.

Triggers

Twelve events can trigger a rule. Each exposes a fixed set of condition fields — the form only offers fields that exist on that event:

TriggerExample condition fields
incident.createdtitle, category, severity, priority, reporter kind, affected CIs, assignment group
incident.updatedstate, assignee, priority, severity
incident.transitionedfrom state, to state, severity, priority
change.submittedchange type, risk score, scheduled start, requester
change.approvedchange type, risk score, requester, implementer
change.implementingchange type, implementer
problem.createdtitle, category, priority
problem.transitionedfrom state, to state, priority
service_request.createdtitle, request model, requester
sla.breach_warningSLA definition, ticket type, remaining %
sla.breachedSLA definition, ticket type
incident.sentiment_deterioratedaverage score, sample count, confidence

Conditions

All conditions must match (they are AND-ed — the form says "When (all conditions must match)"). Operators: equals, not equals, greater/less (and or-equal variants, numbers only), in list, not in list, contains, starts with, and exists.

Actions

ActionWhat it does
Assign to groupSets the assignment group
Assign to userSets the assignee
Set prioritySets P1–P4
Classify as DORA majorRuns the major-incident classification (only offered when the dora_major_incident_classification flag is on)
Dispatch notificationSends an in-app or email notification to a user or address, optionally from a template
Create war roomOpens a war room on the incident

Actions run independently — one failing action does not cancel the rest, and each action's outcome is recorded. Everything a rule changes is attributed to the system service account in the audit log, so rule-driven mutations are always distinguishable from human ones.

Dry run and testing

Two safety mechanisms, use both:

  • Test payload — in the rule form, paste a sample event payload and see per-condition match results before saving anything.
  • Dry run — a saved rule can run in dry-run mode: it matches and logs (rule would fire) but never mutates. Watch the audit log for a few days, then flip Go Live.

Rules are versioned — every edit increments the version — and can be disabled without deleting.

Sentiment escalation

The incident.sentiment_deteriorated trigger fires when a ticket's recent inbound messages trend negative (by default: the last three samples average below −0.3 at high confidence). Treat it as a hint to get a human's eyes on the ticket — the score is an explicitly imperfect signal, not a verdict — and pair it with a dispatch notification or assign action rather than anything irreversible.