Custom Fields & Custom Data

Custom fields let you capture the structured data that matters to your business on every ticket and every contact. RapiDesq ships with a sensible set of standard fields (status, priority, channel, email, and so on), but your support operation almost certainly tracks information those standard fields don't cover — account numbers, subscription tiers, order references, regions, renewal dates, VIP flags, internal IDs. Custom fields are where that information lives.

Overview

Custom fields in RapiDesq are:

Key idea

The most valuable custom fields are the ones you'd ask an agent to write in a note anyway. Capturing that information in a structured field instead means you can search it, filter by it, and report on it. "Account number: 47839" in a note is a clue. "Account number" as a custom field is data.

Where Custom Fields Exist

RapiDesq supports custom fields in two places:

Ticket Custom Fields

Ticket custom fields capture information specific to an individual support request — things that change per ticket. Examples: the order number the ticket is about, the specific error message the customer reported, the product version they're running, the reason for closure, or a link to a related issue in your bug tracker.

Ticket custom fields appear on the ticket detail view, can be set by conversation flows and web form mappings, and are included in ticket search, filters, and reports.

Contact Custom Fields

Contact custom fields capture information about a customer that stays consistent across all their interactions — things that are true about the person or company, not about a specific ticket. Examples: account number, subscription tier, contract renewal date, region, preferred language, VIP status, internal CRM ID, or industry segment.

Contact custom fields appear on the contact profile, can be populated from any interaction source (forms, API, import, manual entry), and are included in contact search, filters, segmentation, and reports.

Tip — where should this field live?

If the value is about this particular support request and might differ from one ticket to the next for the same customer, it's a ticket custom field (error message, order number, closure reason). If the value is about the customer and tends to be the same across their tickets, it's a contact custom field (subscription tier, account number, region). When in doubt, ask: "If this customer contacts us again next month, should this value carry over automatically?" If yes, it's a contact field. If no, it's a ticket field.

Field Types

Six field types are available. Each one comes with its own input UI, validation, and search behavior. Choose the type that best matches the data you're capturing — it's more work to change the type later than to get it right the first time.

Type Best for Input appearance
Text Free-form identifiers and descriptions: account numbers, order references, error messages, internal IDs, CRM record URLs that don't need to be clickable. Single-line text input with optional validation pattern and character limits.
Number Quantities, counts, or numeric identifiers that you might sort or aggregate: invoice amount, number of affected users, severity level on a numeric scale, annual contract value. Numeric-only input with optional minimum, maximum, and step settings.
Dropdown Controlled choice lists where standardization matters: subscription tier, region, product line, issue category, closure reason, industry segment. Use dropdowns instead of free text whenever the set of valid values is known and small enough. Select control showing the list of predefined options.
Date Any date-related value: contract renewal date, incident date, desired delivery date, onboarding completion, warranty expiration. Date picker that respects the user's configured timezone.
Checkbox Boolean attributes with a clear yes or no: VIP customer, requires callback, escalation approved, beta participant, do not contact. Checkbox with a single true/false value.
URL External links you want agents to be able to click: CRM record URL, bug tracker issue, internal wiki article, customer-facing order tracking page. Text input validated as a URL; renders as a clickable link in the agent view.
Prefer dropdowns for controlled vocabularies

If the set of valid values is small and known in advance, use a dropdown. Free-text fields are convenient but they produce inconsistent data — "Enterprise", "enterprise", "Ent", and "Ent." all mean the same thing to a human and nothing at all to a filter or report. A dropdown with four clean options is worth a small up-front setup cost for every future search, filter, and report that uses the field.

Field Properties

Every custom field supports a consistent set of configuration properties, regardless of type. Some are required, some are optional, and some only apply to specific types.

