Security profiles and the grant matrix

A security profile is a named bundle of permissions that decides what a user may do in xMatix: which entities they can read and change, which fields, which actions they can run, which apps and pages appear in their navigation, which reports and dashboards they see, and which Setup areas they can administer. You build profiles under Setup → Access control → Profiles and assign them to users. A user can hold several profiles, and their rights are the union of what those profiles grant. Profiles are the first of two gates: which records a user reaches inside an entity they may use is decided afterwards by record-level security, and both gates must allow an operation for it to succeed.

Overview

Each profile has a header (Name, Label, Audience scope, Status) and eight tabs down the left side of its page:

When to use it

• Onboarding a new kind of user — create or clone a profile that matches the job, then assign it.
• Opening a module to a team — add the entity, app and action grants (and the product or feature entitlement) to the profile that team already holds.
• Delegating administration — give a profile the Setup capabilities for one area, for example security management, without making its holders full administrators.
• Protecting sensitive data — hide or lock individual fields such as salary or margin with field permissions.

Use record-level security instead when the question is which records someone sees, and restriction rules to narrow that further.

How xMatix handles it

For every request, xMatix collects the user's effective profiles: assignments that are Active, on profiles that are Active, whose Audience scope matches the user (Internal users take Internal or Both profiles; External users take External or Both profiles). Everything below is computed from those profiles only.

