Customizing the suite

Every WorkSquares product lets an administrator extend its records without a developer: add a field, define an object, refuse a save that breaks a policy, calculate a value from other values. The machinery underneath is deliberately one thing — a single runtime engine in the shared platform library that validates field values, evaluates conditions and computes formulas, plus one set of authoring components — the field builder, the page-layout designer, the forms designer and the condition builder — that each web app mounts where it has adopted them. Only the field builder and the condition builder are in all three today: the page-layout designer is in CRM and CPQ, and the forms designer in CRM and Accounts.

That is why a condition you build in CRM looks and behaves the same in Accounts, and why what you preview while authoring is produced by the very code the server runs when it enforces the rule. Nothing here needs a deployment: a saved change applies to the next write — within about half a minute for a CPQ custom field.

What differs is how far each product has adopted it. CRM went first and goes deepest. CPQ has the widest authoring surface but wires the least of it into its record writes. Accounts adopted the engine last, enforces it on every object it registers, and has no screen for typing the values in yet. Read how far each product has taken it before you plan a customization project — it is the difference between a field that shapes your data and a field nobody can fill in.

What you can add to a record

Custom fields

A custom field is a named, typed slot on an object, stored alongside the record’s built-in fields and returned by the same APIs. All three products offer the same 23 field types, grouped in the picker as Text (text, long text, rich text), Number (number, decimal, currency, percent), Boolean, Date & time (date, date & time, time), Contact (email, phone, URL), Choice (picklist, multi-select), Relationship (lookup, master-detail) and Advanced (auto number, formula, roll-up summary, geolocation, JSON).

Each field carries:

• A label, and an API name derived from it as snake_case when you create it. The API name must be unique on the object and is immutable once saved — the dialog greys it out and says so — because stored values are keyed on it.
• Required, help text, description, display order, visible and read-only flags.
• Type-specific settings: picklist values (and whether values outside the list are allowed), a minimum and maximum for numbers, precision and scale for decimal types, a maximum length and a regular expression for text, and a formula expression with its return type.
• Your own error message, shown instead of the built-in wording whenever the field fails a check.

On save the server checks the value against that definition and returns failures field by field, so a form can land each message on the box that caused it: required fields must be present; numbers must be numeric and inside their range; text must be within its length and match its pattern; dates must parse; email and URL must be well formed; picklist values must be on the list. Computed types (formula, auto number, roll-up) and read-only fields are skipped — the user is not asked to supply them.

Changes take effect fast, though not always instantly. CRM and Accounts clear the runtime’s cached catalogue the moment you save, so a new field rule or validation rule bites on the very next write. CPQ does the same for validation rules; a custom-field change there is picked up within about half a minute.

What happens if the platform itself is unreachable

CRM and Accounts let a write proceed rather than block every save on a metadata outage. CPQ takes the opposite choice and fails the write instead of letting it past unchecked. This is about the catalogue being unreadable, not about a rule being wrong — a rule that cannot be evaluated is skipped everywhere.

Custom objects

A custom object is an entity of your own — Site Survey, Renewal Review — that sits alongside the built-in ones and holds nothing but custom fields.

CRM is the only product that completes the loop: you define the object under Customize and then create, edit and browse its records on a screen of their own. Because a custom-object record is its custom-field payload, every field you defined is checked on every create and update, and record-level validation rules run on them too.

CPQ lets you define objects and lays them out on a schema canvas showing their relationships, and its custom fields and validation rules can target them — but there is no records screen, so a CPQ custom object is a place to hang metadata rather than somewhere to keep data.

Accounts has no custom-object builder. Its object list is the fixed set of nine accounting objects that custom fields and validation rules attach to.

Page layouts and list views

Page layouts arrange an object’s fields into sections — one card per section, on a 1–4 column grid — with a drag-and-drop designer whose palette offers both the object’s standard fields and its custom fields. List views do the same job for a list page: which columns, in what order, with what sort, under an optional filter.

