Every access decision in xMatix passes two gates: a security profile must permit the operation on the entity, and record security must expose the specific record. Neither gate alone is enough. The scenarios below show how the common building blocks — ownership, the role hierarchy, teams, business units, policy rules and the view-all override — combine into configurations you can copy. Each names the exact screens and fields involved; the mechanics are explained in Security profiles, Roles, teams and business units, Record security and Restriction rules.
Before you start, know the baseline. First-party entities ship with a policy (DefaultSharing<Entity> under Setup → Access Control → Policies) whose defaults are User Owned, Read Only for internal and external users, and Grant Access Using Hierarchy, Allow Manual Share and Allow Team Access all on — everyone with profile Read sees every record; writing needs ownership, hierarchy or Modify All. Every scenario below that wants records hidden starts by setting Internal Default Access to Private on that policy. An entity you created has no policy and already behaves as Private with the three switches off.
Scenario 1 — Representatives own their records; managers see the team's
Goal. Each sales representative works only their own opportunities, while their manager can read everything the team owns.
Configuration. The representatives' profile grants Read and Update on the entity. The entity's policy is User Owned with Internal Default Access set to Private, so a record is visible only to its owner unless something else grants access. The representatives' roles sit below the manager's role in the hierarchy (Roles → each rep role's Parent Role is the manager's role), and the policy has Grant Access Using Hierarchy on. The manager's profile also grants Read on the entity.
Result. A representative sees and edits their own records; a colleague with the same profile cannot open them. The manager reads every record owned by users in descendant roles — but only because the manager's own profile grants Read. Hierarchy expands record visibility; it never adds entity permissions, and it never lets a representative see upward or sideways.
Scenario 2 — Regional teams see only their region
Goal. Users in each region work with their region's records and nothing else.
Configuration. Keep the entity Private by default, as above. Create one business unit per region (Business Units) and set each region's roles' Business Unit to it. Give users a regional role plus a profile granting Read on the entity. Then open the records to the unit either by sharing records to the business unit, or — the maintainable way — with one policy rule per region: New Rule with Rule Type Access Grant, Effect Grant Read, an expression such as Region == "West", and a target of type Business Unit pointing at the West unit (restriction rules).
Result. Users whose roles resolve to a business unit can open the records shared or granted to it; users in other regions cannot. Two caveats: business-unit membership reaches a user only through their active roles — there is no direct user-to-unit assignment. And belonging to a unit grants nothing by itself: it is the share or rule targeting that unit that opens the records.
Scenario 3 — A support team collaborates on shared cases
Goal. Everyone on a support team can work the cases escalated to the team, regardless of who owns each case.
Configuration. Create the team (Teams) and add its members on the Assignments tab. On the case entity's policy, keep Allow Team Access on. Share the relevant case records to the team — manually from the record, or through a policy rule whose target type is Team. Members' profiles grant Read — and Update where they should edit — on the case entity.
Result. Any member can open the shared cases without owning them. A member whose profile lacks the entity grant still cannot: record access alone never completes an operation — the two gates cut both ways. Note that a rule target grants read only; editing shared cases relies on the Update profile grant plus a Read Write default, ownership, hierarchy, Modify All or a manual share.
Scenario 4 — Everyone may read reference data, nothing else changes
Goal. Accounts of type Reference are visible to all internal users, while every other account stays Private to its owner and management chain.
Configuration. Policy Private, hierarchy on, as in Scenario 1. Add one rule: Rule Type Access Grant, Effect Grant Read, Applies To Audience Internal, expression AccountType == "Reference", target type All Internal. Create the rule disabled, confirm the expression shows Valid, test, then enable it.
Result. Internal users see their own accounts plus every Reference account; portal (external) users are unaffected because the rule's audience excludes them. This is the general pattern for an exception to a Private baseline: one rule, one condition, one audience or group.
Scenario 5 — An operations role that sees everything
Goal. An operations or audit role can read every record of an entity, regardless of ownership and shares.
Configuration. Grant the profile Read plus View All on the entity. Add Modify All only if the role must also update or delete anything it can see.
Result. Record-level filtering is skipped entirely for that entity: the user reads all records even though the entity is User Owned and Private for everyone else. Because these overrides bypass every record-level control — ownership, hierarchy, shares, rules and defaults alike — reserve them for genuinely tenant-wide roles and keep the profiles that carry them narrowly assigned.
Quick interpretation rules
When a configuration does not behave as expected, these shortcuts point at the right layer.
| Symptom | Where to look first |
|---|---|
| The user cannot do the operation on any record (an explicit "not allowed" error) | Profile grants on the entity |
| Some records are visible, others are not | The entity policy and the record-access path (owner, hierarchy, shares, rules) |
| A manager cannot see subordinate data | Role assignments, the Parent Role chain, and Grant Access Using Hierarchy on the policy |
| Business-unit sharing is not working | Whether the user's active roles actually carry the expected Business Unit |
| Team sharing is not working | Team membership and the policy's Allow Team Access switch |
| A rule grants nothing | Rule Enabled, expression Validation = Valid, audience, target, and profile Read |
| Everyone can see everything | A Read Only default that was never set to Private, or View All on a widely assigned profile |
Common questions
Do permissions from multiple profiles conflict?
No. A user's effective permissions are the union of everything their active profiles grant, and there is no explicit deny that overrides a grant. A user with one profile granting Read and another granting Update effectively has both. The practical consequence for troubleshooting: before you conclude a grant is missing, inspect every active profile the user holds — and remember that removing one profile only removes what no other profile still grants.
Can a share grant more than the profile allows?
No. Shares, hierarchy roll-up, rules and policy defaults only decide which records are reachable; the operation itself must still be permitted by a profile grant on the entity. A record shared to a user who has no Read grant stays unreadable, and a readable record is not editable without an Update grant. When you want someone to act on shared records, check both gates deliberately.
What does a Private default actually mean?
With Internal Default Access Private on a User Owned entity, a record is visible only to its owner plus whatever explicit paths you configure: hierarchy roll-up to managers, shares to teams or business units, enabled policy rules, or a profile's View All override. Internal and external users have separate defaults on the same policy — for example Read Only for employees while portal users stay Private — so check both settings when internal and external audiences behave differently.
Should I use shares or rules for group access?
Manual shares are per record and suit exceptions — one escalated case, one strategic account. Rules are per condition and suit standing arrangements — a region's records, a record type, a status. Rules stay visible and reviewable on the policy detail page and can be disabled in one place; shares accumulate on records and are harder to audit. Both require the policy's corresponding switch (Allow Manual Share, Allow Team Access) or rule to be active.