ClientVerse Admin Guide

This guide is for the people who own and operate a ClientVerse org: the CRM administrator, the firm's IT/Salesforce team, and anyone responsible for access, data, and upgrades. It covers what ships in the product, how the security model is laid out, how to grant access, and how to administer the moving parts (rollups, classification, logging, and the optional Modules features).

Audience-first. If you are a user (attorney, BD, marketing, RM) looking to get work done, start with the User Guide. If you are installing ClientVerse for the first time, start with the Implementation Guide. This guide assumes the package is already installed and you are running it day-to-day.

Default assumption: your org has Core only. Anything that requires the optional Modules add-on is marked with a 🧩 badge. If you don't have Modules, skip the badged sections — those objects and apps won't be present in your org.

All package facts in this guide (counts, app names, permission-set names, objects) are cited from the synced _package-facts/ — never asserted from memory. Where a number or name matters, follow the link to confirm against the authoritative source.

---

1. Overview & responsibilities

ClientVerse is a Salesforce-native CRM for law firms. As an administrator you are responsible for:

• Access — assigning the right permission sets / permission-set groups to the right people, and keeping that mapping current as roles change.
• Data — overseeing imports and migrations, monitoring rollups, curating the classification taxonomy, and keeping data quality and governance under control.
• Operability — watching the logging object, planning sandbox-first upgrades, and installing package upgrades in a controlled way.
• Modules (if licensed) — configuring Dispatch digests/notifications, the Whitespace scoring engine, and deciding whether to enable the early-access AI and Analytics capabilities.

You do not manage per-firm overlay customization here — that lives in customer delivery, outside the product guides. This guide documents the shipped product only.

Architecture at a glance

ClientVerse follows a hub-and-spoke pattern with Salesforce as the system of record. For the authoritative picture, read the architecture docs rather than re-deriving the design here:

• ../../architecture/ClientVerse_Technical_Architecture.md — system shape, data domains, integration and environment strategy.
• ../../architecture/ClientVerse_Security_Architecture.md — the profiles / permission-set / permission-set-group / sharing model this guide operationalizes.
• ../../architecture/System_Architecture_Diagram.md and ../../architecture/Data_Flow_Diagram.md — visual views of structure and data movement.

The data model these organize around is documented in ../../data-model/; the domain vocabulary (Experience, Matter, Opportunity, Classification, ERM, …) is in ../../GLOSSARY.md. Before doing anything that looks obvious but might be wrong, check ../../GOTCHAS.md.

---

2. Packages & namespace

ClientVerse ships as two Salesforce packages. Knowing which package an object, app, or permission set comes from tells you whether every client has it and how it gets upgraded.

Edition	Package type	Version	Package version	Namespace	Who has it
ClientVerse Core	Unlocked (2GP)	1.1.7	ClientVerse Core Unlocked@1.1.7-6	clientverse	Every client
ClientVerse Modules	Managed (2GP)	0.4.0	ClientVerse Modules@0.4.0-2	clientverse	Optional add-on

Cite: clientverse-core-1.1.7.json, clientverse-modules-0.4.0.json.

Core is the foundational CRM: the data model, the six applications, the security model, and the BD / relationship workflows. It is an unlocked package, so its metadata is editable in your org (subject to the usual care around package-owned components). Per the synced facts, Core 1.1.7 contains 148 custom objects, 2,457 fields, 6 applications, 60 tabs, 66 permission sets, and 8 permission-set groups. It also extends 13 standard Salesforce objects — Account, Contact, Opportunity, Campaign, Lead, Case, Task, Event, User and others carry ClientVerse fields, which matters when you are reasoning about field-level security or an upgrade's blast radius on standard objects.

Modules is a managed add-on that delivers premium capabilities on top of Core. In 0.4.0 the shipped module areas are Dispatch (notifications/digests), Whitespace (revenue-opportunity scoring), AI (in-platform chat and the AI Actions framework), Analytics (Power BI / Tableau embedding), and General (background automation with no objects or UI of its own). It contributes 21 custom objects, 269 fields, 11 permission sets, 11 tabs, and one application, and extends 3 objects it does not own. Because Modules is managed, its components are namespaced and not directly editable — you configure it through the records and custom metadata it exposes.

AI and Analytics are now in the package — and off by default. The previous release documented AI as "coming, not available". As of Modules 0.4.0 both the CV AI Chat interface and the Power BI / Tableau components ship in the package, gated behind their permission sets (CV_AI_Chat_User, CV_BI_Visualization). Nothing is enabled for anyone until you assign those sets. Both are early-access — see §14 before rolling either out.

