How the xMatix security model works

xMatix decides what a user can do with layered checks, and each layer answers a different question. Licensing answers what exists for this organization and this user at all. Security profiles answer what operations the user may perform on each entity, field, app and action. Capabilities answer which Setup areas the user may administer. Record-level security answers which specific records the user may reach. Company scoping, where it is switched on, answers which companies' records the user may see and post into. An operation succeeds only when every layer that applies agrees. Grants add up and there is no deny, so to restrict something you narrow a grant rather than add a block.

123456 Expand

1. 1

   Access Diagnostics is read-only evidence; the tabs to its left — Role, Profile and Team Assignments, License Allocations — are where each layer is changed.

2. 2

   Audience (Internal or External) is the first gate: a profile whose audience scope does not match the user is ignored entirely.

3. 3

   Profiles answer what the user may do — entity and field permissions, app and action grants, capabilities and license entitlements are all carried here.

4. 4

   Roles grant no permissions; the role places the user in the hierarchy so records owned by people below roll up to them.

5. 5

   Teams and Business Units are additional record-access paths, only for entities whose policy allows team access and sharing; none assigned is a normal state.

6. 6

   Product Licenses and Capabilities are what licensing makes available: a capability counts only when a profile grants it and the user holds the feature license it belongs to.

Overview

The layers are set up in different places and checked in a fixed order:

The one screen that shows these layers together for one person is the user's Access Diagnostics tab (Setup → Access control → Users, open the user). It lists the user's audience, their resolved profiles, roles, teams and business units, and, for product licenses, feature licenses and capabilities, what is allocated to the user beside what their profiles require. It is calculated live when you open it, so it reflects changes immediately, even before they reach the user's own session. When someone asks "why can't I see this?", start there. Troubleshooting: a user can't see something walks the checks in order.

When to use it

Read this page when you:

• design the access set-up for a new organization or a new team;
• need to explain to a colleague why two users with "the same access" see different things;
• are about to grant a broad right such as View All or a Setup capability and want to know exactly what it opens;
• are training administrators who will look after security day to day.

Permission and access are two different questions

Most confusion about security disappears once you separate two decisions. Permission means a user is authorized to perform an operation in principle: "may update orders", "may read the credit-limit field". Security profiles decide permission. Access means the user may operate on one specific record: "may see this opportunity, because they own it or it was shared with them". Record-level security decides access.

Both must be true. A user with update permission on an entity still cannot edit a record they have no access to, and a user who can see a record cannot edit it without update permission. "I can see it but can't change it" points at permission. "I have the permission but can't find the record" points at access.

How xMatix handles it

Licensing: what exists at all

Licensing sits above the other layers. Products (Sales, Service, Finance, Sense AI and so on) and the features inside them are licensed to the organization, with optional seat counts and a start and expiry date. A license outside its term counts as disabled. A user's products are the ones that their profiles require and that the organization has enabled and, where seats apply, that the user holds a seat on.

• Seats. Unless your platform operator has turned seat enforcement on, a user with no product seats at all is treated as seated on every enabled product their profiles require. Their first seat narrows them to the products they are seated on, so seat a user on everything they need in one sitting. Features are counted the same way, separately.
• Free features are granted automatically to every user whose profiles hold the parent product. They need no license row and no seat.
• Nothing overrides licensing. No profile can grant what the organization has not enabled. A screen that belongs to an unlicensed product tells the user the product isn't licensed for the organization.

See licensing for the Licenses screen, seat enforcement and product dependencies.

Security profiles: what a user may do

A security profile is a reusable, named bundle of grants with an Audience Scope (Internal, External or Both) and an Active switch. A user can hold several profiles. A profile counts for a user only when the assignment is active, the profile is active, and its audience scope matches the user's audience. A profile scoped Internal is ignored for a portal (external) user. The bundle has these parts:

• Entity permissions. Per entity, any combination of Read, Create, Update, Delete, Share and Assign, plus the elevated View All and Modify All. Entities are a strict allow-list: an entity no effective profile grants is denied, and it disappears from the user's menus, lists and lookups. A link to one of its records shows a not-found page.
• Field permissions. Per field, whether it may be read, set on create, or changed on update. A field with no explicit row on any of the user's profiles follows the entity grant.
• App and app page permissions. Which apps and custom pages appear in the launcher and navigation.
• Action permissions. Server actions, UI actions, previews and prints each need an explicit tick on the profile's Actions tab. New, Edit and Delete follow the Create, Update and Delete permissions, View and Attachments follow Read, and Submit for approval follows Update.
• Entitlements. The products and features the profile requires, and the Setup capabilities it grants (next section).
• Reports and dashboards. Shared analytics are made visible to profiles, roles, teams or everyone.

The user's effective permissions are the union of their effective profiles, with one exception: field permissions. As soon as any of the user's profiles has an explicit row for a field, only the explicit rows count, and a profile that merely inherits the field does not lift another profile's restriction. The step-by-step guide is in security profiles.

Capabilities: rights over Setup areas

