> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/workflow/request-triggers.md).

# 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.