A note on the Core package name

In the Dev Hub the Core package is registered as ClientVerse Core Unlocked. The product is still called ClientVerse Core, and this is the only Core line that installs anywhere. Two further packages — ClientVerse Core (managed, schema only) and ClientVerse Core Plus — are declared in the build but are not developed against yet and ship to nobody. See ADR-0010.

What this means for you today: nothing changes. Core is still unlocked, its metadata is still editable in your org, and upgrades work exactly as before. If and when the managed Core line becomes the shipping one, that will be a documented migration with its own runbook — it is not something to prepare for now.

Dependency: Modules → Core (one-way)

The dependency runs one way: Modules depends on Core, never the reverse. Core runs perfectly well on its own.

Compatibility — Modules 0.4.0 requires Core 1.1.7. Modules 0.4.0 declares a dependency on ClientVerse Core Unlocked@1.1.7-6. This floor moved up from Core 1.1.4 in the previous release, so an org that was running Modules 0.3.0 on Core 1.1.4/1.1.5/1.1.6 must upgrade Core to 1.1.7 first. Upgrading Modules before Core will fail the install. Cite: clientverse-modules-0.4.0.json (depends_on) and sync-report.md.

The package-facts are synced from cv-crm main — the branch package versions are cut from — so they describe what you can actually install, never in-flight work (ADR-0009). Treat the sync-report.md as the record of what each released package actually contains.

---

3. Applications

Core ships 6 Lightning applications. Cite: clientverse-core-1.1.7.json (applications). Assign users to apps via the App Launcher / profile or permission-set app visibility.

Application (API name)	For
CV_Admin	Administrators — setup, configuration, system management
CV_BD	Business development — opportunities, pitches, referrals
CV_Experience	Experience / matter and relationship intelligence
CV_Intelligence	Cross-cutting relationship & firm intelligence
CV_Lawyer	Attorneys / partners — day-to-day lawyer-facing CRM
CV_Marketing	Marketing — campaigns, lists, events

🧩 ClientVerse Modules — Dispatch Requires the ClientVerse Modules package. Clients on Core only won't see this.

Modules 0.4.0 adds one application, CV_Dispatch_Setup, the admin workspace for configuring Dispatch (definitions, sections, data tables, subscriptions, settings), plus 11 tabs across the module areas — including the CV_AI_Chat tab. Cite: clientverse-modules-0.4.0.json (applications). There is still no separate Whitespace app — Whitespace is administered entirely through its custom metadata (see §13).

---

4. Security model

ClientVerse is private-first: org-wide defaults lock objects down, and access is granted in layers — profile → permission set → permission-set group → sharing. The authoritative design (profiles, OWD, sharing rules, field-level security, CRUD matrix) lives in ../../architecture/ClientVerse_Security_Architecture.md. This section maps the 66 Core permission sets and 8 permission-set groups to the roles that typically need them.

The permission-set and group names below are the exact API names from the synced package facts — clientverse-core-1.1.7.json (permission_sets, permission_set_groups). The role groupings are inferred from the names and the persona-to-security mapping in the security architecture; adapt them to your firm.

4.1 The tiered model (new in 1.1.7)

Core 1.1.7 introduced a three-tier structure per functional area. Understanding the tiers is the fastest way to navigate 66 sets:

Tier	Suffix	Grants	Give it to
Schema Access	_Schema_Access	Object, field, record-type, and tab visibility. No Apex, LWC, or admin capability	Anyone who must see the area's data — including integration and reporting users
User	_User	Schema access plus the components and actions an everyday user needs	The people who work in that area
Admin	_Admin	User access plus configuration of that area	The small group who configure it

The tiers exist so you can stop over-granting. Previously, giving someone visibility of an area often meant giving them a broad set that also carried code access; now the Schema Access tier grants exactly the visibility and nothing else.

Areas with tiered sets:

