Customization

How administrators shape CRM to fit the business — extend the data model, arrange how records are viewed, capture data through forms, number documents, curate the reference lists behind every dropdown, and decide who can see and do what. What you author here is read back at runtime by the detail and list pages people use every day.

What you can do

Custom fields

• Add custom fields to standard and custom objects, then reorder them and read them back through the same APIs as built-in fields. Fields participate in validation, workflow and assignment rules.
• Choose from 23 field types, grouped in the field builder as text, number, boolean, date & time, contact (email / phone / URL), choice (picklist and multi-select), relationship (lookup, master-detail) and advanced.
• On save, the platform checks required fields, type (number, date, email, URL), length and range limits, and picklist values — and returns the failures field by field.
• Formula fields are evaluated when records are read, from an expression you write against the record’s standard and custom fields. A formula that can’t be evaluated yields an empty value rather than failing the read. Formulas are computed on leads, accounts, contacts, deals, cases, products and custom-object records.

Where custom fields apply

Values are validated on save wherever they are set.

Object	Where fields are defined	Where values are edited
Lead, Account, Contact, Deal, Case, Product	Customize screen	The record’s form in the web app
Custom objects	Customize screen	The object’s Records screen
Campaign, Activity, Quote	API only	API only

Roll-up summary and auto-number are field types, not calculations

Both appear in the field-type picker, but nothing calculates them — a roll-up never aggregates its children and a custom auto-number field never allocates a number. Formula is the only calculated field type. For document numbering use auto-numbering.

Custom objects & records

• Define your own custom objects and manage their records with full CRUD — new entities that sit alongside leads, accounts, deals and cases.
• Custom-object records run through the same write path as standard entities, so custom-field validation and record-level validation rules fire on them too — and since a custom object’s whole record body is its custom-field payload, every field you define is checked on create and update. Duplicate and workflow rules do not run on them; those engines are wired to the five core objects only.

Page layouts

• Arrange fields and sections into page layouts — one card per section, with a 1–4 column grid — using a drag-and-drop designer whose palette offers both the object’s standard fields and its custom fields.
• Layouts render at runtime on the detail pages for accounts, contacts, leads, deals and cases in the web app. The object’s default layout (or the first one, if none is marked default) drives the details area; where no layout has been authored, the built-in sections are used unchanged. A field name the page doesn’t recognise is skipped rather than breaking the page, so a layout left over from a deleted field stays safe.
• Layouts govern the field sections only. Purpose-built panels — SLA status, lead score, deal stage progress, addresses, related lists — always render.
• The mobile apps do not read page layouts; they use their own screens.

List views

CRM has two distinct kinds of view, and they do different jobs.

Admin list views are metadata you author per object, alongside layouts and fields.

• The default admin view drives the columns and initial sort on the leads, accounts, contacts, deals and cases list pages. Matching columns keep their built-in formatting; a column for a custom field gets a generic renderer. Header clicks still override the view’s sort.
• The builder’s column palette offers the object’s custom fields; standard columns keep the list page’s own defaults unless the view is authored through the API.
• A view’s stored filters are executed server-side — compiled into SQL over a per-object column allowlist, so both the page and the row count are filtered in the database. Equality, comparisons, text matching (contains, starts with, ends with), in, between, presence checks and nested AND / OR / NOT groups are all supported. A filter on a field that has since been removed is skipped rather than breaking the list.

Authored filters apply through the API, not the list pages

The five core list endpoints accept a viewId and apply that view’s filters and sort. The web list pages ask only for the default view’s columns and sort, so an authored view’s filters bite for API callers and integrations rather than for someone clicking through the app.

Personal saved views are the picker on each list page.

• Save the filters currently applied to a list under a name, then switch between them; set (or clear) a default, which is applied automatically the next time you open the list.
• Choose private, shared (with named roles or users) or public visibility.
• Available on the main lists across the app: leads, accounts, contacts, deals and cases, plus activities, tasks, campaigns, products, pricebooks, quotes, sales orders, purchase orders, goods receipts, stock, vendors, locations, currencies and masters.

Forms

• Build forms in a drag-and-drop designer: drop field types onto the canvas, organise them into sections, and click a field to edit it.
• Add conditional rules so fields appear or behave differently based on what has been filled in, and preview the form before you save it.
• Publish a form to start accepting submissions, then collect and review them.
• Submissions are validated against the published schema: a form that is still a draft (or has been archived) rejects submissions outright, and a submission missing any field the schema marks required is rejected with the specific fields named. Each submission records the form version it was filled against.

Auto-numbering

Document numbers are configuration, not code. The Auto-numbering screen under Customize lists the document types whose numbering you can change, and lets you set the format of each.

Document type	Default format	Example
Invoice	INV-{SEQ:6}	INV-000001
Payment	PAY-{SEQ:6}	PAY-000001
Quote	Q-{SEQ:6}	Q-000001
Sales order	SO-{SEQ:6}	SO-000001
Case	CAS-{SEQ:6}	CAS-000001

For each type you control:

