Skip to content

Who sees what — the security and visibility model

This is the question every firm asks first, and the one with the most expensive wrong answers. It has two halves that pull against each other:

  • Confidential work must not be broadly visible. Matter detail, financials, and screened engagements are the obvious cases.
  • But it must be visible enough to prevent an inappropriate approach. A BD professional who cannot see that the firm already acts against a company is a BD professional who will pitch that company.

A model tuned only for the first half produces the second failure. This page explains how ClientVerse lets you hold both.

The four layers

Access is built from four layers, applied in order. Each assumes the one before it.

Layer What it does Ships configured?
1. Profile Baseline login and object minimums. Grants no ClientVerse access Yes — minimal by design
2. Permission set groups The persona. What this kind of user can do Yes — 9 groups
3. OWD + public groups The default visibility of records, then broad sharing No — you must set this
4. Apex sharing via Collaborator Record-by-record access, including walls Machinery only

Layer 3 is the one that catches firms out. The package ships permissive defaults. Until you tighten them, layers 3 and 4 restrict nothing — see The silent failure below.

Layer 1 — Profiles stay minimal

ClientVerse grants nothing through profiles. Every capability arrives through a permission set.

This is deliberate and worth defending when someone proposes a shortcut: a profile is assigned once and inspected rarely, so a grant added there is invisible in practice. Permission sets are composable, auditable, and removable without moving the user.

Layer 2 — Personas, not permissions

Core ships 74 permission sets and Modules a further 20 — 94 in an org with both installed — plus 9 permission set groups in Core. Admins assign groups, not individual sets. The sets are building blocks; the groups are the personas.

Persona group Composed of
CV_Admin_Team Base Access + Full Access
CV_BD_Team Base + BD Schema Access + BD User + Relationship (schema + user)
CV_Marketing_Team Base + Marketing Admin/User/Schema + Campaign Record Types + MCAE Integration + Relationship
CV_Executive Base + Analytics Executive Admin + Analytics User/Schema + Relationship
CV_Practice_Leads Base + Analytics Practice Lead Admin + Analytics + Relationship
CV_Lawyer_Team Base + Relationship (schema + user)
CV_Matters_Access Base + Analytics Schema + Relationship
CV_Partners Base + Analytics Schema + Relationship
CV_Data_Steward New in 1.1.10: CV_Base_Access, CV_Data_Quality_Schema_Access, CV_Data_Quality_User and CV_Classification_User. Gives the CV Admin app without full admin access, but can't read Data Quality issues or Classifications alone, so assign CV_Data_Manager and CV_Classification_Schema_Access with it

CV_Base_Access appears in all eight original groups — it is the floor.

In 1.1.10 the eight original groups don't give access to a CV app or to Lightning Experience, so assign app visibility separately. Only CV_Data_Steward includes it.

The building blocks follow a three-tier convention:

  • _Schema_Access — object and field visibility, nothing more
  • _User — the day-to-day capability
  • _Admin — configuration and administration of that area

Assign groups. Resist assigning individual sets, which is how an org drifts into a state nobody can reason about. If a persona is nearly right, the correct move is a new group composed of existing sets, not a one-off set assignment to one user.

Counts are from the synced package facts for Core 1.1.10 and Modules 0.8.0 (clientverse-core-1.1.10.json, clientverse-modules-0.8.0.json). Setup also lists one backing record per permission set group, so expect a higher total there. Older figures of 20 or 24, where they still appear, predate the 1.1.7 tiering and should not be relied on.

Layer 3 — Org-wide defaults and public groups

This layer is yours to configure. The package cannot ship it, because a vendor cannot presume a firm's confidentiality posture, and because a package that arrived locked-down would look broken on first login.

What the package actually ships:

Object OWD as installed
Account, Contact, Opportunity, Case, Campaign Public Read/Write
Matter, Experience, Trip, Wall, Collaborator, Client Group, Classification Public Read/Write
Business Plan Private on a new 1.1.10 install, with access through the Plan Team. An upgrade keeps the org's existing setting
List Public Read

Business Plans changed in 1.1.10. An upgrade leaves the org's existing Business Plan setting (Public Read/Write) in place, so nobody loses access. To switch, add Plan Team members to the plans that need them, ask your implementation team to run the Plan Team access back-fill, then set Business Plan to Private in Sharing Settings. Four permission sets grant View All on Business Plans — CV_Full_Access, CV_BD_Admin, CV_Analytics_Executive_Admin and CV_Executive_Analytics — so review who holds them.

A second bypass, above OWD entirely

Everything in layers 3 and 4 assumes no user holds View All Records on the object. That permission bypasses sharing by design — org-wide defaults, sharing rules, collaborators and walls all stop applying to anyone who has it.

In 1.1.10, as in 1.1.7, CV_Base_Access grants View All Records on Account, Campaign, Contact, Event, Opportunity and Task, and CV_Base_Access is in all nine persona groups (CV_Data_Steward included). Every ClientVerse user can therefore read every record on those six objects, whatever you set OWD to. (Checked in the 1.1.10-2 build source.)