Area	Schema Access	User	Admin
Business development	CV_BD_Schema_Access	CV_BD_User	CV_BD_Admin
Classification	CV_Classification_Schema_Access	CV_Classification_User	CV_Classification_Admin
Collaboration / Walls	CV_Collaborator_Schema_Access	CV_Collaborator_User	CV_Collaborator_Admin
Data quality	CV_Data_Quality_Schema_Access	CV_Data_Quality_User	CV_Data_Quality_Admin
List Builder	CV_List_Builder_Schema_Access	CV_List_Builder_User	CV_List_Builder_Admin
Marketing	CV_Marketing_Schema_Access	CV_Marketing_User	CV_Marketing_Admin
Trips	CV_Trip_Schema_Access	CV_Trip_User	CV_Trip_Admin
Analytics	CV_Analytics_Schema_Access	CV_Analytics_User	CV_Analytics_Executive_Admin, CV_Analytics_PracticeLead_Admin
Relationships	CV_Relationship_Schema_Access	CV_Relationship_User, CV_Relationship_Intelligence_User	—
Recognition	CV_Recognition_Schema_Access	CV_Recognition_Read, CV_Recognition_Manage	CV_Recognition_Admin
Rollups	CV_Rollups_Schema_Access	—	CV_Rollups_Admin, Rollup_Definition_Admin
Governance	CV_Governance_Schema_Access	—	CV_Governance_Admin

CV_Base_Access is the baseline every ClientVerse user needs — assign it to everyone, then layer the area sets on top.

This was an additive change. All 24 permission sets that existed in Core 1.1.6 are still present in 1.1.7 — nothing was removed and no assignment broke on upgrade. The 42 new sets sit alongside them. Migrate to the tiered model deliberately; there is no deadline and no forced cutover. The sets carried forward from the older model are CV_BD_Operations, CV_BD_Task_Management, CV_BD_Trip_Management, CV_Marketing_Operations, CV_Relationship_Data_Access, Classification_Management, Collaborator_Admin, Collaborator_Config, ListBuilder_User, List_Builder_Admin_Permission, and Wall_Permitted_User.

4.2 Capability sets (not area-tiered)

These grant a specific capability regardless of area:

Permission set	Grants
CV_Full_Access	Everything. Administrators only
CV_Base_Access	The ClientVerse baseline — assign to every user
CV_Bulk_Tools_Access	CSV Import, Bulk Add, Bulk Activity
CV_Mass_Update_Admin	The Mass Update tool
CV_Merge_Records	Deep merge of duplicate records
CV_Export_Child_Records	Exporting child records alongside parents
CV_Financial_Data_Access	Financial and billing fields
CV_Data_Import_Full_Access, CV_Data_Migration, CV_Data_Manager	Bulk load, cutover migration, ongoing data stewardship
Override_Auto_Generated_Name	Preserving incoming names against auto-naming during load
CV_View_Child_Clients	Visibility of child accounts in a hierarchy
CV_Practice_Leadership, CV_Executive_Analytics	Practice-wide and firm-wide reporting scope
CV_Trip_Target_Override_Access	Overriding trip-target selection rules
CV_Marketing_Campaign_Record_Types	Campaign record types
CV_Setup_Checklist_Admin	The Admin Setup Checklist
MCAE_Integration	The MCAE marketing-automation integration user

4.3 Role → permission-set / group mapping

Every row assumes CV_Base_Access is already assigned. Where a group exists for the role, assign the group; the individual sets are shown so you can see what it contains and grant exceptions.

Role	Grant via (group or set)	Why
CRM Administrator	Group CV_Admin_Team; plus CV_Full_Access, CV_Setup_Checklist_Admin	Full system access and the setup checklist
Data / migration lead	CV_Data_Migration, CV_Data_Import_Full_Access, CV_Merge_Records, Override_Auto_Generated_Name	Bulk load, migrate, dedupe/merge, and override auto-named records during import
Power user running bulk work	CV_Bulk_Tools_Access (+ CV_Mass_Update_Admin)	CSV Import, Bulk Add, Bulk Activity; Mass Update
Marketing professional	Group CV_Marketing_Team → CV_Marketing_User, CV_List_Builder_User, CV_Relationship_User	Campaign/list management and List Builder
Marketing operations lead	CV_Marketing_Admin, CV_List_Builder_Admin	Configure campaigns, record types, and list building
BD professional	Group CV_BD_Team → CV_BD_User, CV_Trip_User, CV_Relationship_User	Opportunity/pitch/referral work and trip planning
BD operations lead	CV_BD_Admin, CV_Trip_Admin	Configure BD processes and trip administration
Associate / junior lawyer	Group CV_Lawyer_Team → CV_Relationship_User (no financial data)	Relationship intelligence without financial fields
Senior lawyer / Partner	Group CV_Partners → CV_Financial_Data_Access + relationship access	Full financial + relationship access
Practice group leader	Group CV_Practice_Leads → CV_Practice_Leadership, CV_Analytics_PracticeLead_Admin	Practice-wide reporting, View All Opportunities
Firm executive	Group CV_Executive → CV_Executive_Analytics, CV_Analytics_Executive_Admin	Firm-wide analytics, forecasts, View All on key objects
Finance / billing viewer	CV_Financial_Data_Access	Read access to financial/billing fields
Classification steward	CV_Classification_Admin	Manage the classification taxonomy (see §8)
Rollups administrator	CV_Rollups_Admin (+ Rollup_Definition_Admin)	Configure and reprocess rollups (see §7)
Data quality steward	CV_Data_Quality_User / CV_Data_Quality_Admin	Work and configure data-quality issues
Governance owner	CV_Governance_Admin	Define and enforce data governance policies
Recognition steward	CV_Recognition_Manage / CV_Recognition_Admin	Record and administer awards and rankings
Collaboration admin	CV_Collaborator_Admin (+ Wall_Permitted_User)	Administer the Collaborator/Wall features
Reporting / integration user	The relevant *_Schema_Access sets	Data visibility with no component or admin capability

