> For the complete documentation index, see [llms.txt](https://knowledge.rollcredits.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledge.rollcredits.io/approvals/configure.md).
# Set up approval flows
Set who approves each kind of transaction on a production, in what order, and who can be asked for extra approval.
Use this page to decide who approves transactions on a production and in what order. Open **Approvals > Configure** in the sidebar to reach the **Approvals Configuration** page, which Owners and Super Admins can use.
{% hint style="info" %}
Some parts of the page depend on what your company uses:
* **Estimate** and **Invoice** don't appear if your company has invoices turned off.
* The **Department-based approvals** panel appears only if your company uses department-based approvals.
* The **Escalated Approvers** tab appears only if your company uses escalated approvers. Without it, the page has no tabs and shows only the approval flows.
{% endhint %}
## How approval chains work
Each kind of transaction has its own approval flow: **Estimate**, **Invoice**, **Receipt** and **Journal Entry**. A flow is a chain of levels. When someone uploads a document, it's sent up its flow one level at a time. Once someone on the highest level approves it, and any escalated approvers asked have too, the document is marked as approved and ready for payment.
The flows are separate, so the same person can be at different levels in different flows.
## Build an approval chain
1. On the **Approval Flows** tab, select the flow you want to set up: **Estimate**, **Invoice**, **Receipt** or **Journal Entry**.
2. Drag a person from **Uploaders** into **Level 1**. **Uploaders** lists everyone on the production who isn't in this chain.
3. To add another level, select **Add Level** below the chain, then drag people into the new level.
4. To move someone to a different level, drag them into that level.
5. To take someone out of the chain, drag them back to **Uploaders**.
Changes save on their own a moment after you drop someone. The indicator at the top of the chain shows **Saving...** and then **Saved!**.
* A person can be in only one level of a flow.
* A level can hold more than one person. When a level has several people, whoever sends a transaction on chooses which of them gets it.
* A new level is kept only once someone is in it. If you leave the page with an empty level at the bottom, it's gone the next time you open the page.
{% hint style="warning" %}
Don't leave an empty level between levels that have people in them. A transaction can be sent only to the level right after the sender's, so nobody can send it on past an empty level: the **Submit to** list has nobody to choose.
{% endhint %}
If a change can't be saved, an error message appears. Reload the page to see the chain as it's saved, then make the change again.
## Route approvals by department
If your company uses department-based approvals, a **Department-based approvals** panel appears above the flow types.
To turn it on, select the toggle in the panel. It saves on its own, and the panel's indicator shows **Saved!**.
The setting covers every flow on the production. When it's on, the list of people someone can send a transaction to shows only the next-level approvers who lead the sender's department: Department Heads in that department, and Managers or Super Admins assigned to it. If nobody at the next level leads the sender's department, or the sender has no department, the list shows everyone at the next level.
People's departments are the ones set on the **Departments** tab of [Project > Team](/project/team.md).
## Choose escalated approvers
If your company uses escalated approvers, the page has two tabs: **Approval Flows** and **Escalated Approvers**. Escalated approvers are people an approver can ask for extra sign-off on a transaction, on top of the normal chain.
1. Select the **Escalated Approvers** tab. It lists everyone on the production, with their name and email.
2. Select a person's row to tick it. Select it again to untick it.
The count next to the instructions, such as **(2 selected)**, shows how many people are ticked. Changes save on their own, shown by **Saving...** and then **Saved!**. You can't select rows while a change is saving.
To learn how approvers ask for extra sign-off, see [Escalate for additional approval](/approvals/review/escalate.md).
## How your chains shape the Review page
A change to a chain also affects transactions already waiting for approval. On [Approvals > Review](/approvals/review.md):
* The **Needs Approval** tab appears only for people who are in an approval flow or are escalated approvers.
* **Submit to** lists the people on the level right after the sender's in that transaction's flow. For someone who isn't in the chain, that's **Level 1**. When several kinds of transactions are selected at once, it lists only people who are next in all of those flows. See [Submit transactions for approval](/approvals/review/submit-for-approval.md).
* When someone in a chain adds a transaction, it counts as approved at their own level, and they send it on to the next level.
* The people on the highest-numbered level of a flow, the last one on the page, are its highest-level approvers. A transaction one of them adds is approved as soon as it's added, so nobody in the chain can reject it. Only an escalated approver it's escalated to can.
* If a flow has nobody in it, transactions of that kind don't need approval and don't appear on the Review page.
---
# 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://knowledge.rollcredits.io/approvals/configure.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.
