ClientVerse Modules 0.8.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.8.0 Modules ships
five capabilities: Dispatch (notifications/digests) and Whitespace
(revenue-opportunity scoring), both mature; AI (in-platform chat and AI Actions, added in
0.4.0, plus AI Email Ingestion and AI Data Cleansing, new in 0.8.0); Analytics
(Power BI / Tableau embedding, added in 0.4.0); and Event Check-In (new in 0.8.0). The AI
features and Analytics ship off by default. A further area, General, is background
automation with no objects or UI.
All counts and names are cited from
clientverse-modules-0.8.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. The objects new in 0.8.0 are not
in the annotation catalog yet; their descriptions here come from the
Core 1.1.10 · Modules 0.8.0 release notes
and the package metadata.
At a glance¶
| Metric | Value |
|---|---|
| Package type | Managed (2GP) |
| Version | 0.8.0 (ClientVerse Modules@0.8.0-1) |
| Namespace | clientverse |
| Custom objects | 31 |
| Objects extended | 4 (Activity, CampaignMember, Clientverse_Log__c, User) |
| Fields | 384 |
| Applications | 1 (CV_Dispatch_Setup) |
| Tabs | 13 |
| Permission sets | 20 |
| Permission-set groups | 3 |
| Apex classes | 310 |
| LWC bundles | 32 |
Source: clientverse-modules-0.8.0.json,
except the permission-set-group count, which the facts sync doesn't collect for Modules yet; it
is from the inventory in the
release notes.
Dependency. Modules 0.8.0 declares a dependency on
ClientVerse Core Unlocked@1.1.10-2, so Core 1.1.10 is the minimum. An org running Modules 0.4.0 on Core 1.1.7 is below this floor. Upgrade Core before Modules; the reverse order fails the install. (Modules 0.7.0 was built but never released; 0.8.0 is that release with two packaging fixes.) See../../_package-facts/sync-report.mdand the Implementation Guide.
Of the 31 custom objects: 13 belong to AI, 12 to Dispatch, 5 to Whitespace, and
1 to Analytics. Event Check-In and General own none. (An earlier version of this reference
counted a Dispatch_Action_Log__c that was removed before 0.1.0 and never shipped. The twelfth
Dispatch object in 0.8.0 is ERM_Privacy_Preference__c, which is new.)
1. Dispatch — object reference (12 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 (52 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. From 0.8.0 a column can also group rows (Group By, one column or several nested) or carry a magic-link action button that lets a reviewer act from the email without logging in. | DataTable_Config__c, Field_API_Name__c, Format_Type__c, Highlight_Rule__c, Is_Group_By__c, Group_By_Order__c, Magic_Link_Policy_Key__c, Button_Label__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) |
ERM privacy¶
New in 0.8.0. Not yet in the annotation catalog; the purpose below is from the package metadata.
| Object | Purpose | Key fields |
|---|---|---|
ERM_Privacy_Preference__c |
A lawyer's exclusion from ERM capture: an email address, person, thread or domain whose signals must not enter the CRM. Checked, with the lawyer's User.ERM_Capture_Enabled__c switch (see §4), before inbound ERM data is written. |
Lawyer__c, Contact__c, Scope__c, Match_Key__c, Match_Value__c, Status__c, Effective_Date__c, Revoked_Date__c, Retroactive_Applied__c |
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 (5 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.
In 0.8.0 the whitespace heatmap (cvWhitespaceHeatmap) also shows plan coverage, a three-year
trend and a grid scoped to one plan, and can be added to any record page in Lightning App
Builder (on objects other than Account and Business Plan it shows the firm-wide view). It isn't
placed on a page by default.
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 four __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 |
Whitespace_Tier_Score__mdt |
New in 0.8.0. The points each Client Tier value scores, so the tier ranking is configuration rather than code and a firm can use its own tier names. Not yet in the annotation catalog; purpose from the package metadata. | Tier_Value__c, Points__c, Active__c |
3. AI — object reference (13 objects)¶
🧩 ClientVerse Modules — AI Requires the ClientVerse Modules package. Clients on Core only won't see this.
AI chat and AI Actions were added in 0.4.0, superseding the 0.3.0 note that called AI
foundation-only: the CV AI Chat interface (a CV_AI_Chat tab and FlexiPage) and the AI
Actions framework, across 5 objects and 5 permission sets. 0.8.0 adds AI Email Ingestion
and AI Data Cleansing, plus groundwork for firm-level field aliases. In 0.8.0 the AI module
has 13 objects, 3 tabs, 4 LWC bundles and 8 permission sets.
AI chat and AI Actions (early access)¶
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. AI Email Ingestion and AI Data Cleansing (below) send firm data to the configured provider too: the forwarded email, and the record values being assessed.
Source: ai.yaml.
AI Email Ingestion (new in 0.8.0)¶
A lawyer forwards an email to a firm address. AI classifies it, matches real Contacts and
Accounts, and proposes a Task or Event for a person to confirm. It never creates an Opportunity
itself, and it ships switched off: turn on Email_Intake_Setting.Default.Is_Active__c
last, after the rest of the setup in the
release notes. Intake also adds an
Email_Intake__c lookup to Activity (§4).
| Object | Purpose | Key fields |
|---|---|---|
Email_Intake__c |
One forwarded email: who submitted it, sender, subject, body, the Contact and Account it was matched to, and its processing status. | Submitted_By__c, From_Address__c, Subject__c, Received_Date__c, Matched_Contact__c, Matched_Account__c, Status__c, Body_Sent_To_Model__c, AI_Session__c |
Email_Intake_Proposal__c |
The Task or Event the AI proposes from an intake email, waiting for a person to confirm it. | Email_Intake__c, Target_Object__c, Proposed_Fields__c, Proposed_Owner__c, Related_Contact__c, Related_Account__c, Confidence__c, Rationale__c, Status__c, Converted_Activity_Id__c |
Email_Intake_Setting__mdt |
Intake settings: the on/off switch, the AI action template, the provider credential, how many candidate Contacts and Accounts to match against, and the public email domains list. | Is_Active__c, Template_API_Name__c, External_Credential_Name__c, Max_Candidate_Contacts__c, Max_Candidate_Accounts__c, Public_Email_Domains__c |
AI Data Cleansing (new in 0.8.0)¶
AI suggests fixes to casing, phone formats and abbreviations, and fills empty Account and
Contact fields. Each suggestion is staged for a steward to accept or reject; applying
suggestions automatically is blocked by three separate settings. To use it, assign the
CV_AI_Cleansing_* permission sets, turn on AI_Cleansing_Setting__mdt, schedule
AICleansingScheduler and configure the AI provider credential.
| Object | Purpose | Key fields |
|---|---|---|
AI_Cleansing_Proposal__c |
One suggested change to one field on one record — current and proposed value, confidence and rationale — staged for a steward to accept or reject. A change someone has rejected isn't proposed again. | Object_API_Name__c, Record_Id__c, Field_API_Name__c, Current_Value__c, Proposed_Value__c, Change_Type__c, Confidence__c, Confidence_Band__c, Rationale__c, Status__c |
AI_Cleansing_Action__mdt |
Per-action behaviour for a cleansing template: which records are worth assessing, and which fields the action may write. | Action_Template__c, Candidate_Filter__c, Target_Fields__c, Is_Active__c |
AI_Cleansing_Setting__mdt |
The on/off switch for cleansing, plus the provider credential, records per run and chunk size. | Is_Enabled__c, External_Credential_Name__c, Max_Records_Per_Run__c, Chunk_Size__c |
AI_Cleansing_Threshold__mdt |
Confidence thresholds by object, field and change type: the minimum to stage a change for review, the minimum to apply it automatically, or never apply it automatically. A threshold can make automatic apply harder to reach, never easier. | Object_API_Name__c, Field_API_Name__c, Change_Type__c, Review_Min__c, Auto_Apply_Min__c, Never_Auto_Apply__c, Is_Active__c |
Groundwork: field aliases (new in 0.8.0)¶
This ships in 0.8.0, but a user can't reach it yet.
| Object | Purpose | Key fields |
|---|---|---|
CV_Semantic_Field__mdt |
Binds a business concept the assistant hears in plain English, such as relationship strength, to the field that carries it at the firm and that field's value range. Groundwork for firm-level field aliases in AI chat. | CV_Concept__c, CV_Object__c, CV_Field__c, CV_Relationship_Name__c, CV_Value_Kind__c, CV_Value_Min__c, CV_Value_Max__c, CV_Is_Active__c |
The 0.8.0 AI objects are not yet in the annotation catalog. Their descriptions come from the release notes and the package metadata.
3a. Analytics — object reference (1 object) — early access¶
🧩 ClientVerse Modules — Analytics Requires the ClientVerse Modules package. Clients on Core only won't see this.
Added 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.
3b. Event Check-In (no objects of its own)¶
🧩 ClientVerse Modules — Event Check-In Requires the ClientVerse Modules package. Clients on Core only won't see this.
New in 0.8.0. A staff console on the Campaign (roster, search, tap to check in, guest count and CLE check-out), a self-service kiosk, de-duplication of walk-ins, an email to the sponsor when a guest arrives, and Close Attendance, which marks no-shows.
Event Check-In owns no objects. It adds check-in fields to CampaignMember
(§4) and ships five permission sets and three permission-set groups
(§5). None of its three components
(cvEventCheckInConsole, cvEventCheckInKiosk, cvEventCloseAttendance) is placed on a page;
the setup is in the release notes.
4. Objects Modules extends¶
Modules 0.8.0 does not only add new objects — it extends four 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. User is new in 0.8.0, and 0.8.0 adds fields to
Activity and CampaignMember.
| Object | Extended by | What the extension adds |
|---|---|---|
Activity |
Dispatch, AI | A Dispatch_Run_Item__c lookup so tasks/events can link back to the digest that created them. New in 0.8.0: an Email_Intake__c lookup (AI Email Ingestion) and Opportunity_Signal__c / Opportunity_Signal_Score__c. |
Clientverse_Log__c |
Dispatch | Action__c / Run_Item__c fields so Dispatch activity surfaces in the Core logging object. |
CampaignMember |
Whitespace, Event Check-In | Whitespace fields (Opportunity_Score__c, Practice_Area__c, Whitespace_Opportunity__c), added in 0.4.0. New in 0.8.0: the Event Check-In fields — Checked_In_At__c, Checked_In_By__c, Check_In_Method__c, Check_In_Notes__c, Guests_Attended__c, Checked_Out_At__c, Attendance_Minutes__c, Sponsor_Alert_Sent__c. |
User |
Dispatch | New in 0.8.0. ERM_Capture_Enabled__c, the per-lawyer switch for ERM capture (off by default), checked with ERM_Privacy_Preference__c (§1); and ERM_Privacy_Region__c. |
Source: extends_objects in
clientverse-modules-0.8.0.json and the
field lists in catalog.json; for the 0.4.0 extensions,
also 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 (20)¶
Up from 11 in 0.4.0 (and 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 the Dispatch, AI and
Analytics sets carried over from 0.4.0. The Event Check-In kiosk user gets only
CV_Event_Check_In_Kiosk_Access and nothing else (see
Permission-set groups).
| Permission set (API name) | Grants |
|---|---|
CV_Modules_Access |
Baseline access to Modules components — required before the Dispatch, AI and Analytics sets carried over from 0.4.0 work. |
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_ERM_Magic_Link_Guest |
For the guest user of the ERM Experience site, so a reviewer can act on a digest's magic-link action without logging in. Assign alongside Core's CV_Magic_Link_Guest. New in 0.8.0. |
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_AI_Cleansing_Schema_Access |
The AI Data Cleansing data model: AI_Cleansing_Proposal__c and the threshold configuration. Pair with CV_AI_Cleansing_User. New in 0.8.0. |
CV_AI_Cleansing_User |
Reviewing staged cleansing proposals: accept or reject. Does not run sweeps. New in 0.8.0. |
CV_AI_Cleansing_Admin |
Launching cleansing sweeps, and seeing every proposal rather than only those shared with you. Assigned on top of the schema and user sets, never alone. New in 0.8.0. |
CV_BI_Visualization |
The switch for Power BI / Tableau embedding. |
CV_Event_Check_In_Schema_Access |
Field access for the Campaign Member, Campaign, Contact and notification fields check-in uses. New in 0.8.0. |
CV_Event_Check_In_User |
The staff check-in console and the kiosk. Pair with CV_Event_Check_In_Schema_Access. New in 0.8.0. |
CV_Event_Check_In_Admin |
Closing out attendance after an event. Assigned on top of the schema and user sets, never alone. New in 0.8.0. |
CV_Event_Check_In_Kiosk_Schema_Access |
Kiosk-only access: read-only Campaign, Contact and Lead, plus check-in write-back on Campaign Member. New in 0.8.0. |
CV_Event_Check_In_Kiosk |
The kiosk component only, for the shared, unattended kiosk user. New in 0.8.0. |
Source: applications and permission_sets in
clientverse-modules-0.8.0.json. For
how these map to roles and how they layer onto Core groups, see the
Admin Guide.
Permission-set groups (3)¶
New in 0.8.0, and all three are for Event Check-In. Modules shipped no permission-set groups before 0.8.0.
| Permission-set group (API name) | Typical role |
|---|---|
CV_Event_Check_In_User_Access |
Event coordinators running in-person check-in: CV_Event_Check_In_Schema_Access + CV_Event_Check_In_User. |
CV_Event_Check_In_Admin_Access |
Coordinators who also close out attendance: the user group's sets + CV_Event_Check_In_Admin. |
CV_Event_Check_In_Kiosk_Access |
The shared kiosk user, on a Minimum Access profile with nothing else assigned: CV_Event_Check_In_Kiosk_Schema_Access + CV_Event_Check_In_Kiosk. |
Source: the Event Check-In setup in the release notes and the group definitions in the 0.8.0 package. The facts sync doesn't list Modules permission-set groups yet.
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.8.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,
ai.yaml, and
analytics.yaml. The objects new in 0.8.0 are
not in those files yet.
Unresolved facts¶
- Whitespace access model: still no dedicated Whitespace permission set in 0.8.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.- 0.8.0 objects not annotated: the objects new in 0.8.0 (AI Email Ingestion, AI Data
Cleansing,
CV_Semantic_Field__mdt,ERM_Privacy_Preference__c,Whitespace_Tier_Score__mdt) are not in the annotation catalog yet, so their descriptions here come from the release notes and package metadata rather than authored annotations. - Modules permission-set groups: the facts sync doesn't collect them yet, so the three Event Check-In groups are cited from the release notes rather than the facts JSON.
Resolved since 0.3.0: the "AI status" item is closed — AI shipped in 0.4.0 (§3). It is early access and off by default, but it is no longer roadmap-only.