xMatix administration guide

This section is for the people who run xMatix for their organization: inviting users, deciding who may see and do what, keeping licenses and templates in order, moving data in and out, and testing changes in a sandbox before they reach production. Every page names the Setup screen it describes, lists the settings that matter, and states honestly what a control does — and does not — do.

Where administration lives in the product

All administrative work happens in Setup, reached from the app launcher. Its home page opens on a Browse tab (or directly on the section cards when your organization has no Setup Copilot license) that maps the same groups as the left sidebar:

123456 Expand

1. 1

   Browse shows the section cards; the Setup Copilot tab beside it appears only when your organization is licensed for it.

2. 2

   Access Control: Users, Business Units, Profiles, Roles, Teams and Policies — the identity and record-security screens.

3. 3

   Feature Hub: Administration holds Licenses and Org Settings; Platform holds Document Settings and Email Templates; module groups hold their own Settings.

4. 4

   Platform Operations: Sandboxes & DeltaPacks, Monitoring, Data Import and Data Export.

5. 5

   The sidebar carries the same groups; leaf screens such as Licenses or Jobs open from here.

6. 6

   Recently used entities give quick access to the metadata you edited last.

The other groups — Design Studio, Process Studio, Data Studio and Sense AI Studio — are where the model, automation, analytics and AI agents are built; they are covered in Customizing xMatix, Data Studio and Sense AI. The cards for Access Control, Feature Hub and Platform Operations list their sub-groups as text; open the actual screens from the left sidebar. Below the cards, the home page keeps shortcuts to the entities you worked on most recently.

The access model in one paragraph

Every action a user attempts passes two independent gates. A security profile must grant the operation — the app, the entity, the field, the action or the setup capability — and record security (the entity's policy, ownership, the role hierarchy, shares and rules) must expose the specific record. Roles, teams and business units never grant operations; licenses and seats are a third, commercial layer that must also be satisfied for licensed products and features. When a user "can't see something", work through the layers in order rather than widening one profile: Troubleshooting: a user can't see something is the ordered checklist, and Worked security scenarios shows the building blocks combined into configurations you can copy.

Capabilities you will need

Setup screens are gated by capabilities on your security profiles. The built-in SystemAdmin profile holds all of them; a delegated administrator needs only the relevant ones:

A screen you cannot see in the sidebar is almost always a missing capability, not a missing feature; some groups are additionally hidden when the feature is not enabled for your organization (sandboxes) or when the current environment is itself a sandbox.

Reading order

1. Invite a user — the account, provisioning and the first profile.
2. Security profiles and the grant matrix — the operation gate.
3. Roles, teams and business units, Record-level security and sharing and Restriction rules — the record gate.
4. Licensing — the commercial layer and per-user seats.
5. Email templates and document numbering — outbound messages and generated document numbers.
6. Import data and Export data — bulk data in and out.
7. Sandboxes and promoting changes — test in isolation, promote with DeltaPacks.

Related topics

• Security model concepts
• Tenants and companies
• Data lifecycle concepts
• Getting started with xMatix — the user-facing orientation.
• Platform security & governance