> 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/request-and-service-management-service-catalog/applications-and-equipment-fields.md).

# Add application and equipment fields to forms

Link requests to an Application and an Equipment alongside the Service, and configure services so these fields fill in from manual, form and AI request creation for reporting

#### Overview

Siit introduces dedicated **Application** and **Equipment** fields in requests to provide a clearer structure, better reporting, and more powerful automation capabilities.

Instead of relying on services alone or custom fields, requests can now be explicitly associated with:

* a **Service** (what type of request it is),
* an **Application** (which software is involved),
* an **Equipment** (which asset is concerned).

This article explains:

* what these new fields are,
* how they work in practice,
* and how to configure your services to get the full value from them across manual, form-based, and AI-driven request creation.

<figure><img src="https://2274035325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlWFhpq2ia6gdHet0opKx%2Fuploads%2Fgit-blob-5df0a30a8341d2177e8cb1d956c6021761a18c1c%2Funnamed.jpg?alt=media" alt="unnamed"><figcaption></figcaption></figure>

#### Why Applications and Equipment Matter in Requests

With dedicated fields, you unlock:

### Better data visibility

Each request is now clearly linked to the exact application or equipment involved, creating a consistent and reliable data model.

### More granular reporting

You can analyze:

* most requested applications,
* most impacted equipment,
* trends per app or asset over time.

This enables more actionable dashboards and operational insights.

### Stronger automation and workflows

Workflows can now react directly to:

* the associated application,
* or the associated equipment,\
  unlocking app-specific or asset-specific automation (provisioning, approvals, notifications, integrations).

#### Understanding the New Request Fields

Each request now includes:

* **Service**\
  Defines the type of request (e.g. App Access Request, Equipment Issue).
* **Associated app**\
  Identifies the software application involved.
* **Associated equipment**\
  Identifies the physical asset involved.

These fields are visible only to users with the appropriate permissions (manage applications / manage equipment), ensuring controlled access to sensitive data.

<figure><img src="https://2274035325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlWFhpq2ia6gdHet0opKx%2Fuploads%2Fgit-blob-af8643907c07fdcc81d81e37a2c4cc5f7172e207%2Funnamed-1-.jpg?alt=media" alt="unnamed (1)"><figcaption></figcaption></figure>

#### How Applications and Equipment Are Filled in Requests

How these fields are populated depends on how requests are created in your workspace.

### 1. Auto-submit request mode (Slack / Teams messages)

In auto-submit mode, any employee message automatically creates a Siit request without a predefined service.

**How it works:**

* A request is created with no Service, Application, or Equipment.
* An admin qualifies the request manually:
  * assigns the correct **Service** (e.g. App Access Request),
  * selects the relevant **Associated app** or **Associated equipment**.

This approach is flexible and well-suited for teams that prefer free-form employee requests with admin qualification.

### 2. Submit button / Service form mode

When employees submit requests using a **Submit button** or from the **Service Catalog**, structured data can be captured upfront.

**Prerequisites:**

* A dedicated service must be configured (e.g. App Access Request or Equipment Issue).
* The service must include a dynamic form with:
  * **Select an app** for application-related services,
  * **Select an equipment** for equipment-related services.

**Result:**

* The Service is automatically assigned.
* The Associated app or Associated equipment field is automatically populated.
* No manual qualification is required.

This mode ensures high data quality and faster processing.

### 3. AI Agent (Playbooks)

When using the AI Agent with a **Create a request** action in a playbook:

* The agent can automatically:
  * select the appropriate Service,
  * associate the correct Application or Equipment,\
    based on employee intent and existing configuration.

This enables fully automated request handling while preserving structured data for reporting and workflows.

#### Best Practices for Service Configuration

To fully benefit from Applications and Equipment fields, services must be designed intentionally.

### Create dedicated services per use case

Avoid using the application or equipment itself as the service.

Instead, create clear, functional services such as:

* **Application Access Request/Issue**
* **Equipment Request/Issue**

Inside each service, make sure to add the corresponding dynamic service:

* "Select an application" for the **Application Access Request/Issue** service
* "Select and equipment" for the **Equipment Request/Issue**

<figure><img src="https://2274035325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlWFhpq2ia6gdHet0opKx%2Fuploads%2Fgit-blob-bf3b8421c9124eaa41ea28dca65ce29a2c958567%2Funnamed-2-.jpg?alt=media" alt="unnamed (2)"><figcaption></figcaption></figure>

Make sure to review your workflow accordingly so that you use the combinaison Service/Application in your workflows instead of the Application only.

<figure><img src="https://2274035325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlWFhpq2ia6gdHet0opKx%2Fuploads%2Fgit-blob-809ff3a3650f4aa0df34eb0b4d3abfc54598f336%2Funnamed-1-.png?alt=media" alt="unnamed (1)"><figcaption></figcaption></figure>


---

# 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/request-and-service-management-service-catalog/applications-and-equipment-fields.md?ask=<question>&goal=<user_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.