The 8 permission-set groups (permission_set_groups in the cited JSON) bundle the sets above for one-click role assignment. CV_Admin_Team and CV_Lawyer_Team are new in 1.1.7 and fill the two gaps the earlier six left:

Permission-set group	Typical role
CV_Admin_Team	CRM administrators — new in 1.1.7
CV_Lawyer_Team	Attorneys / fee-earners — new in 1.1.7
CV_BD_Team	BD professionals
CV_Marketing_Team	Marketing professionals
CV_Partners	Senior lawyers / partners
CV_Practice_Leads	Practice group leaders
CV_Executive	Firm executives
CV_Matters_Access	Matter-context financial + relationship access

Start here. For most firms the right first move is: assign CV_Base_Access to everyone, then one group per role from this table. Reach for individual sets only where a person genuinely needs an exception.

🧩 ClientVerse Modules — Dispatch Requires the ClientVerse Modules package. Clients on Core only won't see this.

Modules 0.4.0 adds 11 permission sets — up from 3, following the same tiering as Core (cite: clientverse-modules-0.4.0.json, permission_sets):

Permission set	Grant to
CV_Modules_Access	Baseline access to Modules components — the prerequisite for everything below
CV_Dispatch_Schema_Access	Visibility of Dispatch objects without component access
CV_Dispatch_User	End users who receive, subscribe to, and act on dispatches
CV_Dispatch_Lawyer	The pre-1.1.7 end-user set, retained — equivalent to CV_Dispatch_User
CV_Dispatch_Admin	Admins who configure definitions, sections, data tables, settings
CV_AI_Schema_Access	Visibility of AI session objects
CV_AI_User	Everyday AI capability
CV_AI_Chat_User	The switch for CV AI Chat. Nobody sees the chat interface without this
CV_AI_Admin	AI configuration — action templates, adapter limits, system prompts
CV_AI_Actions_Permission	Invoking AI Actions from flows and components
CV_BI_Visualization	The switch for Power BI / Tableau embedding

The security architecture composes the Dispatch end-user set into the CV_Partners, CV_Practice_Leads, and CV_Executive groups, so partners and above get Dispatch access through their existing group. Grant CV_Dispatch_Admin directly to the small set of people who build digests. CV_AI_Chat_User and CV_BI_Visualization grant nothing until you assign them deliberately — see §14.

