Worked security scenarios

This page is a set of worked security configurations you can copy: each scenario states a goal, the exact settings that achieve it, and what users then see. Use it after you know the building blocks — security profiles, roles, teams and business units, record security and restriction rules — and before you change a live policy.

Overview

Every access decision in xMatix passes two gates:

1. The profile gate. One of the user's active profiles must grant the operation (Read, Create, Update, Delete) on the entity. Without it the user is refused on every record.
2. The record gate. Record security must reach the specific record — through the entity's sharing policy (ownership model and default access), ownership, the role hierarchy, a share, or a matching Access Grant rule — and every Access Filter rule that applies must keep it.

Neither gate alone is enough, and neither widens the other: a rule or share never lets a user use an entity their profiles do not grant, and a profile grant never exposes records the record gate hides. The only exceptions are View All (skips the record gate for reading) and Modify All (skips it for updating and deleting).

When to use it

• You are setting up security for a new organization or a new module and want a proven pattern.
• You are asked for a specific outcome ("reps see only their own", "each region sees its region") and need the settings that deliver it.
• A configuration behaves unexpectedly and you want to compare it with a known-good one — see Quick interpretation rules.

How xMatix handles it

Know the baseline before you start

Not every entity ships with a sharing policy. Open Setup → Access Control → Policies and look for the entity's row:

• No row, or the policy's Active switch is off — the entity behaves as User Owned and Private for both audiences, with hierarchy, manual sharing and team access all off, and any rules are ignored. Only owners and View All holders read its records. Every entity you create starts like this.
• A shipped policy — usually named DefaultSharing<Entity>. Many are User Owned with Read Only for both audiences and all three switches on (accounts and contacts, for example): everyone with profile Read sees every record, and writing needs ownership, the hierarchy or Modify All. Others are stricter: opportunities, leads, cases and activities are Private for staff, and leads and cases also have Allow manual share and Allow team access off.
• A policy you create with New policy — starts User Owned, Private for both audiences, with all three switches and Active on.

Read the exact values in your organization before you copy a scenario. They can have been changed.

What each building block can and cannot do

Policy, rule and profile changes reach signed-in users within about two minutes.

Prerequisites

• The setup.security.manage capability, which opens the Access control area of Setup.
• The roles, teams and business units each scenario names, with people assigned (roles, teams and business units).
• A test user for each audience you are scoping, holding only the profiles that audience gets. Your own administrator account probably has View All, so it cannot show you what scoped users see.
• A written note of the current policy values, so you can roll back.

Procedure

Use these steps to apply any of the scenarios below.

Step 1 — Check the profile gate

Open Setup → Access Control → Profiles, open each profile the affected users hold, and confirm the entity grants they need (Read, plus Update, Create or Delete where they should change data). Confirm that View All and Modify All are only on profiles meant to bypass record security.

Step 2 — Check or create the policy

Open Setup → Access Control → Policies and open the entity's policy, or create one with New policy if there is none. Compare Ownership, Internal Access, External Access, Hierarchy Access, Manual Share and Team Access with the scenario, and change them with Edit Policy.

Step 3 — Add the scenario's rules, disabled

Select New Rule, set the fields the scenario lists and untick Enabled. Open the rule, add the condition on Expressions (Add Expression) and confirm the Validation column shows Valid, then add the people on Targets (Add Target). The full dialog guide is in Restriction rules.

Step 4 — Test, enable, test again

Sign in as a test user and check one record that should be visible, one that should not, and one save. Enable the rule with Edit Rule → Enabled, wait two minutes and repeat the checks — including with a user the scenario should not affect.

Scenario 1 — Representatives own their records; managers see the team's

Goal. Each sales representative works only their own opportunities, while their manager can see and correct everything the team owns.

Configuration.

• Profile: the representatives' and the manager's profiles grant Read and Update on the entity (plus Create for the representatives).
• Policy: User Owned, Internal default access = Private, Grant access using hierarchy on. The shipped opportunity policy already looks like this; for an entity whose default is Read Only, change it to Private.
• Roles: each representative's role has the manager's role as its Parent Role (Setup → Access Control → Roles), and each person holds an active assignment to their role.

Result. A representative sees and edits their own records; a colleague with the same profile cannot open them. The manager reads and edits every record owned by users in roles below theirs, at any depth. Hierarchy never reaches upward or sideways, and it never adds entity permissions: a manager whose profile grants only Read sees the team's records but cannot save changes.

Scenario 2 — Each region sees only its region

Goal. Users in each region work with their region's records and nothing else.

Configuration.

• Policy: Internal default access = Private.
• Business units: one unit per region under Setup → Access Control → Business units. Set each regional role's Business unit to its region. A user belongs to a unit only through the active roles they hold; there is no unit field on the user.
• One rule per region: Access Grant, Grant Read, Applies To Audience = Internal, an expression that picks the region's records (for example Region == "West", using your entity's own field), and an Applies to target of Business Unit = the region's unit.
• If the region should also edit those records, add a second rule per region with Grant Write and Update (4), the same expression and target.

