> 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/guides/data-management/how-to-add-sequential-approval-rounds-to-an-approval-policy.md).
# Add sequential approval rounds
Add sequential rounds to an Approval Policy, control their order, and see what happens when a round is rejected and when app access provisioning fires after the final round
### What this guide helps you achieve
* Add more than one round of approval to an Approval Policy
* Control the order rounds run in
* Understand what happens when a round is rejected
* Know exactly when provisioning fires
### Where to find it
`Settings → Approval Policies → [Policy] → Add round`
### How it works
* Round 1 runs first. Once every approver in Round 1 signs off, Round 2 starts automatically.
* If Round 1 is rejected, Round 2 (and any round after it) is cancelled. Nothing downstream is ever triggered.
* App Access provisioning is held until the final round is approved. As long as any round is pending, nothing is granted.
### Steps
1. Go to **Settings**, then **Approval Policies**, and open the policy you want to edit.
2. In **Round of approval 1**, click **Select approvers** and choose who signs off first (a specific person, a team, an inbox, or a dynamic role such as App owner).
3. Set the approver mode for that round (for example **All users**) to control whether every member of the group must approve or a single decision is enough.
4. Click **Add another round of approval** to add a second round. Siit labels it automatically to show the dependency, for example "Round of approval 2, triggered once round 1 is approved."
5. Repeat for as many rounds as the policy needs.
6. Click **Save**.
### Example use case
A Salesforce admin Role needs sign off from the App owner, then Finance, since the license carries a cost. The policy is configured with two rounds: Round 1 is the App owner, Round 2 is Finance, triggered only once Round 1 is approved. If the App owner rejects the request, Finance never sees it.
### Common pitfalls
* **Adding rounds in the wrong order.** Rounds run strictly in the order they appear in the policy, so double check the sequence before saving.
* **Expecting partial provisioning.** Access is not granted after an early round approves. It only fires once every round in the policy has signed off.
### Best practices
* Reserve multiple rounds for higher risk apps or higher cost access. A single round is still the right call for low risk, high volume requests.
* Keep the round count reasonable. Each extra round adds latency for the requester, so only add one when a distinct stakeholder genuinely needs to weigh in.
### Availability
Pro plan.
### Frequently asked questions
**What happens if I only need one approver?** You don't have to add a second round. A policy with a single round behaves exactly as it did before this update.
**What happens if a round is rejected?** Every round still waiting behind it, is cancelled automatically, and the request is marked rejected. Approvers further down the chain are never notified.
**When does app access actually get provisioned?** Only after every round in the policy has been approved. Provisioning never runs partway through a chain.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.siit.io/guides/data-management/how-to-add-sequential-approval-rounds-to-an-approval-policy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
