> 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/workflows/workflows-app-access.md).
# Automate app access requests
Step by step article on how to set up a workflow for the app access requests.
{% hint style="info" %}
In this article, we’ll review how to **configure a workflow that fully automates app access requests** — from the initial submission by an employee to the final provisioning of the application via Okta, JumpCloud, Google Workspace, Microsoft Entra ID or a custom webhook integration.
By the end of this guide, you’ll be able to build a **zero-touch access request flow** that:
* Automatically routes the request for the right approvals
* Handles multi-level approval chains (e.g., manager and app owner)
* Provisions the access once approved
* Updates the ticket automatically once completed
{% endhint %}
### Overview
App access requests are among the most frequent IT tickets in any company.\
Employees constantly need access to new tools, systems, or applications — and without automation, each request requires multiple manual steps: qualification, approval, and provisioning.
This process is time-consuming for IT teams, especially as the number of SaaS tools grows. Automating app access requests through **Siit Workflows** not only reduces the manual workload but also ensures faster access for employees, consistent governance, and a complete audit trail — all without a single IT touch.
### Step 1 — Create a New Workflow
1. Go to **Settings > Workflows** and click **Create Workflow**.
2. Select **Request Submitted** as your workflow trigger.\
This ensures the automation starts each time an employee submits a new request in Siit.
### Step 2 — Define the Trigger Condition
1. Add a **Condition** to ensure the workflow only runs for app access requests.
* Choose **“Service”** → select your dedicated *App Access Request* service from the Service Catalog.
💡 **Tip:**\
If you want to restrict the workflow to a specific app (for example: *Slack Access Request*), add a second condition referencing the app field in your service form.
### Step 3 — Send the Approval Requests
Next, you’ll add approval steps to ensure access is properly validated before provisioning.
1. Add the **Send an Approval Request** action.
2. Choose your approval recipients:
* First approver: **Requester’s Manager**
* Second approver: **App Owner**
💡 **Tips:**
* Use dynamic variables such as `{{request.requester.name}}` or `{{request.service.name}}` to personalize the message to approvers.
* You can also include contextual information like the reason for access or duration if these fields exist in the form.
Once both approvals are completed, the workflow automatically continues to the next step.
### Step 4 — Provision Access Automatically
After approval, you can automate the actual access provisioning:
#### Option 1 — Using Okta or JumpCloud
1. Add an action: **Add user to a group**.
2. Select the target group manually or dynamically call it using variables (for example:\
`{{request.service.name}}_users`).
This automatically adds the requester to the right group, granting them access to the app.
#### Option 2 — Using a Custom Provider via Webhook
If your company uses another identity or access system (like Entra ID), you can:
1. Add a **Custom Action** using a **Webhook**.
2. Configure the endpoint to send the requester’s details and requested app to your provider’s API.
If you want to explore further this option, feel free to check out [this article](/guides/workflows/google-group-management.md).
### Step 5 — Confirm Completion
Finally, you can:
* Add a **Send a Message** or **Update Request** action to notify the employee that their access has been granted.
* Close the request automatically once the provisioning is complete.
### Checking what happened: the App Access event log
Once access starts getting provisioned automatically, you'll want a fast way to confirm what actually happened for any given person, especially if something looks off.
Every App Access now keeps its own event log, covering only the events that changed its status:
* **Request created**
* **Approvals** (one entry per approver)
* **Manual provisioning** (an app owner granted access by hand)
* **Automatic provisioning** (your workflow's group-add or webhook action ran)
* **Provisioning failure** (the automatic step failed and needs manual follow-up)
* **Cancellation**
* **Expiration**
* **Planned deprovisioning**
To check it:
1. Open the app from your Apps list.
2. Go to the **Activity** tab.
3. Find the **App access** entry for the person you're checking.
4. Open the entry to see its **Events log**.
💡**Tip**:\
If a workflow's automatic provisioning step ever fails silently, this is the fastest way to confirm it and see whether it needs manual follow-up. For example, if someone's access shows as granted but they say they still can't log in, the event log will show whether the approval went through and where the provisioning step actually stopped.
This also covers App Access granted before this update. Siit backfilled events onto existing records, so older grants show the same history as new ones.
### Final Result
Your workflow now automates the entire app access process:
1. Employee submits the request.
2. The workflow qualifies and routes it for approvals.
3. Once approved, access is provisioned automatically.
4. The request closes — all without IT intervention.
**Outcome:** A fully automated, secure, and auditable app access management process.
---
# 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/workflows/workflows-app-access.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.