Property Required? Description
Name Yes A unique identifier used internally for mappings, automations, and references. Use descriptive camelCase names like accountNumber, subscriptionTier, or orderReference. Names cannot be changed after the field is created, so choose carefully.
Label Yes The human-readable label displayed to agents above the input. Unlike the name, the label can be changed freely without affecting any integrations or automations.
Description No A brief explanation of what the field captures and when to fill it in. Appears as a tooltip or help icon next to the field in the agent interface.
Required No When enabled, agents must fill in the field before they can save or resolve a ticket (or save a contact). Use required sparingly — overusing it slows down agents and encourages placeholder values.
Placeholder No Example text shown inside the empty input as a hint. Applies to text, number, and URL fields. Use it to show expected format, not to explain what the field is for (that's what Description is for).
Help text No Short explanatory text displayed below the input field. Useful for clarifying when or how to fill it in.
Default value No A value automatically set when a new ticket or contact is created, before any agent or automation sets it explicitly. Useful for checkbox fields (default false) and for dropdown fields with a sensible starting point.
Validation pattern No For text fields: a regular expression that values must match. Useful when a field follows a known format (like an order reference that always starts with "ORD-" followed by digits).
Options Dropdown only The list of valid choices for a dropdown field. Each option has a value (stored internally) and a label (shown to agents). You can reorder and update options later without losing data for tickets or contacts that used earlier values.
Display order No An integer that controls the position of the field in the ticket or contact view. Lower numbers appear first. Use increments of 10 (10, 20, 30) so you can insert fields later without renumbering everything.
Category or group No An optional grouping so related fields display together in the agent interface. For example, all billing-related custom fields could share a "Billing" group.

Creating Custom Fields

Custom fields are created in the admin interface, separately for tickets and contacts. You need the manage settings permission to create or edit custom fields.

Creating a ticket custom field

  1. Navigate to Admin > Ticket Settings > Custom Fields.
  2. Click Add Field.
  3. Choose the field type (text, number, dropdown, date, checkbox, or URL).
  4. Enter the Name (internal identifier, cannot be changed later) and the Label (displayed to agents).
  5. Fill in any type-specific properties — options for a dropdown, minimum and maximum for a number, validation pattern for a text field.
  6. Configure optional properties: Description, Required, Placeholder, Help text, Default value, Display order.
  7. Click Save. The field is immediately available on all ticket views and can be referenced from web form mappings, conversation flows, and API integrations.

Creating a contact custom field

  1. Navigate to Admin > Contacts > Custom Fields.
  2. Click Add Field.
  3. Choose the field type.
  4. Enter the Name and Label.
  5. Configure the type-specific and optional properties as above.
  6. Click Save. The field is available on all contact profiles from that point forward.
Note — adding a field doesn't back-populate

When you add a new custom field, it's blank on tickets and contacts that already existed before you created it. That's by design — the system doesn't invent values for historical records. If you need to populate the field on older tickets or contacts, you can edit them individually, use a bulk import to update them, or (for contacts) use an API call to enrich existing records.

Populating Custom Fields

Manual entry by agents is the most obvious way to populate custom fields, but it's usually not the best way. Automation produces more consistent data with less agent effort. RapiDesq supports several automated paths.

Manually by agents

Agents can fill in or update any custom field directly from the ticket or contact view. The input type determines the interaction: a dropdown shows its options, a date field shows a date picker, a checkbox toggles, and so on. Changes are saved immediately and recorded in the audit log.

From web form submissions

When you build a web form, you can map each form field to a ticket or contact custom field. When a customer submits the form, the values they entered flow directly into the mapped custom fields on the ticket that's created.

For example, a form that asks for "Order number" and "Product affected" can map those answers to the orderNumber and productAffected custom fields on the resulting ticket. The agent never has to copy the values over.

From conversation flows

Custom fields can be set by conversation flows using the Update Ticket node. A flow that asks the customer "What's your subscription tier?" and collects the answer into a flow variable can then use Update Ticket to write that value into the ticket's subscriptionTier custom field before the ticket reaches an agent.

The same pattern works for values the flow obtains from external systems. An API Call node that looks up the customer's account in your CRM can return their account status, which a subsequent Update Ticket node writes to the appropriate custom field.

From the API and webhooks

External systems can create and update tickets and contacts via the RapiDesq API, including setting custom field values in the process. This is the right path when:

From bulk import

When you import contacts (and, in some scenarios, tickets) from a CSV file or another source, the import can include columns that map to custom fields. The importer matches column headers to custom field names or labels, and writes the imported values directly.

This is the fastest way to initialize custom field values on a large number of existing contacts — for example, when you first introduce a "Subscription tier" field and want to back-populate it for every contact based on data from your billing system.

Prefer automation over manual entry

Every custom field you can populate automatically is one fewer field your agents have to think about. The pattern that scales best is: forms and flows populate most fields at the point of entry, API and import handle back-population and cross-system sync, and manual entry is reserved for the handful of fields that really do require agent judgment.

Using Custom Fields

Once custom fields exist and have values in them, they become first-class citizens of the platform. Here's where they show up.

Ticket and contact detail views

Agents see all relevant custom fields on the ticket or contact they're looking at, ordered by the display order you configured. Fields grouped into a category are shown together. Agents can update any field they have permission to edit, and changes are saved immediately.

Search, filters, and saved views

Every custom field is automatically available as a filter criterion in ticket and contact list views. Supervisors and admins can build saved views that filter by custom field values — "all tickets where Subscription tier is Enterprise and Priority is Urgent" or "all contacts where Region is EMEA and VIP is true".

Search also respects custom fields: you can search for a specific value (an order number, a CRM ID, an account number) and find the tickets or contacts where it matches.

Routing and automation

Conversation flow Conditional Branch nodes can evaluate custom field values to make routing decisions. "If Subscription tier equals Enterprise, route to the enterprise support team" is a standard pattern, and it works off the same custom field that holds the subscription tier for ordinary display purposes.

Reporting and dashboards

Custom fields can be used as breakdowns in reports: ticket volume by subscription tier, average resolution time by issue category, SLA compliance rate by region. They can also be included as columns in exports so the raw data is available for analysis in external tools.

AI bot and agent context

When the AI bot handles a conversation, it has access to the relevant custom fields on the contact (and on the ticket, if one exists) as context. A bot grounded in your knowledge base and aware that the customer is an Enterprise-tier user can respond differently than it would for a Free-tier user, without you having to build separate bots.

The same applies to agents: when they open a ticket, the custom fields on both the ticket and the associated contact are visible in the detail view so the agent has full context before they start typing.

Common Examples by Business Type

To make this concrete, here are custom field patterns that tend to show up across different kinds of businesses. Yours will differ — these are starting points, not prescriptions.

B2B SaaS

E-commerce

Service businesses (agency, consultancy, MSP)

Internal IT / HR helpdesk (using the employee portal)

Best Practices

Start with a handful of fields, add more as you learn

It's tempting to try to design the full custom field schema up front. Resist. Start with five to ten fields you know you need based on current operations, see how they're used in practice, and add new ones as real gaps emerge. Over-designed schemas lead to fields nobody fills in reliably, which is worse than not having them at all.

Prefer dropdowns over text for controlled vocabularies

If the valid values are known in advance, use a dropdown. "Region" as a dropdown with (EMEA, NA, APAC, LATAM) is reliably filterable and reportable. "Region" as a free-text field becomes "Europe", "EMEA", "emea", "Europe - UK", "UK", and twelve other variants that mean the same thing. Every report that tries to group by region now has to handle the mess.

Design for reporting, not just capture

Before creating a field, ask: "What report or filter am I going to use this for?" A field that's written but never read is overhead. A field you'll segment reports by, route on, or filter saved views by is carrying its weight. If you can't name a concrete use, consider whether the information belongs in a note instead.

Use required sparingly

Every required field is a friction point in the agent workflow. Required fields slow agents down, and when required fields don't have good default or auto-populated values, agents will enter placeholder values ("N/A", "unknown", ".") just to get past the validation — which ruins the data quality you were trying to enforce. Make fields required only when you truly cannot resolve a ticket or save a contact without the value.

Automate population wherever possible

A field populated by a web form mapping, a conversation flow, or an API call is populated consistently, every time, without agent effort. A field that depends on agent manual entry is populated unevenly and incompletely, even with the best intentions. Always ask: is there a form, flow, or API path that could fill this in automatically?

Review the schema periodically

Every few months, look at your custom fields and ask: Which ones are actually being filled in? Which ones are being used in reports and filters? Which are dead weight? Archive (or delete) the dead ones and focus on the fields that are earning their place. A small, active schema is much more useful than a sprawling one where most fields are empty most of the time.

Name fields descriptively and consistently

Internal names are permanent, so invest in them up front. Use camelCase for consistency (orderNumber, subscriptionTier, contractRenewalDate), and make them specific enough that someone reading an integration or automation that references them can tell what they are without opening the admin interface. tier is ambiguous; subscriptionTier is not.

Be thoughtful about sensitive data

Custom fields are not the right place for data that requires special handling — payment card details, government IDs, health information, or anything else subject to specific regulatory regimes. Use them for business identifiers, categories, and workflow metadata. Sensitive data should be referenced by identifier (an internal customer ID that points to a record in a system designed to hold that data) rather than stored directly in the custom field.

Important — treat custom fields like tenant-wide metadata

Custom field values are visible to everyone on your team who has access to the ticket or contact they're attached to. They're retained according to the tenant's data retention policy and included in any exports and audit log entries. If a piece of data needs narrower access or different retention rules, don't put it in a custom field — keep it in the system built for it and reference it by ID.