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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.siit.io/workflow/request-triggers.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.