> ## 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. *** ## How custom fields work Custom fields are tied to specific forms. When someone creates a ticket using a form, they see both standard system fields (like title and description) plus any custom fields configured for that form. **Example:** A "Bug Report" form might include custom fields for bug severity, browser type, and steps to reproduce. A "Feature Request" form might include custom fields for business justification, priority level, and target users. Custom fields are only available when creating tickets through forms. *** ## Field types Single-line text input for short responses like names, titles, or brief descriptions. Multi-line text input for longer descriptions, explanations, or detailed information. Numeric input with validation for quantities, counts, or measurements. Date picker for scheduling, deadlines, or date-related information. When used in a [title template](/documentation/tickets/forms/overview#title-templates), date fields support format suffixes to control how the date displays in the generated title. Time input for selecting specific times of day. Time duration input for tracking time spans or estimated completion times. Select from predefined timezone options for scheduling and time-related information. Yes/No checkbox for binary choices or confirmations. Single-choice dropdown menu from predefined options. Multiple-choice dropdown menu allowing selection of multiple options. Choose a single organization member for assignments or mentions. Choose multiple organization members for assignments or mentions. Select from user groups in your organization. * Configure an **allowlist** with no item limit to restrict which groups appear as options * Filter by **source** to show only groups from a specific provider (Okta, Google Workspace, or groups created in Ravenna) * Manually created groups only appear in their assigned workspace. Synced groups are visible across all workspaces. Select from available tags to categorize tickets. Select from applications connected to your organization. Select multiple applications connected to your organization. * Configure an **allowlist** with no item limit to restrict which applications appear as options Select from application groups in your organization. Select from predefined ticket type options (e.g., Service, Incident, Question). Select from defined access levels for permission management. Upload files and attachments to tickets. Configure allowed file types and size limits. *** ## Create custom fields Create custom fields centrally in workspace settings: Go to **Settings > Fields** in your workspace. Click **Create Custom Field**. Fill in the required information: * **Label**: The name that appears on the form * **Description**: Help text explaining what this field is for * **Type**: Choose from available field types * **Required**: Toggle whether this field must be filled out. Turning this on at the workspace level makes the field required everywhere it appears and locks the per-form **Required** toggle so individual forms cannot opt out. Click **Create** to save your custom field. Create and manage custom fields directly within forms: Go to **Settings > Forms**. Select an existing form or create a new one. Drag and drop fields from the right panel into your form. The right panel has three tabs: * **Custom**: Create new custom fields * **Existing**: Use existing custom fields from other forms * **System**: Add system fields Use the dropdown menu in each custom field item to edit field properties. Toggle the private option to make a custom field visible only for the current form. *** ## Use existing fields Existing custom fields are non-private fields created from other forms or settings. Find them in the **Existing Custom Fields** tab in the form builder. These fields are shared across forms, meaning you can reuse them without recreating them. When you update an existing custom field that's shared across multiple forms, the changes apply to all forms using that field. *** ## Per-form label and description overrides Override the **label** and **description** of a shared custom field on a single form without affecting how the field appears on other forms. Use overrides when the same underlying data point needs different wording per audience. **Example:** A shared **Department** field can show as "Your department" on an employee-facing onboarding form and "Requesting department" on an internal procurement form, while still writing to the same field on every ticket. **Configure an override:** Go to **Settings > Forms** and select the form. In the form builder, click the field's title to rename it inline, or open the field's menu and choose **Edit** to update the description. Changes save automatically. The override applies only to this form. Clear an override to fall back to the field's shared label or description. Overrides do not change the field's key, type, options, or validation — only the displayed text on this form. Custom fields cannot be deleted when they are being used in a form. ### Preview impacted forms When you edit a shared custom field, Ravenna asks you to confirm the change and lists every form the field is attached to. When you try to delete a shared field that's still in use, the error dialog shows the same list so you can see exactly where it's referenced. Each entry in the list links directly to the affected form. The form you're currently editing is labeled **Current** and is not clickable. Use this list to: * Review which forms will be affected before saving a label, description, or option change. * Jump to other forms that need follow-up edits. * Locate every form that still references a field you want to delete. *** ## Use custom fields Once you've created custom fields and assigned them to forms: **Ticket creation** * Users see custom fields when creating tickets with that form **Ticket display** * Custom field values appear in ticket details * In table views, custom field columns are hidden by default. Show them from the column visibility menu. * URLs in text and textarea fields are automatically converted to clickable links, including `https://`, `http://`, `www.`, and bare domain formats **Ticket updates** * Custom field values can be updated after ticket creation from the ticket details page Learn more about [setting up forms](/documentation/tickets/forms/overview) and assigning custom fields to create complete ticket templates ## 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. If a 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**. * 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.