> ## 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. # Incident properties and configuration overview > Configure incident properties, custom fields, and settings to characterize incidents, trigger workflows, and filter metrics across your organization. ## Overview Every incident created in Rootly is characterized by a structured set of **properties**. These properties define how an incident behaves, how it progresses through its lifecycle, how it interacts with workflows and automation, and how it appears in reporting and analytics. Incident properties serve several critical purposes: * Help characterize each incident (e.g., `kind = normal`) * Trigger workflow automations (e.g., Status Updated) * Define conditional logic for workflow execution (e.g., Severity is SEV0) * Enable filtering and segmentation of metrics * Allow structured access through **Liquid syntax** Properties fall into three primary categories: * **Fixed Properties** — system-defined and not customizable * **Configurable Properties** — built-in but organization-customizable * **Custom Fields** — fully defined and managed by your organization *** # Fixed Properties Fixed properties are intentionally restricted to maintain lifecycle integrity, automation consistency, and reporting standardization across the Rootly platform. Fixed properties cannot be modified or deleted. They define the foundational lifecycle and structural behavior of every incident. *** ## Incident Kind The **Kind** property determines the classification and structural behavior of an incident at creation time — whether it's a real production incident, a test, a backfill, or a scheduled maintenance window. Kind is immutable after declaration and governs workflow execution, status page eligibility, and metrics inclusion. For the full kind reference (all seven kinds, behavior matrix, choosing the right kind, and Kind-related troubleshooting), see **[Incident Kind](/configuration/incident-kind)**. *** ## Incident Status The **Status** property defines the lifecycle stage of an incident — from Triage through Started, Mitigated, Resolved, Closed, or Cancelled. Status transitions are validated to preserve chronological and logical integrity. Scheduled Maintenance incidents follow a separate lifecycle (Scheduled / In Progress / Completed) with its own rules. For the full status reference (transition rules, timestamp validation, sub-statuses, the Scheduled Maintenance lifecycle, and Status-related troubleshooting), see **[Incident Status](/configuration/incident-status)**. *** # Configurable Properties Configurable properties are built-in fields that organizations can customize to reflect their operational structure, severity model, and reporting taxonomy. | Property | Description | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Environments](/configuration/environments) | Characterizes incidents by environment (e.g., Development, Staging, Production). Commonly used to prioritize production-impacting incidents and to filter metrics and workflow conditions. | | [Severities](/configuration/severities) | Defines impact levels (e.g., SEV0–SEV3). Drives escalation logic, workflow triggers, and reporting analysis. | | [Incident Types](/configuration/incident-types) | Custom categorization distinct from Kind. Allows organizations to define taxonomy such as UI Bug, Infrastructure Failure, Security Event, etc. | | [Incident Roles](/configuration/incident-roles) | Defines structured responder roles (Incident Commander, Communications Lead, etc.) to coordinate responsibilities during response. | | [Teams](/configuration/teams) | Assigns ownership and organizational routing responsibility to teams or groups. | | [Services](/configuration/services) | Identifies impacted infrastructure components. Used for service-level reporting and status page communication. | | [Functionalities](/configuration/functionalities) | Identifies impacted product capabilities (e.g., login, checkout). Enables feature-level transparency. | | [Incident Causes](/configuration/incident-causes) | Categorizes root causes to support retrospective analysis and long-term reliability improvements. | *** ## Property Order The ordering of values within configurable properties determines how they appear in dropdown menus and forms. Ordering is **global** and affects all users. You can: * Drag and drop values manually * Sort values alphabetically Property order example *** # Custom Fields When built-in properties are insufficient to meet your organization’s needs, you can create **Custom Fields** to extend the incident schema. Custom Fields allow you to: * Capture structured or unstructured metadata * Apply validation and defaults * Power advanced workflow automation * Reference values using Liquid syntax * Enforce organization-specific incident taxonomy For full configuration details, see the [Custom Fields](/configuration/custom-fields) documentation. *** # Frequently Asked Questions No. Fixed properties (**Kind** and **Status**) are system-defined and cannot be modified, deleted, or customized. They exist to ensure consistency across the platform and maintain the integrity of workflow automation and reporting. If you need different categorization options, use **Configurable Properties** (like Incident Types) or **Custom Fields**, which can be fully customized to meet your organization's needs. Yes. Custom fields can be referenced in workflow run conditions and Liquid templates, allowing you to create sophisticated automation based on organization-specific data. Custom fields are accessible via Liquid syntax: ```liquid theme={null} {{ incident.custom_fields | find: 'custom_field.slug', 'your-field-slug' | get: 'value' }} ``` This enables workflows to react to custom field values, trigger actions based on custom data, and include custom field information in notifications and integrations. Property ordering is **global**, meaning changes affect all users immediately. When you reorder values (e.g., Severities or Environments), the new order appears in: * Dropdown menus when creating or editing incidents * Form fields across the platform * Any interface where that property is displayed You can reorder manually via drag-and-drop or sort alphabetically. *** **Need help or have a question?** Contact us anytime at **[support@rootly.com](mailto:support@rootly.com)**, use the `/rootly support` Slack command, or visit **Getting Help** to start a chat.