Automation & workflow

Three layers, one engine

Zentra has three surfaces on top of the same underlying execution engine:

• Workflow definitions (WorkflowDefinition) — multi-step processes with triggers, conditions, branches, and actions. The main automation surface.
• Scenario definitions (ScenarioDefinition) — manually-triggered automations the agent kicks off from the console.
• Automation rules (AutomationRule) — the legacy rule system; new automations should use workflows.

All three execute under the same security model and audit trail. Each execution is recorded on WorkflowExecution with inputs, outputs, and per-step timings.

Triggers

Triggers define when a workflow runs. Common trigger sources:

Trigger	Fires when
ticket.created	A new ticket arrives via any channel.
ticket.updated	Any field on a ticket changes.
ticket.status_changed	Status transitions (e.g. open → in_progress).
ticket.sla_breached	SLA timer expires.
change.approved	A change record completes its approval graph.
asset.lifecycle_changed	An asset transitions state (e.g. deployed → retired).
schedule.cron	Time-based trigger.
webhook.received	Inbound webhook hits a configured Zentra endpoint.

The full trigger catalog is exposed in the workflow editor.

Conditions

Conditions are boolean expressions over the trigger payload. The visual editor supports:

• Field comparisons: priority = "urgent", category in ["Network", "Identity"], requester.organizationId = "org_...".
• Asset and CMDB lookups: ticket.linkedAsset.criticality <= 1.
• Logical combinators: AND, OR, NOT, with explicit grouping.

Actions

Actions modify state, talk to other systems, or wait for input.

Category	Examples
Ticket	Set field, assign team or agent, transition status, add internal note, post reply, link, escalate.
Approval	Request approval (sequential or parallel), wait for outcome, branch on result.
Notification	Email (via configured SMTP), Slack channel/DM, Microsoft Teams channel/DM.
Outbound webhook	POST to a registered OutboundWebhook endpoint with HMAC-signed payload.
Asset	Update lifecycle, attach contract, schedule renewal alert.
Flow control	Wait, branch on condition, parallel block, terminate.

Example: escalate urgent tickets

WHEN  ticket.created
WHERE priority = "urgent"
        AND category = "Network"
THEN  set team           = "Network"
      add internal note  = "Auto-routed by urgency rule"
      notify slack       = "#incidents"

Example workflow: new joiner provisioning

A canonical multi-step process with approvals and integration actions:

1. Trigger: webhook from HR system on new joiner record.
2. Action: create three tickets — provision laptop (Field IT), create accounts (IAM), assign desk (Facilities).
3. Action: request approval from the joiner’s line manager.
4. Wait: until approval received, or 48 hours.
5. Branch:
   • If approved → mark all child tickets as ready and notify Field IT.
   • If rejected or timed out → notify HR and mark child tickets cancelled.
6. Action: schedule a 30-day check-in survey to the new joiner.

Approvals

The ApprovalRequest model is first-class and shared across changes, requests, and any custom workflow that needs gating.

• Approver scope — a specific user, a role, a group, or a dynamic expression (e.g. requester’s line manager).
• Order — sequential (each in turn) or parallel (any one suffices, or all must approve).
• Reminders — Nth-hour reminders before timeout.
• Decision channels — email, Slack notification, Teams notification, agent console.

Every decision is recorded on ApprovalDecision with user, timestamp, and optional comment, and is immutable.

Audit & versioning

Workflows are versioned. Every WorkflowExecution records the workflow version that ran, the inputs, the path taken, and the outputs of every action — so you can answer “what happened to this ticket and why” long after the fact.

Next

• Integrations — connect Slack, Teams, and SMTP for actions to use
• Webhooks & API — trigger workflows from external systems
• Service desk — where most workflows deliver their value