Start with Access Diagnostics
- 1
Access Diagnostics sits beside the tabs you fix things on: Role, Profile and Team Assignments and License Allocations.
- 2
Audience and External User decide which profiles can apply to this user — an external user never picks up an Internal-only profile.
- 3
Counts of effective profiles, roles, teams, business units, product licenses and capabilities; a zero in Profiles explains a blank workspace by itself.
- 4
Profiles and Roles resolved for the user — roles drive hierarchy and business-unit membership, profiles drive every grant.
- 5
Product Licenses: Allocated to user versus Required by profile — a name present below but missing above is a seat the user still needs.
- 6
Capabilities work the same way: what the profiles ask for versus what the user actually holds after licensing is applied.
The user's Access Diagnostics tab (Setup → Access Control → Users → open the user) is the fastest way to see the effective picture the server computes for that person: audience, active profiles, roles, teams, business units, and — for product licenses, feature licenses and capabilities — two lists side by side: Allocated to user and Required by profile. The screen does not flag the difference for you; read the two lists and look for a name that appears under Required but not under Allocated. That is a licensing gap (check 1). Empty Teams or Business Units cards are normal for many users and only matter when a share or rule depends on them (check 3).
When a user reports they can't see something — an app, a list, particular records, a field or a button — record the affected user, the app or entity, the operation and one specific missing record, then work through the checks below in order and stop at the first one that fails; that layer is the one to fix, and changes elsewhere won't help. Prefer additive fixes: grant the missing piece on the user's existing profile rather than handing out a broader admin profile.
Before you start
Rule out the cheap causes first. Is the account active? Has the user ever signed in — or did the invitation never land? Does the user hold at least one active security profile? Visibility in xMatix is allowlist-based, so a user with no profile sees no apps and no records, and the platform says so explicitly:
The current user has no security profiles and is not allowed to perform 'Read' on entity 'Order'.
That message style confirms which layer refused the request.
After any fix, re-open Access Diagnostics (the Generated timestamp confirms it recomputed) and have the user retry after a session refresh.
The checks, in order
Check 1 — Licensing
If the missing thing belongs to a licensed module or feature, check the commercial layer first: the tenant license (Setup → Feature Hub → Administration → Licenses) must be enabled, unexpired and within its seat ceiling, and the user's License Allocations tab must contain the required non-revoked seat when enforcement applies. Also inspect that module's own Feature Hub settings if it exposes an operational enable switch; there is no consolidated Module Settings item in navigation. Fix the first failing layer. Details in Licensing.
Check 2 — Profile grants
Profiles are the unit of app, entity, field and action access. An app appears only when an active profile grants view on it — no grant means hidden. An entity list needs Read in the union of grants across all the user's active profiles, and a field can be hidden or made read-only by a field-level permission even when the entity is readable. Also confirm the profile's audience matches the user (internal versus external). Inspect every active profile before declaring a grant missing, then fix by adding the specific grant. See Security profiles.
Check 3 — Record security
If the user can open the list but some records are missing, entity permission is fine — record security is filtering. On a private, user-owned entity, non-owned records are reachable only through an explicit path: a broader policy default, hierarchy roll-up to the user's role, a share to them or to their role, team or business unit (team shares also need the policy's team-access setting), an Access Grant rule, or the profile's View All override. A custom entity with no sharing policy at all behaves as private with every mechanism off — create its policy first. In multi-company tenants, company scoping also applies — the user sees only the companies they have access to. Record grants never widen entity access: without profile Read, no share helps. Pick the intended path and configure it; worked examples: Worked security scenarios and Record security.
Check 4 — Restriction rules
Even when the profile and record security both allow a record, an active restriction rule on the entity can scope it away from users the rule targets. Restriction rules only subtract — they never grant — so a rule is the likely culprit when everything in checks 1–3 looks correct. Review the entity's restriction rules for one that applies to this user and excludes the records, and fix by adjusting its criteria or audience. See Restriction rules.
Check 5 — View filters
Last, and surprisingly common: the view itself. Saved view filters, personal column filters, leftover search text and date-range scopes hide records with no security involved. Have the user switch to an unfiltered view, clear filters and search, and compare the record count. If the records appear, nothing was ever wrong with access — adjust the view instead; a shared view's default filters can surprise a whole team.
Common questions
The user can see the record but one field is missing or read-only — why?
That is field-level control, not record security. A field-level permission on one of the user's profiles can hide a field or make it read-only even though the entity itself is readable; with no field permission, the field follows the entity grant. Separately, the field may not be on the form layout in use. Check field permissions across all the user's active profiles first, then the layout.
How quickly do fixes take effect?
New requests re-evaluate promptly after you save a grant, seat or rule change, but an already-signed-in session can hold its previous picture until its token refreshes. Have the user refresh their session — or sign out and back in to force it — before you conclude the fix didn't work. Then re-open Access Diagnostics and compare the allocated and required lists again.
Two users hold the same profile but see different records — why?
Profiles equalize entity permissions only. Record visibility is computed per user from ownership, role hierarchy, team and business-unit shares, company scoping and restriction rules — all of which can differ between two people with the same profile. Compare the two users' roles, teams and company access on their Access Diagnostics tabs, then walk check 3 and check 4 for the records one of them is missing.