> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Functionalities > Configure functionality categories in Rootly to identify impacted product features during incidents, route to appropriate teams, and surface ownership context. # Overview **Functionalities** allow you to specify the impacted features during an incident. This can help you identify which responders to bring in, which on-call to page, which customers to inform, etc. Individual functionalities can be mapped to your status pages. Clean Shot2026 03 30at20 48 48@2x # Adding properties While Functionalities in Rootly comes with built-in properties, additional properties can be added. This allows you to build automations and workflows for your incident response processes using this information: for example, quickly identifying the customer impact of an incident based on the related functionality. To add custom properties, open **Functionalities**, click **Edit catalog**, and click **Add Property**. You can choose from several property types, including text, boolean, and importantly references to other Catalogs. For each Functionality, you'll be able to find the values of these properties in the **Custom Properties** tab. # Configuring Functionalities Begin editing the properties of your Functionalities by selecting the '...', then Edit. Clean Shot 2026 05 04 At 14 17 10@2x ## Basics Update the information in this tab to set the fundamental details about your functionality. 1. **ID**: Use the ID when working with Rootly's API to refer to the functionality. 2. **Name**: Add a descriptive name to your functionality for other Rootly users to refer to. 3. **Description**: Add a description of your functionality for other Rootly users to refer to. 4. **Public Description**: Add an external-facing description for your status page. This will be shown to your Rootly Status Page visitors. ## Ownership Assign the responsible stakeholders of your functionality. The values in these fields can be used to automate tasks and processes using Workflows in Rootly. For example, update an incident with the functionality's `Team` when a functionality is added to an incident. ## Connections Add connections between other entities in Rootly, like Environments, Services, Playbooks, and Escalation Policies. This information can be used to automate tasks and processes using Workflows in Rootly. For example, post a message in the incident channel linking to the functionality's playbook when a functionality is added to an incident. ### Paging Functionalities Functionalities can be paged when things go wrong. When a functionality is paged (either by an Alert Source, or manually by another user), the functionality's escalation policy will fire. Functionalities can only be paged if they have an assigned escalation policy. Make sure to set this up in the Functionality's Connection tab in Rootly. ## Alerting & Notifications Add relevant channel properties to the functionality to automate communications and processes using Workflows in Rootly. For example, use the `Slack Channel` property to post a message in a slack channel dedicated to the functionality when it is added to an incident. ## Custom Properties Add the values to your custom properties in this section. Learn more about adding custom properties [in this section](/configuration/functionalities). ## On-Call Configure what happens when this Functionality is paged in Rootly On-Call. When this Functionality is paged either manually by a user, or through an Alert Source, the Escalation Policy selected here will fire. # Incident Fields **Functionalities** can be customized to be either a **select** or **multi-select** field type. This means you can configure it to allow only one functionality value to be selected per incident or allow multiple functionality values to be selected per incident. Document image ## Attributes **Functionalities** can be configured with the following attributes. Each functionality attribute can be referenced via Liquid syntax. Since the functionality field can be either a **select** or **multi-select** field type, the Liquid syntax to reference each field type will differ. Select will follow a single-value syntax `{{incident.raw_functionalities | get: ''}}` Multi-select will follow an array syntax. Where i references the specific functionality object in the list of functionalities. `{{incident.raw_functionalities[index] | get: ''}}` ### ID This is the unique identifier of the functionality. This field **cannot be customized**. Rootly will automatically assign the *ID* upon creation. It is typically used in Liquid references and API calls. The following Liquid syntax will allow you to list out the functionality *ID*(s) that are selected for an incident: `{{ incident.functionality_ids }}` **OR** * `{{ incident.raw_functionalities | get: 'id'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'id' }}` for a multi-select field type ### Name This is the value that is displayed on the UI for the functionality. This field is customizable. The following Liquid syntax will allow you to list out the functionality *name*(s) that are selected for an incident: `{{ incident.functionalities }}` **OR** * `{{ incident.raw_functionalities | get: 'name'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'name' }}` for a multi-select field type ### Slug This is the string that is used to reference the functionality in Liquid references. This field is automatically generated by lower-casing and hyphenating the functionality *name*. The following Liquid syntax will allow you to list out the functionality *slug*(s) that are selected for an incident: `{{ incident.functionality_slugs }}` **OR** * `{{ incident.raw_functionalities | get: 'slug'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'slug' }}` for a multi-select field type ### Description This value is displayed on the UI to further explain each functionality. This field is customizable. The following Liquid syntax will allow you to list out the functionality *description*(s) that are selected for an incident: * `{{ incident.raw_functionalities | get: 'description'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'description' }}` for a multi-select field type ### Color Each functionality can be assigned a color, which will be used for color-coding on metrics graphs. Rootly uses **color-hex codes**. E.g. #000000 is black, #ffffff is white. Use [this page](https://www.color-hex.com/) to help you find the exact hex code for the color you want. The following Liquid syntax will allow you to list out the functionality *color*(s) that are selected for an incident: * `{{ incident.raw_functionalities | get: 'color'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'color' }}` for a multi-select field type ### Slack Channels Each functionality can be linked to one or more Slack channels. By default, Rootly does not notify the linked channel(s) when a functionality is selected for an incident. Notification needs to be explicitly called out as Attached Functionality Channels in workflow configurations. Systematically, each Slack channel is stored as an object containing an ID and name. The following Liquid syntax will allow you to list out the functionality *Slack Channel*(s) that are selected for an incident: * `{{ incident.raw_functionalities | get: 'slack_channels'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'slack_channels' }}` for a multi-select field type ### Slack Aliases Each functionality can be linked to one or more Slack user groups (aka aliases). By default, Rootly does not invite users in the linked user group(s) when a functionality is selected for an incident. Invitations need to be explicitly called out as Attached Functionality Aliases in workflow configurations. The following Liquid syntax will allow you to list out the functionality *Slack Alias*(es) that are selected for an incident: * `{{ incident.raw_functionalities | get: 'slack_aliases'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'slack_aliases' }}` for a multi-select field type ### Notify Emails Each functionality can be linked to one or more emails. By default, Rootly does not send emails to the linked address(es) when a functionality is selected for an incident. Notification needs to be explicitly called out as `{{ incident.raw_functionalities | map: 'notify_emails' | flatten | join: ',' }}` in workflow configurations. The following Liquid syntax will allow you to list out the functionality *Notify Email*(s) that are selected for an incident: * `{{ incident.raw_functionalities | get: 'notify_emails'}}` for the select field type * `{{ incident.raw_functionalities[index] | get: 'notify_emails' }}` for a multi-select field type ## Import Functionalities Instead of creating functionalities from scratch, Rootly allows you to import functionalities from **PagerDuty** or **Opsgenie**. Imported functionalities will be automatically kept in sync on a daily basis. The ability to import functionalities will only become available once you have PagerDuty or Opsgenie installed on the [integrations page](https://rootly.com/account/integrations). The following Liquid syntax will allow you to list out the corresponding IDs from each of the external paging applications: **PagerDuty** * `{{ incident.raw_functionalities | get: 'pagerduty_id' }}` for the select field type * `{{ incident.raw_functionalities\[0\] | get: 'pagerduty_id' }}` for a multi-select field type **Opsgenie** * `{{ incident.raw_functionalities | get: 'opsgenie_id' }}` for the select field type * `{{ incident.raw_functionalities\[0\] | get: 'opsgenie_id' }}` for a multi-select field type