> ## Documentation Index > Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt > Use this file to discover all available pages before exploring further. # Custom fields > Add custom fields to Ravenna forms to capture exactly the information your team needs when tickets are created, with multiple input types. Custom fields add additional information fields to ticket creation forms. Use them to create dynamic, customized templates that capture exactly the information your team needs for different types of requests. ## Mental model Custom fields are additional data fields attached to forms. When a ticket is created using a form, the custom fields on that form become part of the ticket's data. Custom fields extend the ticket data model beyond the built-in system fields (title, description, status, priority, assignee, requester, approvers, followers). Key concepts: * Custom fields are workspace-scoped. * A custom field can be **shared** (available to add to multiple forms) or **private** (locked to a single form). * Custom field values are stored on the ticket and can be read, updated, and used in workflows and agent rules. * Custom fields are only collected when a ticket is created through a form. Tickets created without a form do not have custom field data. *** ## Field type selection guide | Field type | Use when | | ---------------------------- | ------------------------------------------------------------------------------------- | | **Text** | Short freeform input (names, identifiers, URLs) | | **Text area** | Longer freeform input (steps to reproduce, justifications) | | **Number** | Quantities, counts, version numbers | | **Date** | Deadlines, target dates, incident dates. Supports format suffixes in title templates. | | **Time** | Specific times of day | | **Duration** | Time spans, estimated effort | | **Timezone select** | User timezone for scheduling | | **Boolean** | Yes/no confirmations, toggles | | **Select** | Single choice from a fixed set (severity, environment, device type) | | **Multi-select** | Multiple choices from a fixed set (affected systems, required permissions) | | **User select** | Pick one organization member (manager, approver) | | **User multi-select** | Pick multiple members (stakeholders, reviewers) | | **User group select** | Pick a team or group (supports allowlist and source filtering) | | **Tag select** | Pick from workspace tags | | **Application select** | Pick from connected applications (for access requests) | | **Application multi-select** | Pick multiple connected applications (supports allowlist filtering) | | **Application group select** | Pick from application groups | | **Type select** | Pick from predefined ticket types (Service, Incident, Question, etc.) | | **Access level select** | Pick from defined access levels (for permission management) | | **File picker** | Attachments (screenshots, documents, logs) | For structured data that needs filtering and reporting, prefer select/multi-select over freeform text. Select fields produce consistent values that work better in views, workflows, and analytics. *** ## Shared vs. private fields **Shared fields** (non-private) can be added to multiple forms. Updating a shared field's configuration (type, options, key) propagates the change to all forms using it. This is useful for standardized fields like "Department" or "Location" that appear on many forms. Each form can override the **label** and **description** of a shared field locally. The override is stored on the form's field assignment, not the underlying field, so the same field can read as "Your department" on one form and "Requesting department" on another. Clearing the override restores the shared values. **Private fields** are locked to a single form. They cannot be added to other forms and do not appear in the "Existing Custom Fields" tab. Use private fields for form-specific data that is not relevant elsewhere (e.g., "Steps to Reproduce" on a bug report form). When deciding between shared and private: if the same data point is relevant across multiple forms, make it shared. If it only makes sense in the context of one form, make it private. *** ## Custom fields in automation **Workflows:** Custom field values are available as dynamic values in workflow actions for tickets created with the corresponding form. Use them to: * Route tickets based on field values (e.g., if "Severity" is "Critical", assign to senior team). * Include field data in notifications or messages. * Set other ticket properties based on field values. **Agent rules:** The agent can read custom field values from a ticket and use them in conversation context. The agent can also set custom field values when creating or updating tickets through forms. **Views and filtering:** Custom field values are available as filter and grouping criteria in ticket views. Select and multi-select fields are most effective for filtering. *** ## Constraints and gotchas * Custom fields are only available on tickets created through forms. Tickets created via direct message or without a form selection will not have custom field data. * A custom field cannot be deleted while it is attached to any form. Remove it from all forms first. * Updating a shared field's configuration affects all forms using it. If you need form-specific behavior, create a private field instead. The update confirmation dialog lists every impacted form so you can review the scope of the change before saving. * Deleting a shared field that is still attached to one or more forms is blocked. The error dialog lists each form referencing the field so you can detach it before retrying. * Field type cannot be changed after creation. If you need a different type, create a new field and migrate the data manually. * Required fields must be filled out during ticket creation. If a field is marked required, the ticket cannot be submitted without a value. * Required is enforced as a floor across levels for shared fields. If a shared custom field is set to Required in workspace settings, the per-form Required toggle is locked on and individual forms cannot make the field optional. To allow forms to opt out, uncheck Required on the field in **Settings > Fields**. Private fields are exempt from this floor and can be toggled required directly on the form. * Custom field values can be updated after ticket creation from the ticket detail page, regardless of whether the field was originally required. * Select and multi-select option changes do not retroactively update existing tickets. If you remove an option, tickets with that value retain it. * For user group select fields, changing the source filter clears the allowlist. When duplicating request types across workspaces, allowlist and source configurations are stripped because group IDs may differ. * Allowlists have no item cap. When a fillable field has more than 100 options, Slack form modals automatically switch to a searchable dropdown that loads options on demand, so requesters can find any option by typing.