Result. Users whose roles sit in the West unit read every West record, whoever owns it, plus their own records. Users in other units do not. A target on a parent unit does not cover roles filed under its child units — target each unit that should be covered. A rule formula cannot say "the reader's own unit", which is why this is one rule per region.

Variation without a region field. If records carry no region but are owned by the region's people, use the owner instead: Owner.InRoleAndSubordinates("<regional head role name>") selects records owned by anyone in that role or below it.

Scenario 3 — A support team works escalated cases it does not own

Goal. Every member of an escalation team can open and update escalated cases, regardless of who owns each case.

Configuration.

• Profile: members' profiles grant Read and Update on cases.
• Team: create the team under Setup → Access Control → Teams and add each member on its Assignments tab.
• Two rules on the case policy, both with Applies To Audience = Internal, the expression Escalated == true, and an Applies to target of Team = the escalation team: one Access Grant / Grant Read rule, and one Access Grant / Grant Write rule with Update (4).

Result. Members see and update every escalated case; when a case is no longer escalated it drops out of their reach unless something else gives it to them. This works on the shipped case policy even though it has Allow manual share and Allow team access off: that switch governs team shares, and rule targets naming a team always count. Without the Grant Read rule, members could not see the cases they are allowed to edit, because the case default is Private. Members cannot delete, because there is no Delete rule.

Scenario 4 — Everyone reads accounts; only owners, managers and the back office edit

Goal. All staff can look up any account, but only the owner, the owner's managers and a back-office data team can change one.

Configuration.

• Policy: the shipped account policy already gives Internal default access = Read Only with Grant access using hierarchy on. Leave it.
• Profile: staff profiles grant Read and Update on accounts.
• One rule: Access Grant, Grant Write, Update (4), Applies To Audience = Internal, an expression that picks the accounts the group looks after (for example Status == "Approved"), and an Applies to target of Role (or Team) = the back-office group.

Result. Everyone reads every account. Owners and their managers can save changes through ownership and the hierarchy; the back-office group can save changes to every account the rule matches. Other staff open accounts read-only: their Update grant needs a record path, and the Read Only default does not give one. A Grant Read rule here would change nothing, because the default already lets everyone read. Grant Write rules still widen editing on a Read Only entity. If the back office should also delete, add a second rule with Delete (8), or give them Modify All if they need every account without conditions.

Scenario 5 — Field staff see only what is assigned to them

Goal. Field representatives see only records assigned to their own resource (or to the people below them), while office staff with no resource keep seeing everything.

Configuration.

• Policy: whatever default suits the office (often Read Only).
• One rule: Access Filter, Filter Visible Records, operation Read (1), Applies To Audience = Internal, an expression such as !User.HasResource || (ResourceId != null && User.ResourceIds.Contains(ResourceId.Value)) using the entity's own resource field, and no target (a filter with no target applies to everyone in its audience).
• Optional: an Except target of Role = the head-office role, so that role is never filtered.

Result. A representative linked to a resource sees only records assigned to their resource or to the resources of users below them in the role tree. Users with no linked resource are not filtered, thanks to the !User.HasResource || guard. View All holders are never filtered. Visits and visit plans ship with a filter built this way. Open the visit policy's rule to read a working formula before you write your own.

Scenario 6 — Portal users see only their own records

Goal. External (portal and partner) users see only the records that belong to their own contact, while staff are unaffected.

Configuration.

• Policy: External default access = Private or Read Only, independent of the internal value.
• Profile: the portal profile grants Read on the entity, and nothing more than portal users need.
• One rule: Access Filter, Filter Visible Records, Read (1), Applies To Audience = External, the expression ContactId == User.ContactId (the entity must have a contact field), and no target, or an Applies to target of All External.

Result. Each portal user sees only records whose contact is their own. Staff are not touched by the rule, because its audience is External. If the external default is Private, the filter narrows what they own. If it is Read Only, the filter is what keeps them away from other customers' records, so test it before you open the portal. See Portal security for the portal-side settings.

Scenario 7 — An audit role that reads everything

Goal. An internal audit role can read every record of an entity, whatever its ownership, shares, rules and filters, without being able to change anything.

Configuration. Give the audit profile Read plus View All on the entity, and no Update, Delete or Modify All.

Result. Record security is skipped entirely for the auditors' reads — no owner check, default, grant or filter applies, including Access Filter rules such as the field-staff filter in Scenario 5. They still cannot save changes, because the profile gate refuses Update. Modify All on its own would not widen reading; it skips record security only for update and delete. Keep profiles carrying these masks narrowly assigned.

Scenario 8 — Make a new entity visible to staff

Goal. Records of an entity you created are seen by every staff user, like most shipped entities, instead of only by the people who created them.

Configuration. Under Setup → Access Control → Policies select New policy, pick the Entity, set Internal default access = Read Only (and External default access as your portal needs), keep the three switches on and save. Give staff profiles Read on the entity.

Result. Staff read every record; owners and their managers edit them. Before the policy existed, the entity was Private with every switch off, so only each record's owner and View All holders could read it. From here you can tighten it with any of the scenarios above.

Quick interpretation rules

