> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom Forms
> Configure conditional forms that collect additional information when users create, acknowledge, or close incidents
Custom forms help you collect consistent information at key points in incident handling. You can configure one account-level form for each action: **Create incident**, **Acknowledge incident**, and **Close incident**. Configuration changes apply immediately.
Use forms to collect handoff context, impact details, resolution notes, or screenshots. For reusable business attributes, create the field first in [Custom Fields](/en/on-call/configuration/custom-fields), then add it to a form.
## Configure a form
In the console, go to **Configuration → Custom Forms**, then choose **Create incident**, **Acknowledge incident**, or **Close incident**.
Click **Add Field** and add the elements you need:
| Element | Purpose |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| Custom field | Binds an enabled custom field to collect structured business information. A field can be added only once to the same form. |
| Summary | Provides a multiline text input for the acknowledgment or closure context. This element is not shown in the create-incident form. |
| Image upload | Lets the person submitting the action upload images. |
Select an added element to set its help text, placeholder, and required rule. An element can always be shown, shown only when conditions match, or required only when conditions match.
Drag elements into the required display order. Order changes are saved automatically, and the new rules take effect immediately.
## When each form appears
| Form | When it appears | Result after submission |
| -------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Create incident | When a user manually creates an incident | Custom-field values are saved with the incident. |
| Acknowledge incident | When an incident moves from triggered to processing | The acknowledgment and custom-field values are submitted together; the summary and images are recorded with the acknowledgment action. |
| Close incident | When an open incident moves to closed | The closure and custom-field values are submitted together. |
Visibility and required rules are evaluated when the user performs the action. For example, you can require a field only when a specific severity, label, or team member matches.
These forms also work in the Flashduty App: creating, acknowledging, and closing an incident in the App presents the same form. Both platforms share one configuration, with consistent visibility conditions, required rules, and behaviors such as image upload.
If an action has no configured form elements, or no element is visible for the current incident and user, Flashduty runs the normal create, acknowledge, or close flow without asking for additional input.
## Union interaction for batch operations
When you select **multiple** incidents in the incident list and batch **acknowledge** or batch **close** them, the system first splits the selection into two groups by form applicability, then handles each group separately:
* **Incidents that don't need the form**: the action has no configured form elements, or no element is visible for the current incident/user. Clicking **Acknowledge / Close** **executes immediately** and deselects them from the selection, then the form for the remaining incidents is shown
* **Incidents that need the form**: a **union form** is shown — you fill it once and the values are written to every listed incident in a single request (all-or-nothing; on failure the dialog stays open so you can retry)
The union form's fields are the union of all incidents awaiting the form: an element appears if any incident can see it and is required if any incident requires it.
**Overview in mixed scenarios**: when the selection contains both no-form and form incidents, the dialog starts with an overview — "N incidents acknowledged / M incidents pending acknowledgment" ("closed / pending closure" for the close action) — noting that "the incidents below require the form before acknowledgment and the form values are written to each of them". If every selected incident needs the form, the dialog goes straight to the form with no overview.
**Abandon warning**: if you close the dialog without submitting (Cancel or the top-right close) after some incidents have already been executed, a warning appears — "N acknowledged, M remaining not filled in and not processed" ("closed" for the close action) — so you don't assume the whole batch was completed.
**Fallback when the form cannot be resolved**: for single-incident acknowledge/close, the existing semantics hold — a resolution failure raises the error and is not silently bypassed; for batch acknowledge/close, a resolution failure does not block the action and the whole batch is executed as if no form existed (consistent with the backend's degradation for form-less batch requests).
## Recommendations
* Use custom fields for information you need to filter, report on, or reuse; use **Summary** for one-off action notes.
* Require only the information that is genuinely needed, so urgent acknowledgments and closures stay fast.
* Before changing or disabling a custom field, check whether a form still references it. Disabled fields are not shown at runtime.
## Related topics
Create reusable business fields for incidents and custom forms
Learn about acknowledgment, closure, and other incident actions