Data permissions do not cover everything an administrator does, such as managing users, editing the data model, tuning Sense AI or running imports. These are governed by capability keys of the form setup.<area>.<action>, for example setup.security.manage, setup.metadata.model.manage or setup.diagnostics.jobs.view. Each Setup screen is gated by one key, and keys are granted on a profile's Entitlements tab.

• A capability needs its feature. It counts only when the user is entitled to the feature it belongs to (through a feature grant or a product grant that carries the feature) and the organization has that feature enabled.
• Some areas have a gate of their own. The whole Access control area is hidden unless the user holds setup.security.manage, and the whole Feature Hub area is hidden unless they hold setup.licensing.admin, even if they hold a capability for one screen inside it. When you delegate one screen in those areas, grant the area capability too.
• Capabilities and data permissions are independent. Granting someone a Setup right never widens their data access, and the reverse is also true.
• SystemAdmin keeps four capabilities. setup.security.manage, setup.security.users.manage, setup.security.audit.view and setup.security.users.loginAs cannot be removed from the built-in SystemAdmin profile, so the organization can never lock itself out of security administration.

Record-level security: which records a user reaches

For each entity, a security policy decides how record access is worked out. A policy has an Ownership model, a default access level for internal users and one for external users (Private, Read Only or Read Write), and three switches: Grant Access Using Hierarchy, Allow Manual Share and Allow Team Access.

Not every entity ships with a policy, and shipped policies differ by entity. For example, accounts and contacts are Read Only by default, opportunities are Private, and orders are Organization Owned. An entity with no policy, or with an inactive policy, is treated as User Owned and Private with all three switches off, and any rules for it are ignored. Check the policy before you rely on hierarchy, sharing or team access for an entity.

For each request, the server works out the records a user reaches in this order:

1. No signed-in user, no access. A request with no user identity is refused.
2. View All and Modify All skip record security. If one of the user's profiles grants View All on the entity, a pure read sees every record, and access filter rules do not apply. Modify All does the same for updates and deletes. Neither covers the other's operations.
3. Organization Owned or default access opens every record. If the entity is Organization Owned, or the policy's default access for the user's audience covers the operation (Read Only covers reads, Read Write covers reads, updates and deletes), every record starts out reachable. A policy set to Team Owned is treated as User Owned.
4. Otherwise, the user reaches records through access paths:
   • records they own;
   • records owned by users in roles beneath theirs, when Grant Access Using Hierarchy is on (an inactive role cuts off everything beneath it);
   • records shared with them, with one of their roles, with their business unit, or with all internal or all external users, when Allow Manual Share is on. A share counts only for the operations its access level covers;
   • records shared with a team they belong to, when both Allow Manual Share and Allow Team Access are on.
5. Access grant rules widen the set. An enabled rule of type access grant adds the records that match its expression, for the users its targets cover. Grant rules only matter where step 3 has not already opened every record.
6. Access filter rules narrow the set. An enabled access filter rule keeps only the records that match its expression. Filters apply after everything above, including to Organization Owned and Read Only entities. Only View All and Modify All in step 2 skip them.

A rule applies only to the operations it is set up for, and only to the users its targets cover. Its expressions are combined with AND, and only expressions marked valid are used. A grant with no included target applies to nobody, and a filter with no included target applies to everyone. An Except target removes the users it matches. The how-to for policies and shares is record-level security, and scoping with rules is in restriction rules.

Roles, teams and business units

Roles form the reporting hierarchy that record visibility rolls up through: a manager's role lets them reach records owned by users in roles beneath it, on entities whose policy has hierarchy access on. Roles grant no permissions of their own. Teams are working groups a record can be shared with. Business units group roles, and a user belongs to the business units of the roles they hold. A share or rule aimed at a business unit covers only that unit, not the units beneath it. Roles, teams and profiles are assigned per user on the user's Role Assignments, Team Assignments and Profile Assignments tabs (Setup → Access control → Users). See roles, teams and business units.

Company scoping: a separate boundary inside the organization

Organizations that trade through several companies can restrict users to particular companies. This layer is separate from record-level security and works on records that carry a company.

• The switch. Restrict users to their own companies on the General tab of Org settings turns it on for the organization. It can't be on while We run multiple companies is off. Company restriction also has to be enabled for the platform by your platform operator. Until it is, the setting is saved but users are not restricted.
• Per-user access. On the Company access tab, pick a user and add the companies (optionally a single branch) they may use. Each row has an Access kind: Transact (see + post) or View (see only). One Transact row can be marked Use as the user's default company, which prefills the company on new records the user owns.
• Bypass. The Access all companies switch on the same tab lifts the restriction for one user. The built-in SystemAdmin profile also carries the all-companies bypass, so every SystemAdmin user sees all companies.
• What a restricted user sees. Records of companies the user has no access to are left out of lists, lookups and reports. Saving a record for a company the user can only view, or cannot see, is refused with "You do not have permission to transact on the selected company." Records with no company, such as shared master data, are never blocked.

Tenants and companies explains how companies, branches and the organization relate.

Example

