Skip to content

Collaborators & Walls

Part of: ClientVerse Core (every client).

What it is

Two complementary answers to "who can see this, and who is working on it".

  • A Wall (Wall__c) is a restriction with an audit trail — a controlled boundary around a set of records, with explicit membership and a recorded lifecycle.
  • A Collaborator (Collaborator__c) records who works with whom on relationships and matters, driving the team-sharing model.

They are often discussed together but solve opposite problems: Collaborators widen appropriate access, Walls constrain it.

Who it's for

  • Admins create Walls, manage membership, and own the sharing model.
  • Attorneys and BD work inside them — seeing the records shared with their team, and not seeing what they shouldn't.

How it works

Walls

A Wall has members (Wall_Member__c) with roles and access levels, and its own sharing configuration (Wall_Sharing__c). Only users with the right membership see a Wall and what is shared on it.

A Wall grants visibility, not ownership. Sharing a record on a Wall never changes who owns it — which matters because ownership drives a great deal of other behaviour, from reporting to assignment rules.

Removal is a state change, not a delete. A Wall carries Wall_Status__c (Active / Removed) plus Removed_By__c, Removal_Date__c, and Removal_Justification__c. Taking a Wall down records who did it, when, and why, rather than erasing the fact that it existed — the firm needs to be able to answer "was this wall in place on that date?" long after the fact.

Two things to know about the lifecycle fields. They are not required at the schema level — requiredness is enforced by the layout and the removal process, so any API path (data loads, overlay code) can create a Wall with no status. And Walls created before those fields existed have a null Wall_Status__c, so a filter on Wall_Status__c = 'Active' silently drops them. Filter for "not Removed" instead.

Collaborators

A Collaborator records a working relationship between the firm's people and the people they work with. Collaborators surface on the records and Walls you are part of, and how they display is driven by Collaborator_Display_Config__c and Collaborator_Field_Mappings__mdt.

Access

Three permission sets govern this area:

Permission set Grants
Wall_Permitted_User Access to Walls the user is a member of
Collaborator_Admin Create and manage Walls and collaborator records
Collaborator_Config Configure collaborator display and field mappings

If a user cannot see a Wall they expect to, that is nearly always membership or one of these sets — start there, and see the Troubleshooting guide.

How to use it

Set up a Wall (admin)

  1. Create a Wall__c with its description and the user it walls off.
  2. Add Wall_Member__c records with the appropriate roles and access levels.
  3. Share the relevant records onto the Wall.

Take a Wall down (admin)

Set Wall_Status__c to Removed and complete the justification. Do not delete the record — deleting destroys exactly the audit fact the Wall exists to provide.

Work in a Wall (attorney / BD)

Open the Wall to see the shared records. Access follows membership, so if a colleague cannot see something you can, they are probably not a member.

  • Configuration Reference — display config and field mappings.
  • Admin Guide — the security model this operationalizes.
  • Security Architecture — the private-first OWD model.
  • QA coverage: COL in core-collaboration.md — note that the negative cases (non-member cannot see, removal revokes) are the ones that actually validate this feature.