> 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-set-up-the-app-access-question-in-a-service-form.md).
# Add the app access question to a form
Let employees request one or more apps directly from a service form, with the right apps shown and if you need it, a Role selector that kicks off your App Access approval flow automatically.
### What this guide helps you achieve
* Add an **App access** field to any service form
* Control which apps employees are allowed to pick (e.g. only Approved apps)
* Decide whether picking a Role is required, so the request triggers your App Access approval flow instead of landing as a plain ticket
* Mark the field Mandatory
### Where to find it
`Service Catalog → [Service] → Form → App access question`
### Steps
1. Go to **Service Catalog** and open the service you want to edit.
2. Open the **Form** tab and add (or select) the **App access** question.
3. Choose **Single select** if the employee should request one app at a time, or **Multiple select** to let them request several apps in the same submission.
4. Under **Type of apps to display**, pick which apps are eligible to appear in the picker, for example, restrict it to **Approved** apps only so employees can't request apps that aren't ready for general use.
5. Under **Role-based access request**, turn on **Ask for role and trigger app access** if you want the employee to also pick a Role for the app they're requesting.
* Note: this only shows apps for which the requester has at least one available Role. If an app has no Roles configured, it won't show up here, the request needs to go through Roles to trigger the automated App Access flow.
6. Toggle **Mandatory** on if the question must be answered before the form can be submitted.
7. Save the form and submit a test request to confirm the picker and (if enabled) the Role step behave as expected.
### Common pitfalls
* **Role toggle on, but no Roles configured on the app** — the picker won't offer a Role, and the request falls back to the app's Default role (manual app owner ping) instead of automated routing.
* **"Type of apps to display" set too narrow,** if you restrict to Approved only, make sure the apps you expect employees to request are actually marked Approved in **Data Management → Apps**, or they won't show up at all.
### Best practices
* Keep the app list scoped (e.g. Approved only) so employees aren't offered apps that are deprecated, under security review, or not yet supported.
* Only turn on **Ask for role and trigger app access** for apps where you've actually set up Roles and an Approval Policy, otherwise the toggle adds a step without an automated payoff.
* Put the App access field early in the form so agents see the requested app(s) immediately when triaging.
### Availability
Pro plan.
---
# 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-set-up-the-app-access-question-in-a-service-form.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.
