> 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/service-catalog/service-forms.md).

# Service forms

Service forms let you ask the right questions up front. When an employee selects a service, Siit shows tailored fields to collect the details you need. Answers are submitted with the request and are visible to agents for faster triage, routing, and resolution.

<figure><img src="/files/4AZYmSVdcx42m0OQFyTO" alt=""><figcaption></figcaption></figure>

#### What you can collect

* Text: short answer, long answer
* Numbers
* Lists: single select or multi select (define your options)
* Dates
* Pickers from your internal data: person, application, team, department, office location, legal entity, country, equipment
* **App access**: lets employees pick one or more apps to request. Choose which apps are eligible to show up in the picker (e.g. only Approved apps), and optionally require a Role, this hands the request straight to your App Access approval flow instead of creating a plain ticket.
* File upload

### Where it appears

* Slack/Teams request modal: the form expands after the employee chooses a service.
* Portal: the same fields render on the service request page.
* Request view for agents: answers are displayed at the top of the conversation so the team sees context immediately.

{% embed url="<https://www.youtube.com/watch?v=3IpGwYccRYw>" %}

### **Key behaviors**

* Per‑service configuration: each service can have its own form.
* Required vs optional: mark any field as Mandatory.
* Order and format: choose field type, label, helper text, and drag to reorder.
* Directory‑aware pickers: person/team/app/equipment fields draw from Siit’s unified data, so lists stay current.
* Multi‑channel: the same form works in Slack/Teams and the web portal.

### What admins can expect

* Immediate context: form answers are summarized in the request, reducing back‑and‑forth.
* Search and triage: answers are visible in the request and can be referenced in workflows and views for routing and prioritization.

Examples

* IT access request: Application (picker), Access level (single select), Date needed (date), Manager (person), Justification (long text)
* HR payroll question: Payroll period (date), Issue type (single select), Attachment (file)
* Equipment request: Equipment type (single select), Model preference (short text), Office location (picker), Cost center (number)

### Best practices

* Ask only for what’s needed to take action; keep mandatory fields minimal.
* Use pickers (person/app/team/equipment) instead of free text to reduce ambiguity.
* Put the most important fields first; add helper text for clarity.
* Pair with workflows to auto‑route or set priority based on answers (e.g., Issue type = “Urgent payroll” → assign to HR‑Payroll and set priority High).