TENSOR has two automation systems — workflow configuration tunes the state machines, business rules react to events. Keep them apart.

TENSOR deliberately separates two things that other platforms blur together:

Workflow configuration (Settings → Workflows) tunes the state machines — the states a record moves through and the transitions between them. You can relabel transitions, hide ones you don't use, add required fields, and raise approval quorums. You cannot invent transitions or weaken anything the platform requires.
Business rules (Settings → Rules) are event-driven automation — when an event matching your conditions occurs, then run actions: assign, set priority, notify, open a war room.

There is no drag-and-drop workflow canvas, and that is a design decision, not a gap. The states and transitions of incidents, problems, changes, and service requests are code — tested, audited, and impossible to misconfigure into a dead end. What a tenant configures is the dressing of that machine (labels, visibility, extra required fields, stricter approvals) and the reactions to its events. The result is that no tenant configuration can ever disable a compliance invariant like separation of duties.

A third mechanism, approvals, spans both: CAB quorums on changes, per-catalog-item approval steps on service requests, and the dual-approval flows that guard sensitive operations.

Which one do I want?

You want to…	Use
Rename "Submit for approval" to "Submit RFC"	Workflow configuration
Require a justification field before a change can be submitted	Workflow configuration
Require three CAB approvers instead of two for normal changes	Workflow configuration
Auto-assign new `software_access` incidents to the IAM team	Business rules (or category routing)
Page the incident manager when an SLA is about to breach	Business rules
Classify incoming P1 webhook incidents as DORA-major	Business rules
Notify the requester when their change is approved	Notification rules

Workflows and automation

Which one do I want?

On this page