When a configuration does not behave as expected, these shortcuts point at the right layer.

Example

A distributor sets up its sales area from scratch, combining three scenarios.

1. Reps and managers (Scenario 1). The administrator opens the opportunity policy and confirms Private and Hierarchy Access on. Under Roles they make North sales rep and South sales rep children of Sales manager. Rep and manager profiles grant Read and Update on opportunities.
2. Regional quote desks (Scenario 2). The quote policy is also Private. They create business units North and South, file the two rep roles under them, and add two disabled Grant Read rules on the quote policy (BillingRegion == "North" → Business Unit North, BillingRegion == "South" → South).
3. Auditor (Scenario 7). A new Internal audit profile grants Read and View All on opportunities and quotes, nothing else.
4. Test. As a North rep they see only their own opportunities. As the sales manager they see both regions' opportunities and can edit them. They enable the quote rules, wait two minutes, and confirm a North rep sees every North quote and no South ones. As the auditor they see everything and the Edit button is not offered.

Orders were left alone: the shipped order policy is Organization Owned with Read Write defaults, so record security does not narrow orders at all, and the profile gate alone decides who can change them.

Training

Practice exercise

In a sandbox, take a custom entity with a text field you can set to North or South, and two test users in different roles, each with a profile granting Read, Create and Update (no View All).

1. Each user creates one record (North for user A, South for user B). Expected result: each sees only their own record, because the entity has no policy (Scenario 8 baseline).
2. Create a policy with Internal default access = Read Only. After two minutes: both see both records, but each can save only their own.
3. Change the default back to Private. Make user B's role a child of user A's role. Expected result: user A sees and edits user B's record; user B still sees only their own (Scenario 1).
4. Add a disabled Grant Read rule with expression <YourField> == "North" and an Applies to target of Role = user B's role, then enable it. Expected result: user B now also sees user A's North record, read-only.

Quick reference

• Two gates: the profile allows the operation; record security reaches the record.
• No policy, or an inactive one, means Private with every switch off.
• Private default + hierarchy = owners and their managers only.
• Groups get records through rules with targets; formulas cannot name the reader's unit, role or team.
• Grant Read and Grant Write (Update, Delete) are separate rules; seeing needs Grant Read unless the default already reads.
• Team targets work even when Allow team access is off.
• Filters narrow; guard resource filters with !User.HasResource ||.
• View All skips record security for reading, filters included; Modify All for writing.
• Build rules disabled, check Valid, test, then enable; allow two minutes.

Permissions

Configuration

Common problems

Managers see their team's records but cannot change them

The hierarchy gives the record path, but the manager's profile must still grant Update on the entity. Add it to the manager's profile.

Escalation team members still cannot see escalated cases

Check that both rules exist — a Grant Write rule alone does not let members see cases on a Private entity. Then check each member's assignment is active on the team's Assignments tab, the expression shows Valid, and the rules are enabled.

After adding a field-staff filter, office users see nothing

The filter has no resource guard, so users without a linked resource match no record. Start the formula with !User.HasResource ||, or add an Except target for the office role.

A regional rule covers one unit but not its sub-units

Business-unit targets do not follow the unit tree. Add a target for each sub-unit, or file the regional roles directly under the unit the rule targets.

The scenario worked for the administrator but not for the test user

The administrator's profile probably has View All or Modify All, which skip record security. Always test with a scoped account.

Common questions

Do permissions from multiple profiles conflict?

For entity operations, no: a user's effective entity permissions are the union of what their active profiles grant, and there is no deny that overrides a grant. A user with one profile granting Read and another granting Update has both. Field permissions are the exception: if any active profile has an explicit setting for a field, a profile that only inherits a broader setting does not lift that restriction. Before you conclude a grant is missing, check every active profile the user holds, and remember that removing one profile removes only what no other profile still grants.

Can a rule or share grant more than the profile allows?

No. Shares, the hierarchy, rules and default access decide which records are reachable; the operation itself must still be allowed by a profile grant on the entity. A record reached by a Grant Write rule stays read-only for a user whose profiles lack Update, and a record shared with a user who has no Read grant stays unreadable. When you want someone to act on records, check both gates deliberately.

What does a Private default actually mean?

With Internal default access = Private on a User Owned entity, staff see only records they own plus whatever explicit paths you configure: hierarchy roll-up to managers, Access Grant rules, shares, or a profile's View All. Internal and external users have separate defaults on the same policy — for example Read Only for staff while portal users stay Private — so check both when the two audiences behave differently. An entity with no policy at all is also Private, for both audiences, with every switch off.

Should I use shares or rules for group access?

Use rules for standing arrangements — a region's records, a record type, escalated cases. They are listed on the policy page, can be switched off in one place, and team targets work whatever the policy's team switch says. Shares are per record, are created only through the metadata API, and count only when the policy's Allow manual share is on, so they suit rare one-off exceptions. If you find yourself sharing the same kind of record repeatedly, replace the shares with a rule.

Related topics

• Security model concepts
• Security profiles
• Roles, teams and business units
• Record security
• Restriction rules
• Portal security
• Troubleshooting: a user can't see something