> For the complete documentation index, see [llms.txt](https://support.suptask.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.suptask.com/suptask-ai/dynamic-ai-approvals.md).

# Dynamic AI Approvals

Let the Assistant find the right approver in your other systems

Every approval in Suptask used to start with a list of names. Someone decided in advance who signs off, and that list was the same for every ticket.

An AI Assistant turns that around. It reads the request, looks up who should approve it - the requester's manager in Google Workspace, their HR partner in BambooHR, the owner of the app they're asking for - and sends the approval to that person. Nobody configures the approver; the Assistant finds them, every time, for that specific ticket. Then it waits for the answer and finishes the job.

{% hint style="success" %}
**For example**\
An employee requests access to Salesforce. The Assistant finds their manager in your directory, asks them to approve, and when they say yes, adds the employee to the right group and tells them it's done. No agent touched the ticket, and the right manager was asked every time, regardless of who submitted it.
{% endhint %}

{% hint style="warning" %}
AI Assistants are a part of the Custom plan. Contact Suptask to get started.
{% endhint %}

***

### Where the approver comes from

The approver is whoever the Assistant found earlier in its workflow. Any connected system that knows who's responsible for something can supply the name:

| Who should approve                     | Where the Assistant finds them                                            |
| -------------------------------------- | ------------------------------------------------------------------------- |
| The requester's manager                | Google Workspace Admin, Microsoft Entra, Okta, BambooHR, HiBob, HaileyHR  |
| The owner of a system or app           | A Field in the ticket, a knowledge document, or a group in your directory |
| The person responsible for a device    | PDQ Connect                                                               |
| A team lead or department head         | Your HRIS or user directory                                               |
| A fixed reviewer, plus the dynamic one | Pick the fixed person; the Assistant adds the other                       |

The pattern is always the same: a task looks the person up, saves their Slack user ID in a variable, and the approval step reads that variable. See [Write instructions for your Assistant](https://support.suptask.com/suptask-ai/use-cases-library/write-instructions-for-your-assistant) for how variables work.

```
Find @Requester Email in Google Workspace Admin and fetch the manager's
email. Store it in @managerEmail. Look up the manager's Slack user from
@managerEmail with @Lookup User By Email and store it in @managerSlackId.
```

You can also pick specific people by name, or do both - a security lead who always reviews, plus whoever the Assistant finds. Up to 10 approvers, and everyone listed must approve.

If the Assistant can't find the person - the lookup came back empty, or they aren't a user in your Slack workspace - it stops and tells the requester rather than sending the approval to nobody.

***

### How it works

An approval is a step in the Assistant's workflow, placed between the tasks you've written.

1. **The Assistant does the groundwork.** It runs the tasks before the step - reads the request, finds the approver, gathers what they'll need to decide.
2. **It pauses and asks.** Each approver gets a Suptask approval in Slack with the reason you wrote. They approve or decline from the notification, and can open the ticket for context.
3. **It continues.** Once everyone has decided, the Assistant follows your instructions for the outcome - one set for approved, one for declined.

The approval itself is a normal Suptask approval: the approver experience, audit trail and ticket history are the same as for any other [Approval](https://support.suptask.com/working-with-tickets/for-agents-who-respond-and-manage-tickets/how-to-send-and-manage-approvals). What's different is who gets it, and what happens next.

***

### What approvers see

Write the reason as a message to the approver. Type `@` to insert details from the ticket or a variable the Assistant saved, so they can decide without opening the ticket.

```
@Requester Name is asking for access to: @fieldApp
```

***

### After the decision

Each approval step has two sets of instructions, **When approved** and **When declined**, written the same way as workflow tasks.

**When approved** is where the Assistant completes the change - the part that previously needed an agent.

```
Add @Requester Email to the requested group with @Add Member. Move the
ticket status to Resolved and tell the requester using
@Post Message Requester that access has been granted.
```

**When declined** is usually a short message back and a status change.

```
Tell the requester using @Post Message Requester that the request was
not approved. Move the ticket status to Closed.
```

#### Letting the Assistant finish on its own

Tools that change data are normally set to **Ask**, so an agent confirms each action. After an approval, that second confirmation is redundant - the approver already said yes.

Under *When approved*, list the tools the Assistant may use **without asking again**. For the rest of that run those tools behave as if they were on Auto; everything else keeps its normal mode. The safe default stays - a human approves every change - but the approved path runs end to end with no agent involved.

#### Waiting or continuing

By default the Assistant waits for the decision. Set the step to **No, continue** if the approval shouldn't block the rest of the work - the Assistant moves on to the next task and runs the approved or declined instructions when the decision comes in.

***

### Walkthrough: access requests approved by the manager

This setup handles tickets from an *Access Request* Form. The Assistant finds the requester's manager in Google Workspace Admin, sends the approval to them, and resolves or closes the ticket depending on the answer.

**Connectors**

* **Google Workspace Admin** - or Microsoft Entra, Okta or your HRIS, wherever reporting lines live. User lookup tools on Auto.
* **Slack** (built in) - *Lookup User By Email* and *Post Message Requester* on Auto.
* **Suptask Ticket Management** - *Update Ticket* on Ask.

**Example Base instructions**

```
Manage incoming access requests and send approvals.
```

**Variables**

| Name             | Description            |
| ---------------- | ---------------------- |
| `managerEmail`   | Manager email          |
| `managerSlackId` | Manager Slack ID       |
| `fieldApp`       | Applications requested |

{% hint style="info" %}
fieldApp picks up Applications from a field in the configured Form. The requester can select one or more applications to request access to in the Form, these applications are stored in the fieldApp variable to make them visible to the approver in the approval message.
{% endhint %}

**Workflow**

Task 1:

```
Find @Requester Email in Google Workspace Admin and fetch the manager's
email. Store it in @managerEmail. Look up the manager's Slack user from
@managerEmail with @Lookup User By Email and store it in @managerSlackId.
From the ticket, store the selected values from the field "Application"
in @fieldApp.
```

Approval step 2:

* **Approvers:** from variable `@managerSlackId`
* **Reason:** `Please review the access request for these apps: @fieldApp`
* **Wait for the decision:** Yes, pause
* **When approved:** `Move the ticket status to Resolved.` Allow *Update Ticket* without asking again.
* **When declined:** `Tell the requester using @Post Message Requester that this was not approved.`

**Activation:** Ticket created, limited to the *Access Request* Form.

Swap the first task to change who approves. "Find the owner of @fieldApp in the Application Owners document" sends it to the system owner instead of the manager; "fetch the requester's HR partner from BambooHR" sends it to HR. The approval step stays the same.

***

### Automation rules or AI Assistants?

Both can request approvals when a ticket comes in. Use an [Automation](https://support.suptask.com/integrations-automations-and-workflows/how-to-set-up-automation-rules) when the approvers are always the same people for a Form or Inbox - it's simpler and needs no AI. Use an Assistant when the approver depends on who's asking or what they're asking for, or when something should happen automatically after the decision.

***

### Good to know

* Add approval steps with **Add approval** below the workflow tasks. Steps can be reordered by dragging, and an approval can sit anywhere in the workflow.
* Decisions are recorded on the ticket like any other approval and show in the ticket's history.
* If an approval has no *When declined* instructions, the Assistant stops after a decline and leaves the ticket for an agent.

***

### Related articles

{% content-ref url="/pages/78LTRipFdHG0TYwuKQZF" %}
[Approvals](/working-with-tickets/for-agents-who-respond-and-manage-tickets/how-to-send-and-manage-approvals.md)
{% endcontent-ref %}

{% content-ref url="/pages/EMXzCysY1oz2JPFXI8gH" %}
[AI Assistants](/suptask-ai/ai-assistants.md)
{% endcontent-ref %}

{% content-ref url="/pages/RHp6timCpwHDqb9OkFNd" %}
[Write instructions for your Assistant](/suptask-ai/use-cases-library/write-instructions-for-your-assistant.md)
{% endcontent-ref %}