Custom Fields

Setup & Configuration

Issue Fields vs. Account Fields

Pylon has two categories of custom fields, managed on different settings pages:

• Issue custom fields (Settings > Issue fields): attached to individual issues. Used for categorization, AI classification, required-to-close workflows, and ticket forms.

• Account custom fields (Settings > Account fields): attached to customer accounts. Used for CRM-synced data, account health, and tier-based routing.

Both share the same field types and support AI, formulas, and triggers. The rest of this article covers configuration that applies to both unless noted otherwise. For guidance on when to use tags instead of custom fields, see the Tags vs Custom Fields article in this collection.

Creating Custom Fields

For issue fields, go to Settings > Issue fields. For account fields, go to Settings > Account fields (under the Customers section). Each field has a label (display name), slug (identifier used in APIs, triggers, and integrations), and a type that determines what data it stores.

A field's type cannot be changed after creation. If you need a different type, create a new field. Deleting a field requires removing all references to it first: ticket form settings, triggers, views, and any filters that use it.

Field Types

Select and Multi-Select Options

For Select and Multi-Select fields, you define the available options. Each option has a value (internal identifier, must be unique within the field), a label (display text), and an optional hex color for badge display. You can have up to 400 options per select field.

Required and Conditional Fields (Issue Fields Only)

Issue custom fields can be configured with three requirement settings:

• Not required (default).

• Required to close: must be filled before an issue can be closed. Required fields must be filled in to save any change to the issue, so every issue is properly labeled for analytics.

• Required under conditions: required only when specific filter conditions are met (e.g., state = "closed" AND team = "support").

Fields can also be conditionally shown based on other field values. A "Sub-Product Area" field that only appears when "Product Area" is set, for instance. This keeps the sidebar clean when gathering different details for bugs vs. feature requests.

AI Fields

Any custom field can be AI-enabled. There are two modes:

• Autofill: AI fills the field without confirmation. Best for high-confidence categorization like question type or product area. Fields filled by AI show a sparkles icon. Once manually updated, AI will not override the value.

• Suggestion: AI proposes a value that agents accept or reject in the sidebar. Better for fields where human review adds value, like priority or sentiment.

To configure AI on a field: enable AI on the field definition in Settings, add instructions describing how AI should determine the value, and for Select/Multi-Select fields, add AI descriptions to each option explaining when it applies.

AI fields can draw from issue content, call recordings, CRM data, and AI context in notebooks. They provide reasoning and citations alongside the output. AI runs when an issue is created and does not retroactively fill existing issues. To re-trigger AI on an existing issue, add an internal note or click the Fill with AI button (sparkles icon) next to the field in the sidebar.

Formula Fields

Formula fields calculate values automatically and can adopt any data type. They work anywhere custom fields do: views, triggers, APIs. Some examples: count of meetings with a customer in the last 90 days, seat utilization percentage from CRM fields, health score weighted across multiple components, lifecycle stage based on contract progress.

Populating Fields

Custom fields can be populated through multiple channels:

• Manual entry in the issue sidebar or account page

• AI Autofill or Suggestion (issue fields)

• Triggers and macros using the Set custom field value action

• Ticket forms: collect values from customers via web, Slack, customer portal, or chat widget. Supports conditional fields and AI Form Suggestions that auto-suggest KB articles as users fill forms.

• Slack data collection: collect fields like Severity as dropdown or text inputs when tickets are opened in Slack. Values sync directly into custom fields.

• Customer portal: designate fields as visible or editable by end users in portal settings.

• REST API: set fields via POST /issues or PATCH /issues/{id} using the field slug.

• Chat Widget JS API: window.Pylon("setNewIssueCustomFields", { slug: "value" }) to set fields on widget-created issues.

• CRM sync: fields synced from connected CRM systems are updated multiple times per day.

• Migration tools and ETL processes for bulk data import.

• Formulas: computed automatically.

Field Visibility

Control where fields appear:

• Sidebar visibility: hide fields from specific modules (e.g., show only in Issue Details, hide from Account Details).

• Conditional visibility: show or hide fields based on issue properties like state, assignee, or team. Different rules can apply for internal staff vs. customer portal users.

• Portal visibility: configure which fields customers can see and modify via portal settings.

For configuring module order and which fields appear in the issue sidebar, see the Account & Issue Setup (Sidebar) article in this collection.

Field History

All custom field changes are tracked in Field History: who changed the value, when, and the old/new values. For AI fields, the reasoning and citations are also captured. This gives you an audit trail for compliance and helps teams understand how values evolved.