• Entities are a strict allowlist. An entity no effective profile grants is denied. The operations a user has on an entity are the union of the ticks on all their profiles' rows for it. There is no deny: one profile can't take away what another grants.
• The entity itself can rule an operation out. When an entity does not support an operation (for example, an entity that can't be created by hand), the operation is refused for everyone, whatever the profile grants, and its button is not offered.
• Unlicensed modules disappear. An entity or app that belongs to a product your organization has not enabled is hidden and refused for every user, whatever the profile grants. See Licensing.
• Fields are allowed unless a row says otherwise. A field with no field-permission row on any effective profile follows the entity grant. As soon as any effective profile has an explicit row for a field, only the explicit rows count: the user gets the union of those rows. A profile that merely inherits the field does not lift another profile's restriction.
• Buttons follow the grants. New, Edit and Delete appear only when the user has Create, Update or Delete on the entity (and the entity supports it). View and Attachments need Read. Submit for approval needs Update. Server actions, UI actions, previews and prints each need an explicit tick on the Actions tab.
• Navigation is its own allowlist. An app appears only when a profile grants View on it, and a page entry inside an app's menu appears only when a profile grants View on that page.
• Setup capabilities need their feature. A capability 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 your organization has that feature enabled.
• Changes reach signed-in users within about two minutes. Each user's resolved profiles, entitlements and capabilities are cached for up to 120 seconds.

Prerequisites

• The setup.security.manage capability. Without it the whole Access control area is hidden from Setup, and the profile screens refuse to load or save.
• For entitlement grants to take effect, the product or feature must be licensed and enabled for your organization (Setup → Feature Hub → Administration → Licenses).
• A decision about the job the profile serves. A profile per job (Sales Executive, Warehouse Operator) is easier to maintain than a profile per person.

Procedure

Step 1 — Open the profile list

Go to Setup → Access control → Profiles. The list shows Name, Label, Description, Audience scope, Active and Modified, with search, filters and refresh in the table header. Select a profile's name to open its page.

Step 2 — Create a profile, or clone one

To start from nothing, select New profile in the page header. In the New profile dialog enter a Label (required, up to 100 characters); Name fills in from the label. Add a Description, choose the Audience scope (Both, Internal or External; the default is Both) and leave Active on. Select Create. The profile starts with no grants at all.

It is usually quicker to clone a profile that is close to what you need. On the list, use Clone profile in the row's actions, or open the profile and select Clone in the page header. Enter a Label and Name, then under Clone related keep the grant sets you want: Entity Permissions, Field Permissions, App Permissions, App Page Permissions, Action Permissions, Mobile App Access, Product Entitlements, Feature Entitlements and Capabilities (need their feature entitlement). Unchecked sets are left out. Select Clone; the new profile opens. User assignments are never copied, so nobody holds the clone until you assign it. The built-in profiles can be cloned too.

Step 3 — Grant entity operations

On the Entity Permissions tab, find the entity with the search box and tick the operations the profile needs. All ticks or clears every operation for that row. Select All and Deselect All in the table header change every entity at once. Your changes are a draft until you select Save in the bar at the bottom; Cancel throws the draft away. A successful save shows "Entity permissions updated."

Always include Read with any write operation, and keep View All and Modify All for administrators and auditors — they bypass record-level security.

Step 4 — Restrict individual fields (optional)

On the Field Permissions tab, expand an entity to see its fields. Each field shows Inherited (no row: full access through the entity grant) or Custom (an explicit row), with Read, Create and Update columns and an All column.

• Clear Read to hide the field from forms, lists and data reads.
• Keep Read but clear Create and/or Update to make the field read-only when records are created or edited.
• Reset to inherited (on a field) or the reset button on an entity row removes the explicit rows again.
• Only overrides shows just the entities that have explicit rows. Deny all creates explicit deny rows for every field currently loaded; Reset all returns every field to inherited.

An entity row tagged No entity access means the profile has no Read on that entity, so its field settings have no effect until you grant Read on the Entity Permissions tab. Select Save to apply.

Step 5 — Allow actions

On the Actions tab, expand an entity and tick Allowed for each custom action the profile may run. Each action shows Active or Inactive, and Hidden when it is hidden from pages. Ticks here matter for server actions, UI actions, previews and prints. The standard New, Edit, Delete, View and Attachments buttons follow the entity operations instead, so ticking them here changes nothing. Select Save.

Step 6 — Make apps and pages visible

On the App Permissions tab, tick View for each app in the left panel. In the right panel, tick View for each app page (the list shows Page, Name, Type and the Apps it belongs to) that should appear in navigation. Select Save. Mobile app access is not on this tab: it is set per mobile app under Setup → Design Studio → Apps → Mobile apps, on the app's Profiles tab.

Step 7 — Grant products, features and capabilities

On the Entitlements tab, tick products, the features under them, and the capabilities under each feature. Use the search box to find a capability by name. Tags explain each node: Assigned, Tenant disabled (your organization has not enabled it, so the grant does nothing yet), Inactive and, on the SystemAdmin profile, Required. Unticking a product or feature also unticks what sits beneath it. If a capability is ticked without its feature, or a feature without its product, a dangling grant warning appears above the tree; fix it before you save. Select Save.

Step 8 — Choose visible reports and dashboards

On the Reports and Dashboards tabs, select Add, pick one or more items in the dialog and select Save. Use Remove on a row to take one away. These lists only add visibility; they don't remove what users already see through other routes (see Business rules).

Step 9 — Assign the profile to users

On the profile's Assignments tab select Add Assignment, or from the user's side open Setup → Access control → Users, open the user and use the Profile Assignments tab. In the New Profile Assignment dialog choose the User and the Profile, leave Active on and select Create. The profile list only offers profiles whose audience scope matches the user. If the user lacks seats the profile needs, the dialog lists the missing products and features and offers Assign missing seats. That allocates seats only on licenses your organization already holds and has enabled; licenses it does not have are listed separately, don't block the assignment and grant nothing until they are enabled. When seat enforcement is on, saving is blocked until the seats are in place.

Step 10 — Check the result

Ask the user to refresh after about two minutes, or open their Access Diagnostics tab on the user page to see which requirement, if any, is still unmet. Then change or remove grants the same way you added them. To take a profile out of use for everyone at once, open it, select Edit and switch Active off.

Fields

The assignment dialog has User, Profile and Active. Both lookups are locked once the assignment exists; to move a user to another profile, add a new assignment and delete or deactivate the old one.

Business rules

• Union, never deny. Entity operations, app and page visibility, action grants and capabilities add up across a user's effective profiles. Removing one profile only removes what no other profile still grants.
• Field rows are the exception. If any effective profile has an explicit row for a field, only explicit rows are combined. To let someone see a field another of their profiles hides, give the field an explicit Read row on a profile they hold, rather than leaving it inherited.
• Blocked field writes are refused by name. Saving a record that changes a field the user may not create or update fails with "The current user is not allowed to modify field(s): …".
• Built-in profiles. SystemAdmin and StandardUser can't be deleted or renamed ("The built-in security profile '…' cannot be deleted." / "… cannot be renamed."). Their label, description, audience scope and Active switch can still be edited from the profile page. StandardUser ships without grants; you configure it.
• SystemAdmin keeps its security capabilities. setup.security.manage, setup.security.users.manage, setup.security.audit.view and setup.security.users.loginAs, and the feature and product that host them, cannot be removed from SystemAdmin. Everything else on SystemAdmin can be revoked.
• Assignment rules never hand out administrator profiles. Rules under Security assignment refuse SystemAdmin and any profile holding a setup. capability; assign those by hand. See Resources.
• Reports. A user sees a report they created, a report shared with all users or with them, and a report made visible to a profile, role or team they belong to.
• No duplicates. A user can hold a profile once: "This user is already assigned to the selected security target."
• Delete is immediate. Delete in the list runs without a confirmation step. The built-ins show no Edit or Delete in the list.

Example

A distribution company wants store auditors who record shelf checks but cannot see prices.

1. The administrator opens Profiles, clones Standard User as Field auditor (Name FieldAuditor), keeping only Entity Permissions and App Permissions under Clone related.
2. On Entity Permissions they give the audit entity Read, Create and Update, and the Item entity Read only.
3. On Field Permissions they expand Item and clear Read on the price field — it now shows Custom.
4. On App Permissions they tick View on the auditing app and its pages, and clear the other apps.
5. On Assignments they add the three auditors. The dialog shows no missing seats.
6. Two minutes later an auditor opens an item: the price field is absent, and the list has no New button because Item only has Read.

Training

Practice exercise

In a sandbox, clone Standard User as Training read-only with only Entity Permissions copied. On its Entity Permissions tab, clear every operation except Read on one entity you know, such as Accounts, and save. Assign the profile to a test user who holds no other profile.

Expected result: after about two minutes the test user can open Accounts but sees no New, Edit or Delete button, and any other entity is refused. If the user sees nothing at all, check the App Permissions tab — the clone kept no app grants because you only copied Entity Permissions.

Quick reference

• Profiles live under Setup → Access control → Profiles; you need setup.security.manage.
• Rights are the union of all Active, audience-matching profiles. There is no deny.
• No row on Entity Permissions = no access to that entity.
• Every tab saves separately: select Save in the bar at the bottom.
• An app or page shows only with a View tick on App Permissions.
• Custom actions, previews and prints need a tick on the Actions tab; New/Edit/Delete follow the entity grant.
• Any explicit field row overrides "inherited" from the user's other profiles.
• Capabilities need their feature; licenses must be enabled for the organization.
• Clone copies grants, never users.
• Allow up to two minutes for changes to reach signed-in users.

Permissions

A user without setup.security.manage does not see the Access control area in Setup. The SystemAdmin profile always keeps it, so at least one administrator can always recover access — make sure at least one active user holds SystemAdmin.

Configuration

• Profile header — Edit on the profile page opens the label, description, audience scope and Active switch. Switching Active off removes the profile's grants from every holder.
• Grant tabs — Entity Permissions, Field Permissions, Actions, App Permissions and Entitlements, as described in the procedure. Each saves as one unit: if any part fails, nothing is saved and you see "Unable to save … permissions".
• Reports and dashboards — the Reports and Dashboards tabs; the same visibility can also be set from the report or dashboard side.
• Mobile app access — Setup → Design Studio → Apps → Mobile apps, the app's Profiles tab.
• Automatic assignment — Setup → Access control → Security assignment assigns non-administrator profiles from people's resource fields. See Resources.
• Licenses and seats — Setup → Feature Hub → Administration → Licenses, and the user's seat allocations. See Licensing.
• Record reach — sharing policies, rules and shares under Setup → Access control → Policies. See Record-level security.
• Starter profiles — besides SystemAdmin and StandardUser, new organizations ship with starter profiles such as Sales, Sales Executive, Sales Manager, Procurement, Service, Parts Manager, HR admin and Payroll admin. Treat them as starting points and review their tabs before you rely on them. See Role-based guides.

Common problems

A new user sees an empty workspace

The user has no effective profile: no assignment, an inactive assignment, an inactive profile, or a profile whose audience scope doesn't match the user. Any operation then fails with "The current user has no security profiles and is not allowed to perform '…' on entity '…'." Add an Active assignment to an Active profile with the right audience scope.

The profile has the right entity grants but the menu is empty

The profile grants no app. Tick View on the App Permissions tab for the app, and for each page that should appear in its menu.

"The current user is not allowed to perform 'Read' on entity '…'"

None of the user's effective profiles has the operation on that entity — often there is no row for the entity at all. Add the operation on Entity Permissions. If the message says "Access '…' is not enabled for entity '…'", the entity itself doesn't support that operation, and no profile can grant it.

"Entity '…' belongs to product '…', which is not enabled for this organization"

The entity's product is not licensed or enabled, or its license term has not started or has ended. Profile grants can't override this; see Licensing.

"The current user is not allowed to execute server action '…'"

The action needs a tick on the Actions tab of one of the user's profiles. The same applies when a custom button, preview or print is missing from a page.

A field is missing even though one of the user's profiles doesn't restrict it

Another of the user's profiles has an explicit row that hides the field, and explicit rows override inherited access. Give the field an explicit Read row on a profile the user holds, or remove the restricting row.

A Setup area stays hidden after granting the capability

Check that the user is entitled to the capability's feature (the tree shows a dangling grant warning when a capability's feature or a feature's product is unticked) and that the feature is not tagged Tenant disabled. Area gates also apply: the whole Access control area needs setup.security.manage, and Feature Hub needs setup.licensing.admin, even for users who hold a capability for a single screen inside them.

"Cannot remove '…' from the SystemAdmin profile"

You tried to remove one of SystemAdmin's protected security grants. They are required so that someone can always manage profiles, users and audit. Create a separate, smaller profile instead.

Common questions

Can one profile deny what another grants?

No. Entity operations, apps, pages, actions and capabilities only ever add up, so a user's rights are the union of their effective profiles. To narrow access, remove grants or move the user to a smaller profile. The one place where a profile can take something away is field permissions: an explicit field row on any profile overrides inherited access from the others. To narrow which records a user sees, rather than which operations, use record-level security and restriction rules.

Why does a new profile seem to do nothing?

Most often the profile has entity grants but no app, so navigation stays empty. Next come a capability whose feature the user isn't entitled to, a product your organization has not enabled, missing seats where seat enforcement is on, an assignment that is inactive, or an audience scope that doesn't match the user. The user's Access Diagnostics tab shows which layer is short. Remember that changes can take up to two minutes to reach a signed-in user.

Should I edit Standard User or create my own profile?

Create your own, usually by cloning. Standard User and SystemAdmin are built in and can't be renamed or deleted, and a change to any live profile reaches every holder within minutes. A clone lets you build and test the new set of grants on a single test user before you move people across.

What do Share and Assign do?

Both columns appear in the grant matrix, but xMatix does not check either one when a user works with records. Changing a record's owner is governed by Update, and per-record shares are created by administrators with setup.security.manage. View All and Modify All, by contrast, are powerful: they skip record-level security for reading, and for updating and deleting.

Related topics

• Record-level security and sharing
• Roles, teams and business units
• Restriction rules: scoping what users can see
• Worked security scenarios
• Troubleshooting: a user can't see something
• Licensing
• Resources
• Role-based guides