• Format — free text plus tokens. {SEQ} or {SEQ:n} (zero-padded to n digits, or write {000000}) for the counter, and {YYYY}, {YY}, {MM}, {DD}, {Q} for date parts. Exactly one sequence token per format.
• Reset period — never, yearly, monthly or daily.
• Start value and increment.

A live preview shows the number your format will produce as you type, using the same engine the server uses, so what you preview is what you get. Configurations are validated before they save: a yearly reset needs a year token, a monthly reset needs year and month, and a daily reset needs year, month and day — otherwise numbers would repeat across periods.

Numbers come from an atomic per-tenant counter, so two people saving at the same moment can never be handed the same number — and where the save runs in a transaction, such as a payment, an invoice raised from a sales order or a quote converted to a sales order, a rollback releases the number instead of burning it. Until you save a configuration the built-in default is in effect and the screen marks it Default.

Not everything numbered is configurable. Purchase orders, goods receipts and put-aways use a fixed built-in format (PO-00001, GRN-00001, PUT-2026-000001) that the Auto-numbering screen does not cover. Leads, accounts, contacts and deals are not numbered at all.

Common masters

Reference lists back the dropdowns across CRM. Masters is a full admin area, not a single list: a combined screen with search, type and status filters, plus a dedicated screen and purpose-built form for each of the 14 master types.

Area	Master types
Sales & marketing	Lead source, Account type, Industry, Rating, Ownership
Service	Case origin, Case reason, Case priority
Work management	Task priority, Approval status
Geography	Country, State, City
Finance	Tax

• Every entry carries a code, name, description, sort order, optional icon and colour, and an active flag, so you can retire a value without breaking the records that already use it.
• Country → State → City are hierarchical: a state belongs to a country and a city to a state, and you can browse an entry’s children.
• Entries are soft-deleted and restorable, and can be looked up by type or by type and code — which is how integrations resolve a value without guessing at an ID.

Roles & permissions

Access control is a per-resource permission matrix granted to roles. There are no permission sets — a user’s access is the union of the matrices of every role they hold.

• Define roles, assign users to them, and edit each role’s matrix in a rights grid. Five actions drive enforcement — view, create, update, delete and approve. The grid offers six more — export, import, print, bulk update, share and clone — but those are recorded on the role and held for future use rather than checked, so build your access design out of the five.
• The matrix is keyed on the navigation catalogue, so the same edit governs both what appears in the menu and what the API will allow.
• Read a user’s effective permissions — the union across their roles — from a single endpoint.
• The built-in Admin role is a bootstrap superuser and bypasses the matrix, so a tenant can never lock itself out of administration.

How the API enforces it

Each data router carries the guard as a whole, so every endpoint under it is covered, including ones added later. The guard maps the HTTP method and path onto a permission action:

Request	Action required
GET / HEAD	View
POST to the collection — POST /deals	Create
PUT / PATCH	Update
POST under a record — POST /deals/{id}/close-won	Update
POST …/approve, POST …/reject	Approve
DELETE	Delete

Around two dozen resources are guarded this way: leads, accounts, contacts, deals, opportunities, pipelines, forecast, cases, knowledge, activities, campaigns, quotes, products, pricebooks, invoices, sales orders, purchase orders, goods receipts, put-away, warehouse locations, vendors, reports and dashboards.

The mobile API is gated by the same matrix, resolving each request to the same resource names and applying the same method-to-action rules — so a role that can only view deals on the web can only view deals on mobile, and the app is not a way around your access design. Coverage across the two surfaces is close but not identical, so it is worth trying a new role on both before you roll it out.

Authoring the metadata on this page follows the same model: creating and editing custom fields, custom objects, page layouts, list views, forms and auto-numbering rules needs the customization permission, and managing roles needs the roles permission. Reading that metadata only requires being signed in, which is what lets an ordinary user’s record page render an authored layout.

The customization permission is the one right with no row in the matrix, so it cannot be granted to a custom role from the Roles screen — today that work belongs to Admin. Plan for your customization owner to hold Admin, and keep that group small.

What the matrix does not cover

A few areas of the app are still gated on sign-in alone rather than on the matrix, so any signed-in user in the tenant can reach them whatever their role says. Do not treat unticking a right as a guarantee that covers the whole product: for now, tenant sign-in is the real boundary, and an account should only go to someone you would trust with those areas.

The six extra columns in the grid above are the same story: recorded on the role, held for future use rather than checked. Build your access design out of the five enforced actions.

In the web app

The web app fetches the signed-in user’s effective permissions once per session and uses them to render a clear “You don’t have permission to view this” page instead of a broken screen, and to surface a message whenever the server refuses an action. That guard is a courtesy, not the boundary: it deliberately fails open — an unmapped route or a failed permissions fetch still lets the page render, because the API refuses the underlying data calls anyway.

Admin-configurable

Everything on this page is administrator-controlled, subject to the gating above. Nothing here requires a deployment or a developer — layouts, views, fields, forms, numbering and masters all take effect as soon as they are saved.

Connects to

• Automation — validation, workflow and assignment rules operate on the custom fields and objects defined here.
• Roles & permissions — the suite-wide vocabulary of users, roles and permissions; how CRM enforces it is described above.
• Platform data model — customizations extend the suite’s shared record model.