Skip to main content
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, then add it to a form.

​
Configure a form

1

Open Custom Forms

In the console, go to Configuration → Custom Forms, then choose Create incident, Acknowledge incident, or Close incident.
2

Add form elements

Click Add Field and add the elements you need:
3

Set input rules

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.
4

Order elements

Drag elements into the required display order. Order changes are saved automatically, and the new rules take effect immediately.

​
When each form appears

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.

Custom Fields

Create reusable business fields for incidents and custom forms

Handle and Update Incidents

Learn about acknowledgment, closure, and other incident actions