4.4 Field-level & sharing model (cite, don't duplicate)

The private-first OWD strategy, the three-tier sharing model, and the field-level security rules (financial fields restricted by default; relationship-intelligence fields broadly shared) are specified in the security architecture — sections 6–9 of ClientVerse_Security_Architecture.md. Do not re-implement these from this guide; follow that document.

---

5. Assigning access: permission sets vs. groups

Two ways to grant access; prefer groups for role-based assignment.

• Permission-set groups (recommended default). Assign a single group — e.g. CV_BD_Team — and the user inherits every permission set bundled inside it. This keeps role definitions in one place: change the group composition once and every member's access updates. Use the groups in §4.1 as the primary assignment unit.
• Individual permission sets. Assign a single set for additive or exception access that doesn't fit a standard role — e.g. granting CV_Merge_Records to one data steward, or CV_Rollups_Admin to an admin who isn't on CV_Full_Access.

Guidance:

1. Start from the role in the §4.1 table and assign the matching group.
2. Layer individual sets for exceptions (data leads, stewards, one-off elevated access).
3. Avoid profile sprawl — keep entitlements in permission sets/groups, not custom profiles, so the model stays auditable. The base profiles are described in ClientVerse_Security_Architecture.md §3.
4. Use muting carefully — permission-set groups support muting individual permissions; document any muting so the effective access stays explainable.

To assign: Setup → Permission Set Groups (or Permission Sets) → Manage Assignments → Add Assignment. Group recalculation runs asynchronously; allow a few minutes after editing a group's composition.

---

6. Data import & migration

Most data entering ClientVerse arrives through a migration (from a legacy CRM/PMS) or a bulk import, not hand entry. Two access prerequisites gate this work:

• CV_Data_Import_Full_Access — broad import access for loading data.
• CV_Data_Migration — migration-specific access for a controlled cutover.
• CV_Merge_Records and Override_Auto_Generated_Name — for dedupe and for preserving incoming names against auto-naming rules during load.

Entry points for the actual procedures (do not duplicate here — link):

• Migration strategy and source-specific runbooks — ../../migrations/: the overall 00_Migration_Strategy.md plus the InterAction, Experience-System, Opportunities, and Vuture migration guides.
• First-time install / rollout sequencing — ../implementation-guide/.
• External-system integrations (PMS, marketing automation, etc.) — ../../integrations/.
• External-ID strategy (how records are keyed across systems) — ClientVerse_Technical_Architecture.md §3.3.

Administrative vs. client-facing IDs. Production_ID__c-style fields are system-managed/administrative; legacy and external IDs that users rely on are client-facing and are retained. Confirm field intent in ../../data-model/ before mapping import columns.

---

7. Rollups administration

ClientVerse computes summary values (counts, sums, last-activity dates, relationship metrics) via rollups. Administer them with the CV_Rollups_Admin permission set.

• What rollups do: aggregate child records up to parents (e.g. activity onto a relationship, opportunities onto an account) so users and dashboards read a single computed value.
• Admin tasks: enable/disable individual rollup definitions, trigger a recalculation/backfill after a bulk import or migration, and monitor for recalculation errors.
• After a large data load, plan a rollup recalculation so summary fields reflect the imported records. Sequence this after the import completes to avoid recalculating mid-load.

Grant CV_Rollups_Admin only to administrators; rollup recalculation is resource- intensive and should be coordinated, not ad hoc.

8. Classification administration

ClientVerse uses a classification taxonomy (industries, practice areas, segments, and similar controlled vocabularies) to tag accounts, contacts, and matters consistently. Administer it with Classification_Management.

• What it is: the controlled lists that drive consistent tagging and segmentation across the CRM (see Classification in ../../GLOSSARY.md).
• Admin tasks: maintain the taxonomy values, retire obsolete terms, and keep the taxonomy aligned with how the firm reports.
• Related access: Override_Auto_Generated_Name lets stewards override auto-generated record names where the taxonomy or import requires a specific name.

Classification feeds downstream features — notably Whitespace scoring (§13), which scores accounts against practice areas — so taxonomy hygiene directly affects the quality of those outputs.

9. Logging — Clientverse_Log__c

ClientVerse writes operational and error events to the Clientverse_Log__c object. This is your first stop when diagnosing failures (integration errors, automation faults, dispatch problems).

• Where to look: open the Clientverse_Log__c list views / reports; filter by severity, source, and date.
• What you'll find: error summaries and context for failed operations across the product.
• Retention: establish a retention/cleanup policy (e.g. periodic deletion of old log rows) so the object doesn't grow unbounded; coordinate with your storage limits.

🧩 ClientVerse Modules — Dispatch Requires the ClientVerse Modules package. Clients on Core only won't see this.

Modules 0.4.0 extends three objects it does not own — the Core Clientverse_Log__c and the standard Activity (both Dispatch) and CampaignMember (Whitespace) — so module activity surfaces in the Core logging object you already monitor rather than needing its own log surface. Cite: clientverse-modules-0.4.0.json (extends_objects) and _package-facts/objects/dispatch.yaml (extends). You do not need a separate log surface for Dispatch.

10. Data quality & governance

Core ships three related capabilities for keeping the data trustworthy. They are separate permission areas because firms staff them differently.

Data Quality Monitoring (CV_Data_Quality_User / CV_Data_Quality_Admin) scores records and raises a Data_Quality_Issue__c when a record falls short, with Data_Quality_Score__c holding the measure. Treat the issue object as a work queue, not a report — assign the issues, and watch whether the queue is being drained. A queue that only grows means the scoring rules are miscalibrated or nobody owns the work.

Data validation & account enrichment proposes corrections as Enrichment_Proposal__c records for a human to accept or reject, rather than writing to the record directly. Configuration lives in Enrichment_Config__mdt. Review the proposal queue on a regular cadence; unreviewed proposals are the same problem as unworked issues.

Governance policies (CV_Governance_Admin) let the firm define its own data rules in Governance_Policy__c, with org-level behaviour in Governance_Settings__c. Introduce a new policy in a sandbox against real data volumes first — a policy that fires on a large fraction of existing records will generate more work than the firm can absorb.

Sequence matters after a migration. Load data first, then let data quality and enrichment run. Running them mid-load produces issues against records that are still incomplete by design.

11. Bulk operations

Core 1.1.7 gives power users four bulk tools that previously required an administrator with a data loader: CSV Import, Bulk Add, Bulk Activity, and Mass Update. Access is granted by CV_Bulk_Tools_Access (the first three) and CV_Mass_Update_Admin (the fourth).

What you need to know as the administrator who grants them:

• Every job writes to Clientverse_Log__c. Job tracking was consolidated onto the standard logging object in 1.1.7 — the previous Audit_Log_Import__c and Mass_Update_Job__c objects were retired. If you had reports on either, re-point them at Clientverse_Log__c.
• CSV Import does fuzzy duplicate detection, not exact matching only. That is the right default, but it means the importer's judgement is visible to the person running it. Brief users that flagged rows need a decision rather than a click-through.
• Mass Update has real blast radius. Grant CV_Mass_Update_Admin narrowly, and coach holders to check the record count before applying.
• Consider the automation kill switch for large loads. Packaged automation can be disabled per object during a bulk load and re-enabled afterwards, which avoids triggering rollups and automations once per row. Re-enable it — and run a rollup recalculation — when the load is done.

12. Routine maintenance & upgrades

• Sandbox-first. Validate every package upgrade and configuration change in a sandbox before production. The environment strategy is described in ClientVerse_Technical_Architecture.md §2.4 / §6; install/governance specifics live in ../../deployment/.
• Core upgrades (unlocked package). Install the new package version into the sandbox, run a smoke test of the six apps and the security model, then promote. Because Core is unlocked, watch for local edits to package-owned components that an upgrade could touch.
• Modules upgrades (managed package). Managed-package upgrades are version-bumped installs; confirm the Core baseline first (see the §2 compatibility flag — Modules 0.4.0 requires Core 1.1.7). Upgrade Core before Modules, always: the reverse order fails the install.
• Post-install manual steps that are not packaged. Two things do not ship as metadata and must be configured in the org after every fresh install: the restriction rules (Show_Wall_Accounts, Show_Wall_Records) — Salesforce cannot package restriction rules in 2GP at all — and the Lightning page assignments for Opportunity and Trip. Add both to your install checklist.
• Post-upgrade checks: re-verify permission-set/group assignments, run a rollup recalculation if the data model changed, and scan Clientverse_Log__c for new errors.
• Stay synced. Treat _package-facts/ as the record of what each released version contains; re-run its sync on each release cut rather than editing the JSON by hand (sync-report.md).

---

13. Configuring Modules

The remaining sections apply only to orgs with the ClientVerse Modules add-on.

Configuring Dispatch

🧩 ClientVerse Modules — Dispatch Requires the ClientVerse Modules package. Clients on Core only won't see this.

Dispatch is ClientVerse's data-driven notification and digest engine: an admin defines a digest (who, what content, what schedule, what channel); a scheduled run evaluates it, creates one item per recipient, renders the content, and delivers it by email and/or in-app notification. It also powers ERM review workflows (single-threaded review, auto-promotion). Configure it from the CV_Dispatch_Setup app with the CV_Dispatch_Admin permission set. Full object/field reference: _package-facts/objects/dispatch.yaml.

Dispatch Definitions (Dispatch_Definition__c) are the central configuration record — everything else hangs off a Definition. Key settings (cite dispatch.yaml):

• Content: Primary_Object__c (the object the digest is built from), Entry_Criteria__c (which records qualify).
• Audience: Subscriber_Source__c (criteria / list / role) and Subscriber_Criteria__c.
• Branding & delivery: Email_Subject_Template__c, From_Name__c, From_Address__c, Reply_To__c, Enable_Reply_Routing__c, Use_External_MAP__c.
• ERM behavior: Auto_Promotion_Behavior__c, Review_Window_Hours__c.
• Activation: Active__c must be on for the definition to schedule.

Schedules. On each Definition set Frequency__c (Daily/Weekly/Monthly), Run_Times__c, Day_of_Week__c / Day_of_Month__c, and Timezone__c. Each execution creates a Dispatch_Run__c (status, records evaluated, items created/sent/failed) and one Dispatch_Run_Item__c per recipient (rendered subject/body, sent/opened/clicked timestamps) — your audit trail for a send.

Subscriptions (Dispatch_Subscription__c) enroll recipients, with per-subscriber overrides for channel (Delivery_Channel__c), cadence (Frequency_Override__c), and content filters (Filters_JSON__c). Subscriptions are created by auto-enrollment rules or by users subscribing. Role-based auto-enrollment is driven by Dispatch_Role_Mapping__mdt (map a role/type to a Definition — e.g. enroll all relationship managers in a given digest).

Sections & data tables. Compose a digest body from Dispatch_Section__c blocks (rich text or data table, each with Sort_Order__c, Visibility_Rule__c, Hide_If_Empty__c). A data-table section is defined by Dispatch_DataTable_Config__c (its Data_Source_Type__c — SOQL/report/list view/Apex — and Enable_Inline_Edit__c) and its columns by Dispatch_DataTable_Column__c. Call-to-action buttons are Dispatch_Action__c (each with a Log_Action_Type__c controlling what gets recorded).

Correction — there is no Dispatch_Action_Log__c. Earlier revisions of this guide described a separate action-log object. That object was removed before Modules 0.1.0 shipped and has never existed in a released package. Recipient actions and engagement are recorded on the Run Item itself (Dispatch_Run_Item__c) via Actions_Taken__c, alongside Opened_At__c, Clicked_At__c, View_Count__c, Reply_Count__c, and Reply_Received__c.

Daily email limits & throttling. Dispatch_Settings__c holds org-level Dispatch state — primarily the daily contact-email throttling counters and last reset date — backing the contact email-limit guardrail. Batch sizes (definition batch, run-item batch, insert chunk) are tuned in Dispatch_Config__mdt deploy-time metadata. Review the daily limit before launching a large-audience digest so sends aren't throttled mid-run.

Configuring Whitespace

🧩 ClientVerse Modules — Whitespace Requires the ClientVerse Modules package. Clients on Core only won't see this.

Whitespace identifies untapped revenue opportunities by scoring each account against practice areas the firm could serve but doesn't yet. A batch scores account/practice combinations on configurable factors, writes one WhiteSpace_Opportunity__c per gap (overall score + per-factor component scores + coverage status + recommended action), and optionally surfaces the top opportunities in a digest. Full reference: _package-facts/objects/whitespace.yaml. Whitespace 0.1 has no dedicated app — you administer it entirely through custom metadata:

• Scoring config (Whitespace_Scoring_Config__mdt) — the run's settings: Active__c (scoring on/off), Batch_Size__c, and the digest controls Send_Digest__c, Digest_Day_Of_Week__c, Digest_Hour__c, Top_Opportunity_Count__c.
• Weights (Whitespace_Score_Weight__mdt) — the max points each scoring factor contributes to the composite Opportunity_Score__c (Factor_Name__c, Max_Points__c, Active__c). Reweighting these changes how opportunities rank — e.g. raise Max_Points__c on revenue potential to surface bigger-dollar gaps first.
• Thresholds (Whitespace_Threshold__mdt) — per-practice hours thresholds (Active_Hours_Threshold__c, Partial_Hours_Threshold__c) that classify each opportunity's Coverage_Status__c as active vs. partial.

Digest schedule. When Send_Digest__c is on, the opportunity digest is emailed on Digest_Day_Of_Week__c at Digest_Hour__c, highlighting the top Top_Opportunity_Count__c opportunities. Tuning order: set thresholds and weights first, run/verify scoring, then enable the digest — so recipients see well-calibrated rankings on the first send.

Dependency on classification. Whitespace scores against practice areas, which come from the Core classification taxonomy (§8). Keep that taxonomy clean or scoring quality degrades.

Configuring AI

🧩 ClientVerse Modules — AI Requires the ClientVerse Modules package. Clients on Core only won't see this.

New in Modules 0.4.0. The AI area ships the CV AI Chat interface (CV_AI_Chat tab and FlexiPage, backed by CV_AI_Session__c and CV_AI_Session_Item__c) alongside the AI Actions framework. Configure it with CV_AI_Admin; CV_AI_User is the everyday set and CV_AI_Chat_User gates the chat interface itself.

• Action templates (CV_AI_Action_Template__mdt) define the AI actions available to flows and components.
• System prompt configuration (System_Prompt_Config__mdt) sets the instructions the assistant operates under.
• Adapter limits (AI_Adapter_Limit__mdt) cap usage against the underlying provider — set these before you widen access, not after.

Two things to understand before you enable this at all.

1. Firm data is sent to a third-party LLM provider. The chat calls Anthropic (Claude) or OpenAI (ChatGPT) through the CV_Anthropic / CV_OpenAI named credentials, selectable at runtime. Query results from the firm's CRM are included in those calls. For most law firms this is a decision for the general counsel or risk function, not the CRM administrator alone — confirm it is covered by the firm's AI and outside-counsel-guidelines position, and that the provider contract permits it, before assigning the permission set to anyone.

2. Record access is enforced; prompt injection is not fully mitigated. Queries run through the Core named-query framework in USER_MODE, so every row the model sees is scoped to the running user's CRUD, field-level security, and record sharing — the assistant genuinely cannot surface a record that user could not already open. Separately, because CRM values are fed back into the model, prompt injection hardening is explicitly incomplete at this stage: the system prompt instructs the model to treat retrieved data as untrusted, but that is a mitigation, not a guarantee. Weigh this against how much untrusted, externally-sourced text your CRM holds — contact notes and inbound descriptions are the realistic vector.

Read §14 before enabling this for anyone.

Configuring BI visualization

🧩 ClientVerse Modules — Analytics Requires the ClientVerse Modules package. Clients on Core only won't see this.

Also new in 0.4.0. Components embed Power BI and Tableau visualizations onto record pages, Lightning pages, and flows, each with a custom property editor so placement is configured in Lightning App Builder rather than coded. Connections are defined in CV_BI_Connection__mdt; access is granted by CV_BI_Visualization.

Setup order:

1. Define the connection in CV_BI_Connection__mdt.
2. Confirm the target dashboard's own access model in Power BI or Tableau — ClientVerse does not re-implement their permissions. A visualization embedded in ClientVerse is still governed by the BI tool, so a user who can see the ClientVerse page may or may not be able to render the dashboard inside it. Verify with a real non-admin account.
3. Place the component in App Builder and configure it through its property editor.
4. Assign CV_BI_Visualization to the intended audience.

---

14. Early access: AI and Analytics

Both new module areas in 0.4.0 ship inactive and are best treated as early access. This is deliberate: the package follows a "ship dark, enable selectively" model, so a capability being present in the package is not the same as it being ready for everyone.

Capability	Enable with	Engineering status
🧩 CV AI Chat	CV_AI_Chat_User	In QA
🧩 Power BI / Tableau embedding	CV_BI_Visualization	In progress

Neither is enabled for any user until you assign the permission set, and nothing else in the product depends on them — leaving both off is a fully supported configuration.

Before you roll out AI specifically, settle the third-party-provider question described in §13 — the chat sends CRM query results to Anthropic or OpenAI. That is a firm-policy decision, and it should be answered before the technical rollout starts, not during it.

If you do want to roll one out:

1. Enable in a sandbox first and set adapter limits (AI) or verify BI-tool access (Analytics) before anyone else sees it.
2. Give it to a named pilot group rather than a permission-set group, so you can withdraw it cleanly.
3. Agree what "working" means with the pilot group before you start, and check back before widening.
4. Watch Clientverse_Log__c during the pilot.

Because engineering still classes these as maturing, expect behaviour to change between releases more than it would for an established feature. Check each release's notes before upgrading an org where a pilot is running.

---

Unresolved facts

None outstanding.

Known product gaps an administrator should be aware of — these are tracked, not defects:

• Integrations have no automated test coverage. No integration test environment exists yet for MCAE, PMS/financial sync, the ERM feed, or DMS links. Validate these against your own data during implementation rather than assuming release testing covered them.
• Field-level descriptions are incomplete — 36% of Core fields and 11% of Modules fields carry a description in Setup. Object descriptions are effectively complete. See the annotation backlog.