Request triggers

Request triggers start an automation when something happens on a request. Use them for intake routing, approvals, escalations, and auto‑close flows. They’re the fastest way to remove manual steps from day‑to‑day support.

Available triggers

• Request submitted: Fires when a new request is created (from Slack/Teams, portal, email, or API).

• Request resolved: Fires when a request is marked Resolved.

• Requester message is received: Fires when the requester replies.

• Admin message is sent: Fires when an agent replies publicly.

• Tag is added: Fires when a specific tag is applied.

• Request marked as In progress: Status change to In progress.

• Request marked as Waiting: Status change to Waiting (often used to pause SLAs).

• Request snoozed: A snooze is set.

• Request snooze expired: A snooze ends.

• Request reopened: Status returns to Open from Resolved/Closed.

• SLA breached: A first reply or resolution target has passed.

• Requester unresponsive: Requester hasn’t replied within your threshold.

When to use

• Intake and triage: auto‑assign, set priority, tag, and send acknowledgements when a request is submitted.

• Approvals and provisioning: start manager/app‑owner approval and, on approval, provision access.

• SLA guardrails: escalate before/after breach; notify team leads; raise priority.

• No‑response and housekeeping: remind, auto‑close, or reopen with the right status and notes.

• Major incidents: when a tag is added (“incident”), create a swarm channel and open tracker issues.

Conditions you can add

• Request fields: service (Associated to), status, priority, inbox, assignee, channel, tags, created/updated dates, SLA state....

• Requester attributes: department, location, manager, contract type, job title/level, legal entity...

• Service form answers: any field you added to the service form (e.g., target app, office).

Common workflows

• Auto‑triage and route

  • Trigger: Request submitted

  • Conditions: Associated to = “App access”, Department = Sales

  • Actions: Assign to IT Ops inbox, set priority = Low, send acknowledgement template

• Approval → provision → notify

  • Trigger: Request submitted

  • Actions: Start manager approval → Path 1 (Approved): Okta “Add application to user”, DM requester. Path 2 (Declined): set status Waiting, send decline message

• Escalate on SLA risk

  • Trigger: SLA breached

  • Actions: Increase priority, post to #it‑ops, assign to team lead

• Auto‑close no response

  • Trigger: Requester unresponsive

  • Actions: Send reminder; after n days set status Resolved with resolution note

Best practices

• Name clearly: “IT — App access — Request submitted.”

• One workflow per use case per trigger. Avoid collisions; use conditions for specialization.

• Add a tag (“auto‑provisioned”) for reporting impact.

• Keep steps readable. Use Paths for exceptions only.