Read the customization ladder in Setup
- 1
Process Studio groups save-time rules, scripts, UI components, workflows, approvals, integrations and sync profiles.
- 2
Business Rules is the declarative save-time surface and often the lowest maintainable rung for record behavior.
- 3
New starts authoring only after the requirement has been placed on the correct customization rung.
- 4
Search, filter and refresh help locate existing logic before a duplicate or competing rule is introduced.
- 5
Status, actions, execution order, priority and update columns provide evidence when multiple rules interact.
Setup makes the ladder visible in its navigation. Design Studio shapes entities and experiences; Process Studio holds declarative Business Rules alongside scripts, components, workflows, approvals, integrations and sync profiles; Data Studio governs analytical models; and the remaining areas handle AI, access and feature operations. The active Business Rules register is intentionally shown because a save-time rule is often the lowest maintainable answer to a behavioral requirement.
Use the screen hierarchy as a decision aid before selecting New. First decide whether the request changes data shape, presentation, save-time behavior, orchestration, approval or an external boundary. Then search the existing register so a new definition does not duplicate logic already active elsewhere. The screenshot uses visible synthetic demo2 data so readers can follow realistic rows, values and controls together; production exports and screenshots must still remain inside authorized channels.
Everything in this section is about making xMatix behave the way your business does — new business objects, different forms, save-time enforcement, sign-off chains and server-side logic — without waiting for a release. The tools form a ladder, and the one rule that keeps a tenant maintainable is to pick the lowest rung that genuinely solves the problem: configuration before rules, rules before scripts, and code only when nothing declarative can express the requirement. If you read one page before any of the how-tos, make it the customization ladder — every page here assumes its logic.
The pages in this section
The section is ordered the way customizations are usually built: shape the data first, then the behavior around it, then the experience, then the automation on top.
| Page | What it covers |
|---|---|
| The data model | Entities, fields, picklists, relations and record types — the no-code data model everything else builds on |
| Create a custom entity | The end-to-end procedure: entity, fields, views, layout and app placement |
| Entity behavior | Views, validations, actions, field mappings, lookup filters and field dependencies — what each does and where it lives |
| Design a form layout | The visual layout designer: sections, widgets, per-record-type variants, mobile layouts and defaults |
| Business rules | Save-time automation: conditions and actions that default, require, block, lock and notify |
| Your first automation script | Server-side code in a sandbox — where scripts attach, what they can reach, and how to test them |
| Build a workflow | The visual workflow designer: entity-lifecycle triggers, multi-step orchestration and publishing |
| Approval processes | Sign-off chains: steps and approvers, submitting records, the approvals inbox, and how approval state gates documents |
| Expressions | The two expression surfaces — formulas and query filters — where each is used and how their syntax differs |
Where each change belongs
A few signal phrases route most requests. "This field must…" is data-model configuration. "When the record is saved…" is a business rule. "Someone must approve…" is an approval process. "Then wait, then notify, then later…" is a workflow. "Look across records or call another system…" is an automation script. "Show it differently…" is a layout or a custom component. When two tools both work, the lower rung wins — it stays visible in Setup, previewable, and editable by any administrator rather than only by whoever wrote the code.
Every customization here also runs inside a fixed save pipeline: defaults, then validation, then rules, then module logic, then workflows and scripts. When two customizations seem to fight, the pipeline order is almost always the explanation — see what runs when you save a record.
Common questions
Do I need a developer to customize xMatix?
Not for most of this section. The data model, entity behavior, layouts, business rules, workflows and approval processes are all configured in Setup — no code, previewable, and adjustable by any administrator with the right capabilities. Automation scripts are the exception: they are real server-side code and should be owned like code. The ladder exists precisely so that the coded rung is the last resort, not the first.
Do customizations survive product updates?
Yes — that is the point of building on the declarative surfaces. Custom entities, fields, rules, layouts and processes are tenant metadata, separate from the platform's own objects; platform updates ship new capability without rewriting your configuration. System-owned metadata is read-only in your tenant for the same reason: you extend it with custom fields and rules rather than editing it, so an update never has to merge with your changes.
Where do I try changes before users see them?
Most declarative tools carry their own safety mechanism — business rules are drafted inactive and verified in a test runner, workflows fire only when published, scripts fire only when bound — so the pattern on every page here is draft, verify, then activate. For larger changes, build in a sandbox tenant and promote when proven; see the administration guide for sandbox operations.