Only CRM reads them back at runtime. There, an authored layout drives the details area of the account, contact, lead, deal and case pages, and the default list view drives the columns and initial sort on those five lists — Customization in CRM has the full behaviour, including how authored filters apply and how CRM’s separate per-user saved views differ from admin list views. CPQ ships both designers under Admin, but nothing outside the admin area consumes what they produce, so a CPQ layout or list view is stored rather than rendered. Accounts offers neither.

Validation rules

A validation rule is a condition that blocks a save when it is true. Read it as “refuse the record when…” — the inversion catches people out. A rule names an object, a condition, the message the user should see, and optionally the field to hang that message on. Rules can be deactivated without being deleted, and a change applies to the next save.

Use them for the policies a product cannot know on its own: refuse an invoice over 100,000 with no purchase-order reference, refuse a deal in the closing stage with no close date.

If several rules fire on one save, the first rule’s message is what the user sees and every violation comes back with it. A rule that cannot be evaluated is skipped rather than treated as a block — a broken rule never silently freezes an object.

Forms

The forms platform captures structured information: an intake sheet, a supplier questionnaire, an expense justification. The designer is drag-and-drop — drop fields onto the canvas, group them into sections, click one to edit it — with a Rules tab for conditional behaviour (show this only when that was answered) and a preview that mounts the real renderer on the live schema, so what you see while authoring is what a person filling it in sees.

A form is created as a draft and must be published before it accepts anything — that gate holds in all three products. Each submission records the answers exactly as they were given, so a later edit to the form cannot rewrite its own history.

How much of the stored definition is re-checked on the server when a submission arrives is where the three part company, and it decides how much the definition is worth once something other than the browser is posting to it.

Server-side check on a submission	CRM	CPQ	Accounts
Form must be published	Yes	Yes	Yes
Required fields must be present	Yes	No	Yes — including a field a form rule has made required
Types, lengths, patterns, option lists, min/max	No	No	Yes, returned field by field

So a text answer over its maximum length, a malformed email address or a number outside its range is stored by CRM and CPQ and refused by Accounts. In CRM and CPQ those checks live in the renderer in the browser, which is what a person filling the form in goes through; a submission that reaches the API another way is kept as sent.

CRM and Accounts both ship the authoring end to end, on the same shared designer — see Customization in CRM and Platform & settings in Accounts. CPQ has the forms API but no forms designer in the web app, so a CPQ form is defined and filled through the API rather than on a screen.

Filling a form requires signing in. There is no public link to hand to someone outside the workspace.

Authoring conditions

Validation rules, workflow criteria, assignment rules, approval entry criteria and form rules are all authored with the same condition builder, so criteria look and behave identically wherever you meet them.

• Every group has three buttons — ALL, ANY and NOT — which are the AND, OR and NOT operators.
• Add Condition adds a row of field · operator · value. The operators offered follow the field’s data type, and the list is not the same for every type — see the table below.
• Add Group nests a group inside the current one, for criteria like industry is Retail and (amount over 50,000 or rating is Hot). Two levels of nesting below the top group are allowed; the button stops appearing after that.
• Rows can be dragged to reorder within their group.
• The field picker is fed by the app: the object’s standard fields followed by its active custom fields. In CPQ and Accounts, the validation-rule editor additionally keeps any field an existing rule already references, so reopening an old rule cannot silently drop a condition on a field that has since been deactivated.
• View / Edit JSON swaps the builder for a raw editor over the whole criteria block, and back again.

Which operators a field type offers

This table comes from the shared builder, so it is identical in CRM, CPQ and Accounts.

Field type	Operators offered
Text	equals, not equals, contains, does not contain, starts with, ends with, matches a pattern, in, not in, is empty, is not empty, exists, does not exist
Number	equals, not equals, the four comparisons (greater than, at least, less than, at most), between, in, not in, exists, does not exist
Date	equals, not equals, before, after, between, exists, does not exist
Yes/no (boolean)	equals, not equals, exists, does not exist
Multi-value (multi-select)	contains, does not contain, in, not in, is empty, is not empty, exists, does not exist

Only exists and does not exist are on every type. Three gaps catch people out when they go looking for an operator that is not there:

• is empty / is not empty are on text and multi-value fields only. On a date, a number or a yes/no field, use does not exist for the same idea.
• equals / not equals are on everything except multi-value fields — match one of those with contains or in.
• in / not in are on text, number and multi-value fields; a date or a yes/no field has neither.

Comparisons are type-aware and forgiving in the right places — "5" matches 5, "true" matches true, a comma-separated string works where a list is expected, and dates parse from strings — but a missing value never equals anything, so a blank field cannot accidentally match zero or an empty string.

Field names are matched flatly, not as paths: a condition names a field directly, and the spelling depends on the product.

Product	Standard fields are named	Custom fields are named
CRM	as the API returns them — camelCase, e.g. annualRevenue	by their API name
CPQ	by their stored column name, e.g. total_amount	by their API name
Accounts	by their stored column name, e.g. total_amount	by their API name

In every product you pick the field from the catalogue rather than typing it, so this matters mainly when you edit criteria as JSON or hand a rule to an integration.

Keep a NOT group to a single condition

A NOT group is negated as a whole: the engine reads it as not all of these hold, while the button reads as “none of the following”. With one condition inside, those mean the same thing. With two or more they do not — a NOT group holding two conditions is satisfied as soon as one of them is false. If you mean “none of these”, give each condition its own NOT group, or invert each row’s operator instead.

What a formula can reference

A formula field is written as an expression over the record’s own values — its standard fields and its other custom fields, named exactly as the field-naming table above describes. CRM and Accounts run the same expression engine in the browser preview and on the server, so a formula behaves the same in both. CPQ does not compute formula fields at all — see the table below.

It supports arithmetic (+ - * / % ^, and unary minus), + for joining text, comparisons (== != < <= > >=), logic (&& || !), and these functions:

IF · AND · OR · NOT · COALESCE · CONCAT · LEN · UPPER · LOWER · TRIM · ROUND · FLOOR · CEIL · ABS · MIN · MAX · SUM · POW · SQRT · TODAY · NOW

ROUND rounds half away from zero, the way a spreadsheet does, so money comes out where you expect it.

Two limits are worth planning around. A formula cannot reach outside its own record — there are no lookups into a related record and no aggregation over child records. And a name the engine does not recognise evaluates to nothing rather than raising an error, so a typo in a field name yields a quietly empty result instead of a complaint. A formula that cannot be evaluated at all — division by zero, a malformed expression — also yields an empty value rather than failing the record.

Where the expression is checked differs, and only one product checks it at all:

• CRM parses it when you save the field and refuses an invalid one with the parse error.
• Accounts requires an expression and a return type but does not parse either, so a bad expression is only discovered as an empty value later.
• CPQ does not check it when you save the field — and because CPQ never computes formula fields, it is never discovered later either. A wrong expression in CPQ is inert rather than wrong. The exception is a formula you ask CPQ’s assistant to draft: that one is validated, and re-drafted if it does not parse, before you are shown it — see AI assistance.

How far each product has taken it

Everything above is one platform. This is where each product actually stands.

What you can author

Capability	CRM	CPQ	Accounts
Custom-field builder	Customize → object → Fields	Admin → Custom Fields, plus a schema canvas and a field wizard	Settings → Custom fields
Objects you can extend	Lead, Account, Contact, Deal, Case, Product, and custom objects	Quote, Contract, Order, Product, Customer, Subscription, Invoice, Opportunity, and custom objects	Contact, item, invoice, bill, customer payment, vendor payment, journal entry, GL account, bank account
Field types offered	All 23	All 23	All 23
Reorder fields	Yes	No	Yes
Draft a field with AI	No	Yes — see AI assistance	No
Custom objects	Define, plus a records screen	Define, plus a schema canvas; no records screen	Not offered
Page-layout designer	Yes	Yes	Not offered
List-view builder	Yes	Yes	Not offered
Validation rules	Yes	Yes	Yes
Forms designer	Yes	API only	Yes

What actually runs