Account Field Examples

Common account custom fields by category:

• Activity and Engagement: Last Contacted Date (Date), Last Inbound Issue Date (Date)

• Account Setup: AI Agent Enabled (Boolean), Features In Use (Multi-select)

• Routing: Support Tier (Select)

• Lifecycle: Contract Start Date (Date), Renewal Date (Date), Billing Cadence (Select), ARR (Number), Seat Count (Number), Expansion Opportunity (Select), Churn Risk Level (Formula)

• Product: Current Plan (Select)

Best Practices

Naming Conventions

Use clear, descriptive labels ("Support Tier" not "Tier"). Be intentional with slugs since they appear in APIs, triggers, and integrations and are harder to change later. For Select and Multi-Select options, keep labels concise and mutually exclusive.

AI Field Tips

Write detailed instructions for the field's AI configuration. The more context you provide, the better the results. For Select/Multi-Select fields, describe when each option should be selected and include examples.

Start with Suggestion mode to review accuracy before switching to Autofill. AI fields are evaluated at issue creation. If you use AI field values in triggers, trigger on "field change" rather than "issue created" so the AI value is set first. Filtering to issue status = New alongside the field change is also recommended. Include a catch-all "Other" option in Select fields so AI always has a valid fallback.

Using Fields in Views

Custom fields integrate directly into Views (both Kanban and List). You can filter issues by any field value, combine multiple field filters with AND/OR logic using Filter Groups, add fields as columns in List view, group issues by Select/Multi-Select values in Kanban view, and sort within groups.

For a full guide to view creation and management, see the Views article in this collection.

Using Fields in Triggers

Fields work with triggers in two ways. As conditions: filter trigger execution based on field values (e.g., only run when Priority = "High"). You can select from default and custom attributes on issues, accounts, and contacts. As actions: use the Set custom field value action to automatically fill a value. Note that this action appears under that exact name, not under the field's label. You will not find "Set Priority" in the action list; look for Set custom field value instead.

For a full guide to trigger setup, see the Triggers & Macros article in this collection.

Migration Specific Notes

Planning Your Field Schema

Before migrating, audit your existing tool's fields and map them to Pylon:

1. List all existing fields from your current tool (Zendesk, Intercom, Front, etc.).

2. Decide field vs. tag for each. Structured data goes to custom fields; simple labels go to tags. See the Tags vs Custom Fields article for a detailed comparison.

3. Choose field types carefully. Types cannot be changed after creation.

4. Plan your slugs if you use the REST API or JS API.

Migration is a good opportunity to prune. Only bring over fields that will be actively used in workflows or contain historical data that must be preserved.

CRM Field Mapping

If syncing from a CRM:

• HubSpot: only Company-level fields are supported today. If you need Deal-level properties (e.g., annual contract value, support tier), roll them up to Company properties in HubSpot first.

• Salesforce: Account and Contact field mapping is supported. Configure in Settings > Apps Directory under Salesforce.

Migrating Account Fields

Account custom fields can be migrated in two ways: by creating an exact replica with the same field values (recommended for multi-select fields), or by recreating the field from scratch and mapping data during migration.

When copying fields exactly, watch for multi-select issues. Multi-select fields with many options retain all options in Pylon, which leads to clutter if not cleaned up. Nested dropdown menus from other tools are flattened: a Zendesk field with Value_1 leading to Value_2 becomes "Value_1::Value_2" in Pylon.

External App Data

Data pulled from external app integrations (custom apps) is not usable in trigger conditions. If you need external data to drive routing or automation, use the Pylon REST API to write that data into custom fields directly.

Backfilling Existing Issues

AI fields only run on new issues. For historical data, use the REST API to bulk-update field values, or add an internal note to re-trigger AI evaluation. Consider doing a manual backfill for a set time period (e.g., last 30 days) and relying on AI for new issues going forward.

Common Migration Gotchas

• The "Send and close" keyboard shortcut may bypass required field validation. Make sure agents fill required fields before closing.

• Custom dashboards and analytics are dynamically generated based on your configured fields. There is no fixed list of metrics; it adapts to your setup.

• When updating tags via API, the new array replaces all existing tags. It does not append. Include the full desired tag list in each update.

• The trigger action to set a field is called Set custom field value, not the field's own label. Customers commonly search for their field name and cannot find the action.

• Custom fields must exist before importing data. If you plan to import historical issues with field data, create all field definitions first.

• CRM field sync should be configured during initial setup so historical and future data syncs correctly from day one.