Custom Fields

Custom fields let you capture information that doesn't fit Ascent's built-in fields — an internal reference number, a contract identifier, a dropdown of your own categories, a checkbox, and more. You define a field once, and it then appears on the records it applies to so your technicians can fill it in.

Plan availability

Custom fields are part of the Professional, Teams, and Enterprise plans. On plans that don't include the feature, the API and the custom-field sections of the UI are unavailable.

Overview

A custom field has three core properties:

• A name (what technicians see as the field label).
• A type that controls how the value is entered and stored.
• An entity type that controls which kind of record the field is attached to.

You can also mark a field required and control the order fields appear in. Each field's values are stored per record, so a "Contract number" ticket field holds a different value on every ticket.

Every create, update, delete, and reorder of a custom field — and every change to a stored value — is recorded in the audit log.

Field types

Choose the type that matches the data you want to capture. The type determines the input control technicians see and how the value is validated.

Type	Captures	Input
Text	A short single-line string	Text box
Textarea	A longer multi-line note	Multi-line text box
Number	A numeric value	Number input
Date	A calendar date	Date picker
Date & time	A date with a time	Date-and-time picker
Select	One choice from a list you define	Single-select dropdown
Multi-select	Several choices from a list you define	Multi-select
Checkbox	A yes/no flag	Checkbox (stored as Yes/No)
URL	A web address	Text box validated as a URL
Email	An email address	Text box validated as email
Phone	A phone number	Text box

For Select and Multi-select fields, you provide the list of options technicians can choose from.

Entity types

A custom field is scoped to a single kind of record. The supported entity types are:

• Ticket
• Client
• Contact
• Asset
• Invoice
• Quote
• Project
• Document
• Credential
• Vendor

A field defined for one entity type never appears on another — a "Warranty expiry" asset field shows up only on assets, not on tickets.

Where custom fields appear

Today, custom fields are surfaced in the application on tickets:

• New ticket form — any ticket custom fields you've defined appear as additional inputs while a technician is creating a ticket. Required ticket fields must be filled in before the ticket can be saved.
• Ticket detail — an editable Custom Fields card shows the current values on a ticket. Technicians with permission to edit the ticket can update them; the card is hidden entirely when no ticket custom fields are defined.

Fields for the other entity types are managed through the API and stored against their records, ready to be displayed as those surfaces are added.

Required fields

When a field is marked required, technicians must provide a value before the record can be saved. Ascent enforces this both in the browser (an inline message names the missing field) and on the server, so a required value can't be skipped by any client.

Managing custom fields via the API

Custom field definitions and values are managed through the /api/custom-fields endpoints, which power the in-app custom-field experience. Each request must be authenticated as a user in your organization (or with a scoped API key) on a plan that includes custom fields. Key operations include:

Operation	Endpoint
List the fields defined for an entity type	GET /api/custom-fields?entityType=TICKET
Create a field	POST /api/custom-fields
Update a field (name, options, required, order)	PATCH /api/custom-fields/{fieldId}
Delete a field	DELETE /api/custom-fields/{fieldId}
Reorder fields	POST /api/custom-fields/reorder
Set a value on a record	POST /api/custom-fields/values
Read a record's fields with their values	GET /api/custom-fields/with-values/{entityType}/{entityId}

Deleting a field definition removes the field and all of the values stored for it across your records.

See the in-app API Reference (/api/docs) for the full request and response shapes.