Behaviour	CRM	CPQ	Accounts
Where values are typed in	Lead, account, contact, deal, case and product forms, and custom-object records	Quote, customer, contract and product forms	Nowhere yet — no screen renders an input for a custom field
Field rules enforced on save	Account, contact, lead, deal, case, campaign, activity, quote, product, and custom-object records	Product and customer	All nine registered objects
Validation rules enforced	Account, contact, lead, deal, case, campaign, activity, quote, and custom objects	Product and customer	All nine registered objects
Formula fields computed	When a record is read, on lead, account, contact, deal, case, product and custom-object records	Never — a formula field is authored but no record is given a value	When a record is saved, and stored with it, on all nine objects
Page layouts rendered	Account, contact, lead, deal and case detail pages	No	Not offered
List views consumed	Columns and sort on the five core lists; stored filters apply through the API	No	Not offered

Three consequences are worth stating plainly, because they decide whether a customization project is worth starting today:

• In Accounts, define fields to shape validation, workflow conditions and API payloads — not to give someone a box to type in. The web editors carefully carry existing values through a save so nothing is lost, and the API and the workflow “update a field” action can write them, but no form renders one.
• In CPQ, you can type custom-field values on a quote or a contract, but the server only applies your field rules and validation rules when a product or a customer is saved. The validation-rule editor offers eight objects; only those two are gated by what you author there. Layouts and list views are stored but not rendered.
• In CRM, the pieces line up end to end for the five core objects plus products — the field is defined, the form renders it, the server enforces it, the layout arranges it and the list can show it.

Stored, but not acted on

Some settings the builders offer are recorded on the definition and go no further in any product. Plan around them rather than relying on them.

• Unique — nothing rejects a duplicate value.
• Default value — nothing pre-fills it on a new record.
• Roll-up summary — nothing aggregates child records; the field stays empty.
• Auto number as a field type — nothing allocates a number. For document numbering use the numbering engine instead: see Document numbering.
• Lookup and master-detail values are stored as given; nothing checks that the record they point at exists.

Formula is the only calculated field type that computes, and only in CRM and Accounts.

Who is allowed to change it

Metadata authoring is gated on the API in every product, the same way the rest of the product is — see Roles & permissions for the model.

• Accounts mounts one permission gate in front of every data route, so custom fields, validation rules and forms sit in the role matrix like everything else.
• CPQ declares the permission each metadata route needs.
• CRM gates authoring on a dedicated customization right. That right has no row in the roles grid today, so it cannot be granted to a custom role — plan for your customization owner to hold Admin, and keep that group small. Reading metadata only requires being signed in, which is what lets an ordinary user’s record page render an authored layout.

Sign-in is the real boundary

Some capabilities across these products are not governed by the permission matrix at all, so any signed-in user in the workspace can reach them whatever their role says. Do not treat unticking a right as a guarantee that covers the whole product: give an account only to someone you would trust with the areas it can reach.

How much of this is written down afterwards differs too. Accounts records most Settings changes in its activity log — custom fields, validation rules, forms, numbering and the masters among them — but workflow definitions and exchange rates are not on that map, so keep your own note when you change one. CRM audits validation-rule changes and form-definition changes — create, edit, publish and delete are each written to the trail. What is not audited in either CRM or CPQ is edits to custom fields, custom objects, page layouts and list views; CPQ additionally does not audit its validation rules or its forms. Where you need an accountable record of one of those, keep your own change note alongside it.

Connects to

• Customization in CRM — the fullest adoption, screen by screen, including page layouts, list views and masters.
• Automation in CRM — the workflow, assignment and duplicate engines that run on the fields and conditions defined here.
• Platform & settings in Accounts — custom fields, validation rules, workflows, approvals and forms in Accounts.
• CPQ overview and AI assistance — CPQ’s admin surface, and having a field, object or formula drafted for you.
• Document numbering — the other shared configuration engine, for the numbers on your documents.
• Notifications — what the suite tells people when a rule or a workflow acts.
• Roles & permissions — who may author any of this.
• One source of truth — the shared record model your customizations extend.