ClientVerse Modules 0.4.0 — Configuration Reference¶
🧩 ClientVerse Modules Requires the ClientVerse Modules package. Clients on Core only won't see anything on this page.
The structural reference for ClientVerse Modules — the optional managed add-on
(namespace clientverse) that some clients license on top of Core. In 0.4.0 Modules ships
four capabilities: Dispatch (notifications/digests) and Whitespace
(revenue-opportunity scoring), both mature, plus AI (in-platform chat and AI Actions) and
Analytics (Power BI / Tableau embedding), both new in this release and shipped off by
default. A fifth area, General, is background automation with no objects or UI.
All counts and names are cited from
clientverse-modules-0.4.0.json and
catalog.json. Object meanings and key fields are
from the annotation catalog
objects/dispatch.yaml,
whitespace.yaml,
ai.yaml, and
analytics.yaml.
At a glance¶
| Metric | Value |
|---|---|
| Package type | Managed (2GP) |
| Version | 0.4.0 (ClientVerse Modules@0.4.0-2) |
| Namespace | clientverse |
| Custom objects | 21 |
| Objects extended | 3 (Activity, Clientverse_Log__c, CampaignMember) |
| Fields | 269 |
| Applications | 1 (CV_Dispatch_Setup) |
| Tabs | 11 |
| Permission sets | 11 |
| Apex classes | 184 |
| LWC bundles | 25 |
Source: clientverse-modules-0.4.0.json.
Dependency — this floor moved in 0.4.0. Modules 0.4.0 declares a dependency on
ClientVerse Core Unlocked@1.1.7-6, so Core 1.1.7 is the minimum. Modules 0.3.0 required only Core 1.1.4, which means an org running 0.3.0 without trouble can still be below the new floor. Upgrade Core before Modules; the reverse order fails the install. See../../_package-facts/sync-report.mdand the Implementation Guide.
Of the 21 custom objects: 11 belong to Dispatch, 5 to AI, 4 to Whitespace, and
1 to Analytics. (This reference previously listed 12 Dispatch objects, including a
Dispatch_Action_Log__c that was removed before 0.1.0 and never shipped.)
1. Dispatch — object reference (11 objects)¶
🧩 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 Dispatch_Definition__c (audience, content query, schedule, channel); a
scheduled run evaluates it, creates one Dispatch_Run_Item__c 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).
The tables below list each object's purpose and selected key fields from
dispatch.yaml. Key fields are a curated
subset — not the full field list. For all fields, see
catalog.json and the
Data Dictionary v3.0.
Configuration & subscription¶
| Object | Purpose | Key fields |
|---|---|---|
Dispatch_Definition__c |
The central config for one scheduled notification/digest: what it queries, who receives it, cadence, branding, delivery. Everything else hangs off it (48 fields total). | Active__c, Primary_Object__c, Entry_Criteria__c, Subscriber_Source__c, Subscriber_Criteria__c, Frequency__c, Run_Times__c, Day_of_Week__c, Day_of_Month__c, Timezone__c, Email_Subject_Template__c, From_Name__c, From_Address__c, Reply_To__c, Enable_Reply_Routing__c, Context_Mode__c, Use_External_MAP__c, Auto_Promotion_Behavior__c, Review_Window_Hours__c |
Dispatch_Subscription__c |
A recipient's enrollment in a Definition, with per-subscriber overrides (channel, frequency, send time, filters). | Dispatch_Definition__c, Subscriber__c, Subscriber_User__c, Subscriber_Contact__c, Delivery_Channel__c, Frequency_Override__c, Filters_JSON__c, Is_Active__c, Assignment_Source__c, Unsubscribed_Date__c |
Content composition¶
| Object | Purpose | Key fields |
|---|---|---|
Dispatch_Section__c |
A content block within a digest (rich text or data table), with its own visibility rule and ordering. | Dispatch_Definition__c, Section_Type__c, Sort_Order__c, Visibility_Rule__c, Hide_If_Empty__c |
Dispatch_DataTable_Config__c |
Defines a tabular section: data source (SOQL/report/list view/Apex), row limit, sort, inline-edit. | Section__c, Data_Source_Type__c, SOQL_Template__c, Object_API_Name__c, Enable_Inline_Edit__c |
Dispatch_DataTable_Column__c |
One column in a data-table section: field, label, formatting, alignment, width, highlight rule. | DataTable_Config__c, Field_API_Name__c, Format_Type__c, Highlight_Rule__c |
Dispatch_Action__c |
A call-to-action button on a digest/notification (run a flow, open a URL, update a record), with placement and visibility. | Dispatch_Definition__c, Action_Type__c, Flow_API_Name__c, Visibility_Condition__c |
Execution & audit¶
| Object | Purpose | Key fields |
|---|---|---|
Dispatch_Run__c |
One execution of a Definition. Records what was evaluated and how many items were created/sent/failed, plus an error summary. | Dispatch_Definition__c, Run_Type__c, Status__c, Records_Evaluated__c, Items_Created__c, Items_Sent__c, Items_Failed__c, Error_Summary__c |
Dispatch_Run_Item__c |
One rendered, addressed message for a single recipient: rendered subject/body, delivery + engagement timestamps, links back to Run and Subscription. | Run__c, Subscription__c, Recipient_Email__c, Rendered_Subject__c, Rendered_Body__c, Status__c, Sent_At__c, Opened_At__c, Clicked_At__c, Reply_Received__c, Skip_Reason__c |
Dispatch_Settings__c |
Org-level Dispatch state — primarily daily contact-email throttling counters and last reset date. Backs the contact-email-limit guardrail. | (org-level throttle state) |
Settings (custom metadata)¶
These two __mdt types are deploy-time configuration, not per-record data.
| Object | Purpose | Key fields |
|---|---|---|
Dispatch_Config__mdt |
Tunable batch sizes for Dispatch processing (definition batch, run-item batch, insert chunk). | batch-size settings |
Dispatch_Role_Mapping__mdt |
Maps a role/type to a Definition for role-based auto-enrollment (e.g. enroll all relationship managers in a given digest). | role → definition mapping |
2. Whitespace — object & scoring-settings reference (4 objects)¶
🧩 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 (client tier, peer coverage, relationship strength,
revenue potential), surfaces the top opportunities in a digest, and lets users act on
coverage gaps. Whitespace consumes Core Time_Entry__c data for coverage analysis.
Source: whitespace.yaml.
Scored output¶
| Object | Purpose | Key fields |
|---|---|---|
WhiteSpace_Opportunity__c |
A scored account/practice-area coverage gap — one record per opportunity, with overall + per-factor scores, coverage status, and a recommended action. This is what the dashboard and digest present. | Account__c, Practice_Area__c, Opportunity_Score__c, Score_Client_Tier__c, Score_Peer_Coverage__c, Score_Relationship_Strength__c, Score_Revenue_Potential__c, Coverage_Status__c, Coverage_Lapse__c, Recommended_Action__c, RM_Owner__c, Last_Scored_Date__c |
Scoring settings (custom metadata)¶
The three __mdt types below tune the scoring run. They are deploy-time
configuration.
| Object | Purpose | Key fields |
|---|---|---|
Whitespace_Scoring_Config__mdt |
The scoring run's settings: batch size, whether/when to send the digest (day + hour), and how many top opportunities to surface. | Active__c, Batch_Size__c, Send_Digest__c, Digest_Day_Of_Week__c, Digest_Hour__c, Top_Opportunity_Count__c |
Whitespace_Score_Weight__mdt |
The weight (max points) each scoring factor contributes to the composite Opportunity Score. Tuning these reweights how opportunities rank. | Factor_Name__c, Max_Points__c, Active__c |
Whitespace_Threshold__mdt |
Per-practice hours thresholds that classify coverage as active vs. partial — drives Coverage_Status__c. |
Practice_API_Name__c, Active_Hours_Threshold__c, Partial_Hours_Threshold__c |
3. AI — object reference (5 objects) — early access¶
🧩 ClientVerse Modules — AI Requires the ClientVerse Modules package. Clients on Core only won't see this.
New in 0.4.0, and this supersedes the 0.3.0 note that called AI foundation-only. The module
now ships the CV AI Chat interface (a CV_AI_Chat tab and FlexiPage, 3 LWCs) and the AI
Actions framework, across 5 objects and 5 permission sets.
It is off until you assign a permission set, and engineering still tracks the chat as maturing — treat it as early access rather than a settled feature.
| Object | Purpose | Key fields |
|---|---|---|
CV_AI_Session__c |
One conversation, owned by the running user. Records provider, model, context record and token spend — which is what makes usage reportable per user rather than only in the provider's console. | CV_User__c, CV_Provider__c, CV_Model__c, CV_Context_Record_Id__c, CV_Status__c, CV_Total_Tokens__c |
CV_AI_Session_Item__c |
One turn in a session — a user message, a model response, or a tool call and its result. The auditable record of what the assistant actually did. | CV_Session__c, CV_Sequence__c, CV_Role__c, CV_Item_Type__c, CV_Tool_Name__c, CV_Tool_Call_Json__c |
CV_AI_Action_Template__mdt |
A reusable AI action defined once and invoked from flows or components: instructions, provider/model, the named queries it may call, target objects, and governance limits. | CV_Instructions__c, CV_Named_Query_Names__c, CV_Target_Objects__c, CV_Require_Permission__c, CV_Max_Tokens__c, CV_Temperature__c, CV_Output_Contract__c, CV_Is_Active__c |
System_Prompt_Config__mdt |
The standing instructions the assistant operates under — including the instruction to treat tool data as untrusted. | Instructions__c |
AI_Adapter_Limit__mdt |
Per-provider usage cap. Set before widening access, not after. | AI_Adapter__c, API_Limit__c |
Two facts govern how you configure this.
Record access is enforced. Tool 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 cannot reach a record the user could not open —CV_AI_Chat_Userchanges how someone reaches their data, not which data they can reach.Firm data is sent to a third-party provider. Queries and their results go to Anthropic or OpenAI via the
CV_Anthropic/CV_OpenAInamed credentials, and prompt-injection hardening is explicitly incomplete at this stage. For a law firm this is a general-counsel or risk decision, not a configuration step — settle it before assigning the permission set.
Source: ai.yaml.
3a. Analytics — object reference (1 object) — early access¶
🧩 ClientVerse Modules — Analytics Requires the ClientVerse Modules package. Clients on Core only won't see this.
New in 0.4.0, superseding the 0.3.0 note that recorded analytics as not present. Six LWCs
embed Tableau views and Power BI reports into ClientVerse screen flows and Lightning pages, with
record context passed in as filters through a custom property editor. Gated behind
CV_BI_Visualization.
| Object | Purpose | Key fields |
|---|---|---|
CV_BI_Connection__mdt |
One registered BI environment — platform, base URL, and how a viewer is identified to it. Also the embed host allowlist: content whose host does not match an active connection is refused, so registering a connection is a security decision. | Platform__c, Base_URL__c, Is_Active__c, User_Identity_Source__c, Connected_App_Client_Id__c, Secret_Key_Name__c, Tableau_Site__c, Entra_Tenant_Id__c |
BI-tool permissions still apply. Tableau authenticates via a Connected App JWT minted server-side for the running user; Power BI rides the viewer's existing Microsoft Entra session. ClientVerse does not re-implement either platform's permissions or row-level security, so a user who can open the ClientVerse page may still be unable to render the dashboard inside it. Verify with a real non-admin account. Secrets live in Key Vault metadata and are never sent to the client.
Source: analytics.yaml.
4. Objects Modules extends¶
Modules 0.4.0 does not only add new objects — it extends three objects it does not own
(adds fields). These remain Core or standard Salesforce objects; the added fields are why their
behavior changes when Modules is installed. CampaignMember is new in 0.4.0.
| Object | Extended by | What the extension adds |
|---|---|---|
Activity |
Dispatch | A Dispatch_Run_Item__c lookup so tasks/events can link back to the digest that created them. |
Clientverse_Log__c |
Dispatch | Action__c / Run_Item__c fields so Dispatch activity surfaces in the Core logging object. |
CampaignMember |
Whitespace | Fields added to the standard object — new in 0.4.0. |
Source: extends_objects in
clientverse-modules-0.4.0.json and
the extends: blocks in
dispatch.yaml and
whitespace.yaml.
5. Application & permission sets¶
Application (1)¶
| Application (developer name) | Purpose |
|---|---|
CV_Dispatch_Setup |
Admin setup app for configuring Dispatch definitions, sections, and delivery. |
Permission sets (11)¶
Up from 3 in 0.3.0, following the same Schema Access / User / Admin tiering Core adopted in
1.1.7. CV_Modules_Access is the prerequisite for everything else.
| Permission set (API name) | Grants |
|---|---|
CV_Modules_Access |
Baseline access to Modules components — required before any set below works. |
CV_Dispatch_Schema_Access |
Visibility of the Dispatch objects, without component access. |
CV_Dispatch_User |
Recipient/end-user access — subscribe to and act on digests. |
CV_Dispatch_Lawyer |
The pre-1.1.7 end-user set, retained for continuity — equivalent to CV_Dispatch_User. |
CV_Dispatch_Admin |
Administer Dispatch — create/edit definitions, sections, actions; view runs and logs. |
CV_AI_Schema_Access |
Visibility of the AI session objects. |
CV_AI_User |
Everyday AI capability. |
CV_AI_Chat_User |
The switch for CV AI Chat — the interface is invisible without it. |
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. |
Source: applications and permission_sets in
clientverse-modules-0.4.0.json. For
how these map to roles and how they layer onto Core groups, see the
Admin Guide.
Note — Whitespace still has no dedicated permission set. Whitespace access is governed via Core access plus the scoring configuration. This was an open question in 0.3.0 and remains one in 0.4.0; confirm the intended Whitespace access model during implementation.
6. Field-level detail → Data Dictionary v3.0¶
As with Core, this page is structural. For any field on any Modules object — type,
picklist values, formula, data source — use the canonical
Data Dictionary v3.0. Full field lists per object are in
catalog.json; authored meanings and key fields are
in dispatch.yaml,
whitespace.yaml, and
ai.yaml.
Unresolved facts¶
- Whitespace access model: still no dedicated Whitespace permission set in 0.4.0 — access is governed via Core plus the scoring configuration. Carried over unresolved from 0.3.0; confirm how Whitespace visibility is intended to be granted.
CV_Dispatch_LawyervsCV_Dispatch_User: both ship, and they appear equivalent. Confirm whetherCV_Dispatch_Lawyeris deprecated and which one new orgs should be assigned.
Resolved since 0.3.0: the "AI status" item is closed — AI ships in 0.4.0 (§3). It is early access and off by default, but it is no longer roadmap-only.