Read the platform model map
- 1
Design Studio defines entities, apps, packages and shared picklists.
- 2
Process Studio defines automation and behavior over the model.
- 3
Data Studio governs data movement and analytical structures.
- 4
Sense AI Studio and Access Control govern intelligence and authorization.
- 5
The Entities registry demonstrates how a concept becomes shared runtime metadata.
Setup makes the platform's mental model visible. Design Studio defines entities, apps, packages and global picklists; Process Studio defines behavior over those records; Data Studio governs movement and analytical shapes; Sense AI Studio configures intelligence; Access Control governs people and permissions; and Platform Operations covers the tenant's operating controls. The selected Entities page demonstrates how a concept becomes concrete metadata that every runtime surface consumes.
Use this map to decide where a question belongs before changing configuration. A missing field begins in Design Studio, an unexpected save action in Process Studio, a visibility issue in Access Control, and an AI behavior question in Sense AI Studio. 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.
The concepts section explains the mental models behind xMatix — the small set of ideas that every screen, module and setup option is built on. Each page answers one question in plain language: how your organization's private space is structured, how work is organized into apps and records, who can see and do what, which customization tool fits which job, what runs when a record is saved, what happens to deleted data, how the mobile app works without a network, and how the Sense AI assistant is kept inside the same rules as everything else. None of these pages is a how-to; they are the background that makes the how-tos make sense.
What this section covers
The pages build on one another, so reading them in order works well the first time through:
- Tenants and companies — how your organization's private tenant relates to the companies, branches and business units you run inside it.
- Apps, entities and records — the data model: entities describe the shape of your data, records hold it, and apps group it into workspaces.
- Security model — the layers that decide what a user may do and which records they may reach: profiles, capabilities, licensing and record-level security.
- Customization ladder — which tool to reach for when you change how xMatix behaves, from plain configuration up to custom code, and why the lowest rung that works is the right choice.
- Execution order — what runs, and in what sequence, when a record is saved: defaults, validation, business rules, module logic, workflows, approvals and scripts.
- Data lifecycle — what delete really does: the recycle bin, restore, retention windows and archiving.
- Offline mobile — how the mobile app keeps your data on the device, queues edits made offline, and syncs them when connectivity returns.
- Sense AI governance — how the AI assistant is scoped to each user's permissions, what it is allowed to write, and how administrators control its availability.
Who these pages are for
Administrators get the most from this section: almost every configuration decision — a new field, a security profile, a business rule, an approval process — sits on top of one of these models, and choices are easier to make when you know what the platform is doing underneath. The first two pages and the offline mobile page are also written for everyday users who want to understand why the product is shaped the way it is. Implementation partners and reviewers evaluating xMatix will find the section useful as a compact description of the platform's architecture in user-facing terms.
How concepts relate to the rest of the documentation
The getting started guide teaches the screens: signing in, navigating apps, lists and records. The administration guide holds the procedures: the exact clicks to create a security profile or share a record. This section holds the reasoning that connects them. When a procedure tells you what to do, the matching concept page tells you why it works and what else it affects — so a good pattern is to skim the concept page once, then work from the procedures day to day and come back here when something behaves in a way you did not expect.