This has been raised as a defect (cv-crm#519) and is due to be removed; it is not an intended design. It is still present in the 1.1.10 package. Until it is fixed, walls cannot restrict account or contact visibility, because the restriction never takes effect.

Walls over Matter__c, Experience__c and List__c are unaffected — those grant View All only through CV_Full_Access.

Audit for this before trusting any sharing model, in your own org and after every upgrade:

SELECT Parent.Name, SobjectType, PermissionsViewAllRecords, PermissionsModifyAllRecords
FROM ObjectPermissions
WHERE PermissionsViewAllRecords = true OR PermissionsModifyAllRecords = true
ORDER BY Parent.Name, SobjectType

Rows where Parent.Type = 'Group' duplicate their member sets and can be ignored. Anything else is a user population for whom your sharing model does not apply.

Check the _Schema_Access sets specifically. The tier is documented as visibility only, but in 1.1.10 / 0.8.0, as in 1.1.7, CV_Trip_Schema_Access, CV_Dispatch_Schema_Access and CV_Data_Quality_Schema_Access each grant View All Records — record-level access, from the tier an admin reaches for because it is supposed to be the safe one. Also covered by cv-crm#519.

The silent failure

Walls, collaborators, and every sharing rule below this layer do nothing while OWD is Read/Write.

Nothing errors. The wall records exist, members are attached, the UI looks correct — and every record remains visible to everyone, because there is no restriction for sharing to grant an exception to. Sharing only ever adds access.

For an ethical-wall feature at a law firm, this is the most consequential sentence in this guide. Set OWD to Private on the objects walls must cover before you rely on a wall.

Those objects are the ones Wall_Sharing__c can reference: Account, Matter, Experience, List, Business Plan, Campaign, and DMS Document.

How to change it

Setup → Sharing Settings → Edit.

Two practical notes. Account cannot be set to Private on its own — Salesforce requires Opportunity and Case to be no more permissive, so they change with it. And the packaged custom objects (Matter, Experience, List, Business Plan) cannot be changed by a metadata deploy from a subscriber org — the Metadata API demands a full object redefinition. Setup UI is the route.

Public groups

With OWD Private, public groups plus sharing rules are how you restore broad access deliberately: everyone in a practice sees that practice's matters, everyone in an office sees that office's clients. Build the groups to match how the firm actually organises, not the org chart.

Layer 4 — Record-level sharing and walls

The finest layer works through Collaborator__c records, each naming a target user or group and an access level (Read or Edit), with a Source of Manual, Team, or Wall.

Walls are the screened-engagement case:

  • A Wall names the walled user and a status
  • Wall Members are the users permitted, each with an access level
  • Wall Sharing rows name the records the wall covers

When a Wall Sharing row is created, the platform is designed to generate wall-sourced Collaborator records and grant the Wall_Permitted_User permission set to the wall's members.

Which objects participate is governed by the Collaborator_Field_Mappings__mdt Custom Metadata Type. It ships with nine rows, of which Account, Matter, List, and DMS Document are enabled; Campaign, Contact, Experience, Opportunity, and Plan are present but switched off. Enable the ones your firm needs.

Known defect, still open. Reported on 1.1.7: a correctly configured wall — active wall, active members, sharing rows on an enabled object — produces no Collaborator records, no permission set grants, and no error or log entry. This is tracked as cv-crm#481, which is still open, and the 1.1.10 release notes don't list a fix. Until it is resolved, do not rely on walls as your only control for a screened engagement. Use OWD plus explicit sharing, and verify access with a test user rather than assuming.

Walls need CV automation switched on. In 1.1.10, CV_Trigger_Setting.Org_Default ships with Triggers_Enabled__c set to false, and walls and collaborators are among the features that do nothing until it is enabled for each object. See Turning automation off.

A related 1.1.10 limitation: a second collaborator row that differs from another only by Role or Primary is now kept, but creating its share can fail without an error.

Verifying it actually works

The single most important habit, and the one most often skipped:

Test with a non-administrator. System Administrators have View All Data, which bypasses OWD and sharing entirely. An admin checking their own view will see everything and conclude the model works. Create a test user, assign the persona group, and confirm what they can and cannot see.

A useful check sequence:

  1. Create a test user with one persona group and no administrative profile
  2. Confirm they see the apps and tabs the persona should have
  3. Confirm they cannot see a record the persona should not
  4. Add sharing (group, or collaborator) and confirm access appears
  5. Remove it and confirm access disappears

Step 5 is the one people skip, and revocation is where sharing models usually fail.

Common questions

"Can BD see that a client is conflicted without seeing the matter?" Yes, and this is the pattern to reach for: keep Matter Private, and share the account-level signal broadly. The goal is that BD knows to ask, not that BD knows the detail.

"Who can see financial data — revenue, WIP, AR, realisation?" Field-level security within the persona sets, on top of record access. Decide the visibility tier per persona before go-live; retrofitting is much harder than starting restrictive.

"Do we need walls, or is OWD enough?" If the requirement is "these named people, and only they, may see this engagement", that is a wall. If it is "only the practice sees its own matters", that is OWD plus a sharing rule, and is simpler and more robust. Do not reach for walls when a sharing rule will do.

"What happens on upgrade?" OWD, sharing rules, public groups, and permission set assignments are org configuration, not packaged metadata. They survive package upgrades. The post-install steps are what need re-checking.