Design forms

A form defines the information that can be included in messages or incidents when the form is submitted. The Forms tab of the workflow editor allows you to create forms, build out form content, configure message delivery options, and define who has permission to use it. Once you have created a form, you must deploy it before it can be used to send notifications or initiate incidents.

Formless alerting: You can notify users without a form by adding a Create Alert step to your automated flows.

Building and deploying forms

Once you've created an empty form, you still have some work to do. The following sections provide an overview of the steps you'll need to take to create the message content, define who has permission to send messages using the form, and configure advanced notification and handling options.

Create form content and delivery options

Once you have created an empty form, you can create the content of the messages and define message delivery options using the following tabs:

  • Layout: The form's Layout tab allows you to configure the default recipients and handling options and specify which properties are available to be included in messages, incidents, or in the associate flow. Form elements and properties can be added and rearranged using drag-and-drop, and sections can be removed with one click. This tab also defines whether sending the form initiates a conference bridge (for messaging forms). For more information about working with the form layout, see Design the form layout.
  • Messages (messaging forms only): The Messages tab is where you define the content of the email, SMS (text), and voice notifications. You can include properties in the messages if the properties are included on the form's Layout tab. Messages that do not contain any content or response options are considered empty notifications. They are not sent to the targeted devices and are logged as failed notifications. For more information about creating message content for email, SMS (text) and voice notifications, see Define message content.
  • Responses (messaging forms only): The Responses tab lets you define the response choices that are presented to message recipients and set the action xMatters takes when each response is selected. These actions may include escalating the alert, terminating the alert, or connecting the recipient to a conference bridge. For more information about defining response choices, see Define response options.

Configure flows

Each messaging form creates an associated flow canvas where you can use Flow Designer to build drag-and-drop flows, connecting the tools you use into orchestrated, fully automated toolchains to help you reduce the complexity of your incident management workflows.

Each flow trigger form can be associated with an Incident Initiation trigger or an Incident Automation trigger to initiate the connected flow whenever the form is submitted.

Configure permissions

For the form and its scenarios to be accessible to other users, you must configure permissions.

Initially, only the user who created the form can use it (whether it's a messaging form used to sent notifications or a flow trigger form used to initiate incidents). You can give other users permission to use the form, either individually or to all users with certain roles (for example, Developers, Full Access Users). Note that the form must also be enabled before it can be used.

The Form Permission page also allows you to grant form senders the ability to create, edit, delete, and set scenario permissions for all scenarios associated with a form (to learn more about scenarios, see Define scenarios).

Configure scenarios (optional)

You can make it easier for message senders to quickly send notifications by creating pre-populated forms called scenarios. By anticipating common situations and creating scenarios that are already filled in with the appropriate values, you can reduce the number of choices a message sender must make when sending an urgent notification. For more information about creating scenarios, see Define scenarios.

Allow users to self-subscribe to the form (optional)

If you would like to allow users to voluntarily receive notifications even when they aren't targeted by the alert, you can create a subscription form. Subscription notifications can be configured so that they are "information-only" and do not include the ability to respond or take ownership of the alert. Then can also be configures so that they are generated after an alert has been open for a certain length of time.

For more information about creating subscription forms, see Subscription forms.

Configure status updates (optional)

For messaging forms, you can notify specific users, groups, or dynamic teams when an alert based off the form is initiated or concluded. 

The following types of recipients can be added:

  • Users
  • Roles
  • Groups
  • Dynamic teams
  • Devices

Additionally, granular settings are available to configure which devices recipients receive notifications on. For example, you could specify that users in the system who have the Group Supervisor role should be notified on their Work Email devices when a given form is initiated.

Deploy the form

Before you can send notifications with your form, you must deploy it. Deploying a form makes it available for use. Depending on how you deploy a form, it may be available from the web user interface, xMatters mobile apps, the REST API, or a combination of those. If a form is not deployed, it cannot be used to send notifications and any associated flows won't run.

It is a best practice to deploy forms only to the locations where message senders need to access them; for example, deploy forms to the mobile app if message senders need to use them when they are on the go. Deploy a form to web services only when you want to initiate that form from another application.

For flow trigger forms, you can also set the deployment option on the associated Incident Initiation trigger or Incident Automation trigger.