A distribution business sets up access for its field sales team.

1. Licensing. The organization has Sales enabled. The administrator seats a new sales representative on Sales in one sitting, on the user's License Allocations tab.
2. Profile. The representative gets a "Sales Representative" profile, scoped Internal, that grants Read, Create and Update on Account, Contact and Opportunity, and no Delete. The profile also hides the Margin field on opportunities with an explicit field row.
3. Role. The representative's role, Sales Representative, sits beneath Area Sales Manager, which their manager holds.
4. Policy. The Opportunity policy is User Owned and Private with hierarchy, manual share and team access on.

The result: the representative sees only the opportunities they own, plus any shared with them. The manager sees their own and the representative's, because hierarchy access is on, but can edit the representative's opportunities only if the manager's own profile grants Update on Opportunity. Accounts are Read Only by default, so the representative can open every account, but can edit only the accounts they own or that are shared with them for writing. If the administrator later adds an access filter rule on Account that keeps only accounts in the representative's territory, their account list narrows, while a finance user whose profile has View All on Account still sees every account.

Training

Practice exercise

In a sandbox, with two test users (A, a manager, and B, reporting to A):

1. Give both users a profile with Read and Update on Opportunity, and put B's role beneath A's role.
2. Open Setup → Access control → Policies and confirm the Opportunity policy is Private with Grant Access Using Hierarchy on.
3. Sign in as B and create an opportunity. Sign in as A and find it.
4. Switch Grant Access Using Hierarchy off, wait two minutes, and look again as A.

Expected result: in step 3, A sees B's opportunity through the hierarchy. In step 4, it disappears from A's list, while B still sees it. Open A's Access Diagnostics tab and confirm that nothing in A's profiles changed: only the access path did. Switch the setting back on when you finish.

Quick reference

• Permission (profiles) says what kind of thing; access (policies) says which record. Both must allow it.
• Grants add up across profiles, except explicit field rows. There is no deny.
• A profile counts only when it is active, its assignment is active, and its audience scope matches the user.
• A capability needs its feature. The Access control and Feature Hub areas also need their own area capability.
• No policy means Private with every switch off.
• View All skips record security for reads, filters included. Modify All does the same for updates and deletes.
• Access filter rules narrow even Organization Owned and Read Only entities.
• Roles grant no permissions; they only roll record visibility up the hierarchy.
• Company scoping is separate, and needs the Org settings switch plus per-user Company access rows.
• Changes reach signed-in users within about two minutes. Access Diagnostics shows the new state at once.

Permissions

Changing security is itself gated by capabilities:

A user without these capabilities does not see the matching Setup areas.

Configuration

Changes to profiles, roles, teams, licenses and capabilities reach signed-in users when their cached access refreshes, within about two minutes. Policy and rule changes take a similar time, and company access changes up to about 90 seconds.

Common questions

A user has the right profile but cannot see a record — why?

The profile granted permission; what is missing is access. Check the entity's policy first, and remember that an entity with no policy is Private with every switch off. On a Private entity the user needs a path to the record: ownership, a role above the owner (with hierarchy on), a share to them, their role, their business unit or their team (with sharing and, for teams, team access on), or a grant rule that targets them. Then check for an access filter rule that removes the record, and, if company scoping is on, whether the user has access to the record's company.

Do roles grant permissions?

No, and the separation is deliberate. Roles define whose records roll up to whom; profiles define what may be done. A manager who can see a subordinate's opportunity still needs Update on Opportunity from a profile before editing it.

Can I deny a specific user something their profile grants?

Not with a deny entry: the model has none, and grants add up. To restrict, narrow what is granted. Split a broad profile into narrower ones and assign the narrower set, add an explicit field row rather than masking the field in a layout, tighten the entity's policy so fewer access paths apply, or add an access filter rule that targets the users concerned. Because everything is additive, any access a user has can be traced back to a specific grant.

Why does a portal (external) user see nothing even with a profile?

Usually one of two things. The profile's audience scope is Internal, so it is ignored for an external user: external users need a profile scoped External or Both. Or the entity policy's external default access is Private and no share or rule reaches the portal user's records. External access is decided by the external default and rules, separately from the internal one. See portal security.

How quickly does a security change take effect?

Each user's resolved profiles, roles, teams, licenses and capabilities are cached for up to 120 seconds, and policies and rules for a similar time, so a change usually reaches a signed-in user within about two minutes. Company access is cached for up to about 90 seconds. Access Diagnostics is calculated live, so it shows the new state straight away. If the user still sees the old behaviour there, wait out the two minutes before investigating further.

Does View All also let a user edit everything?

No. View All covers reads only. A user with View All but no Modify All can open every record of the entity, but can update or delete only the records their normal access paths reach, and only if their profile grants Update or Delete. Modify All is the matching right for updates and deletes.

Related topics

• Managing security profiles
• Record-level security
• Restriction rules
• Roles, teams and business units
• Security scenarios
• Licensing
• Troubleshooting: a user can't see something
• Portal security
• Tenants and companies
• Platform security and governance