> 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/request-management/approval-requests.md). # Manage approval requests How they work and how to design effective approval flows? ### What is an approval request, and why is it important? In most organizations, certain actions cannot be executed immediately.\ Granting access to an application, ordering equipment, or approving a specific employee request usually requires validation from one or more stakeholders. Approval requests exist to ensure that: * the right people are involved at the right time, * costs and security risks are controlled, * internal policies are consistently enforced. In Siit, approvals are not standalone actions. They are **fully integrated into workflows**, allowing you to control when a request can move forward, who must validate it, and what happens depending on the decision taken. This article is designed for **Siit admins** who configure workflows. It explains how approvals work, how to design them effectively, and how your configuration choices are reflected in the experience of approvers and employees. ### How approvals work in Siit (admin perspective) In Siit, an approval is a **workflow action** that introduces a decision point in the lifecycle of a request. When an approval is triggered: * the request is paused, * one or several approvers are notified, * the workflow continues only once a decision is made. Each approval action automatically creates two possible paths: * **Approved** * **Rejected** You can then decide which actions should run in each case (provisioning access, notifying the requester, closing the request, escalating, etc.). Approvals can be used at any moment in a workflow: * early, to block unnecessary processing, * or later, just before a sensitive or costly action. ### Designing an effective approval flow #### 1. Decide where validation is required Before adding an approval, ask yourself: * What risk or decision does this approval control? * What should be blocked until approval is given? Typical moments where approvals are used: * before granting app or system access, * before ordering hardware or licenses, * before executing automated actions via integrations or webhooks. Once added to the workflow, the approval becomes a **hard gate**: nothing after it will run until a decision is taken.
#### 2. Define who should approve the request Siit allows you to define approvers in a flexible way: * **Dynamic approvers**, such as: * the requester’s manager, * the app owner, * any role derived from your data. * **Static approvers**, by selecting one or more specific employees. * **Groups**, such as: * Teams * Inboxes You can also combine both approaches and create **multi-level approval sequences**, where several approvals are required in a defined order. This allows you to involve each stakeholder only when necessary, without overloading a single approver with decisions outside their scope.
#### 3. Provide context to help approvers make the right decision When configuring an approval, you can include a contextual message for the approver. This message can dynamically reference: * the request details, * the requester information, * the service or application involved. Providing enough context upfront reduces back-and-forth, speeds up decision-making, and avoids approvals being rejected simply due to lack of information.
#### 4. Configure reminders to avoid blocked workflows Approvals can sometimes remain pending if an approver does not act promptly. To prevent workflows from being blocked indefinitely, you can configure **automatic reminders**: * triggered after a defined delay (from one day to several weeks), * sent directly to the approver. Reminders ensure follow-up without requiring manual intervention from admins.
#### 5. Cancel or manually follow up on a pending approval Sometimes a request no longer needs to wait for a decision, the approval went to the wrong person, or you want to nudge the approver before the automatic reminder is due. From the request, admins can: * **Cancel** a pending approval directly from the approval card. This works the same way whether the approval was sent manually or triggered by a workflow. * **Send a reminder** on demand, without waiting for the scheduled delay. When you cancel an approval, the workflow stops at that approval step: it does not continue down the approved or the rejected branch. A confirmation message spells out this effect before you confirm.
### What approvers experience (and why admins should care) As an admin, understanding the approver experience is important:\ your configuration choices directly impact response time and adoption. #### From Slack or Microsoft Teams When an approval is requested: * the approver receives a notification, * they are redirected to Siit to review the request, * they can **Approve 👍 or Reject ❌** directly.
Approvers can click **More details** to review: * the request title and description, * the full request context.
* They can also add a comment explaining their decision.\ This comment is visible to admins in the request thread and provides valuable auditability.
#### From an email Approval emails have **Approve** and **Reject** buttons. Clicking one opens a Siit confirmation page, in the approver's language. The decision is only recorded when the approver clicks the button on that page. The links on Microsoft Teams approval cards open the same page, so Teams approvers confirm with one more click in their browser. #### From the Employee Portal Approvers can also manage approvals from the **Employee Portal**: * all pending approvals are grouped in a dedicated **“Pending approvals”** tab, * clicking on a request displays its full history and context. This ensures a consistent experience for approvers, whether they primarily work from Slack, Teams, or the Portal.
### Frequently asked questions #### Why do approvers have to click twice from an email? Some email security tools, such as Microsoft Defender Safe Links, open every link in an email to check it. Without a confirmation step, that check could approve or reject a request before the approver even reads the email. A security tool never clicks the button on the confirmation page, so only a real decision counts. #### What happens if the approver opens the link again? The page shows the decision already recorded. If the request was decided the other way, handled by another approver or cancelled, the page says so and nothing changes. --- # 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/request-management/approval-requests.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.