ClientVerse Core 1.1.7 — Configuration Reference¶

The structural reference for ClientVerse Core — the unlocked package (namespace clientverse) that every client has. This page inventories what Core ships: its objects grouped by function, its applications, and its security building blocks. For field-level detail, follow the links into the Data Dictionary v3.0 — this page summarizes by group and does not reproduce every field.

All counts and names below are cited from clientverse-core-1.1.7.json and catalog.json. Object meanings are from the annotation catalog objects/core-key.yaml.

At a glance¶

Metric	Value
Package type	Unlocked (2GP)
Version	1.1.7 (`ClientVerse Core Unlocked@1.1.7-6`)
Namespace	`clientverse`
Objects owned	148
Standard objects extended	13
Fields	2,457
Applications	6
Permission sets	66
Permission-set groups	8
Record types	35 · Tabs
Apex classes	708 · Triggers

Source: clientverse-core-1.1.7.json. The 148 owned objects break down (by kind in catalog.json) into 106 custom objects, 38 custom metadata types, and 4 platform events. Separately, Core adds fields to 13 standard Salesforce objects (Account, Contact, Opportunity, Campaign, Lead, Case, Task, Event, User and others) — these are extended, not owned, which matters when you are reasoning about field-level security or an upgrade's blast radius.

A counting correction. Through 1.1.6 this page reported "146 objects" without separating owned from extended, so standard objects the package merely adds fields to were counted as shipped objects. The split above is the corrected form.

1. Object inventory by functional group¶

The custom + standard objects are grouped below by what they do. Counts are indicative groupings to aid navigation, not a packaging boundary — the authoritative package/kind/field facts are in catalog.json. For any field, open the named object in the Data Dictionary v3.0.

Configuration objects (38 custom metadata types, 4 platform events) are listed separately in §2.

Clients, Contacts & Relationships¶

Core CRM entities and the relationship graph between firm people and external contacts.

Representative objects	Notes
`Account`, `Contact`, `AccountContactRelation`, `Related_Company__c`, `Client_Address__c`, `Key_Contact__c`	`Account` (174 fields) and `Contact` (143) are the largest standard objects; both are extended heavily with Core fields.
`Connection__c`, `Collaborator__c`, `Touchpoint__c`, `Touchpoint_Summary__c`, `Competitor__c`, `Cohort_Member__c`	`Connection__c` (34 fields) is the ERM relationship signal — "who knows whom". `Collaborator__c` underpins team sharing.

~12 objects. See Connection__c, Collaborator__c in core-key.yaml.

Matters & Financials¶

The "work" the firm performs and the money attached to it. Sourced from the practice management system (PMS).

Representative objects	Notes
`Matter__c`, `Matter_Group__c`, `Matter_Party__c`, `Court_Case__c`, `Case_Party__c`, `Judge__c`	`Matter__c` (84 fields) is the central work entity.
`Time_Entry__c`, `Timekeeper__c`, `Timekeeper_Summary__c`, `Financial_Summary__c`, `Invoice__c`, `Allocation__c`	`Time_Entry__c` (29) and `Timekeeper_Summary__c` (32) feed financial rollups; also consumed by Whitespace (Modules).

~12 objects.

Experience¶

Described instances of the firm's work, captured for reuse in pitches and directories — the richest part of the model.

Representative objects	Notes
`Experience__c`, `Experience_Holder__c`, `Experience_Party__c`, `Experience_Narrative__c`	`Experience__c` (90 fields) is the largest custom object. `Experience_Holder__c` links a lawyer to an Experience and their role.
`Professional_Profile__c`, `Education__c`, `Work_History__c`, `Recognition__c`, `Author__c`	Profile/credential records assembled into individual experience profiles. `Professional_Profile__c` has 35 fields.

~9 objects. See Experience__c, Experience_Holder__c in core-key.yaml.

Classification (taxonomy)¶

The firm taxonomy (practice areas, industries, regions) and the engine that assigns it to records.

Representative objects	Notes
`Classification__c`, `Classification_Assignment__c`, `Classification_Description__c`, `Classification_Mapping__c`	`Classification_Assignment__c` (40 fields) is the join that makes the taxonomy actionable — it can target almost any object.
`Classification_Assignment_Rule__c`, `Classification_Assignment_Rule_Item__c`, `Classification_Assignment_History__c`, `Classification_Saved_Search__c`	The rules engine plus its change history.

~8 objects. See Classification__c, Classification_Assignment__c in core-key.yaml.

Lists & Search (List Builder)¶

Curated/rule-driven audiences and the saved-search infrastructure that feeds campaigns and dispatches.

Representative objects	Notes
`List__c`, `List_Member__c`, `List_Change__c`, `List_Builder_Config__c`, `Source_List__c`	`List__c` and `List_Member__c` are the List Builder core; static and dynamic lists. `Audit_Log_Import__c` was retired in 1.1.7 — bulk-job tracking consolidated onto `Clientverse_Log__c`.
`Saved_Search__c`, `Search_Component_Config__c`, `View_Share_Config__c`	`Saved_Search__c` (14) drives re-runnable searches that can feed lists and dispatches.

~9 objects. See List__c, List_Member__c, Saved_Search__c in core-key.yaml.

Collaboration (Walls)¶

Team collaboration spaces with role-based membership and sharing.

Representative objects	Notes
`Wall__c`, `Wall_Member__c`, `Wall_Sharing__c`, `Group_Member__c`, `Private_Record__c`	`Wall__c` is the collaboration space; membership and sharing are split into their own objects. Gated by `Wall_Permitted_User`.

~5 objects.

Business Development¶

BD planning: trips, pitches/proposals, plans, panels, referrals, and strategic intelligence.

Representative objects	Notes
`Trip__c`, `Trip_Leg__c`, `Trip_Target__c`, `Trip_Participant__c`, `Trip_Business_Plan__c`	`Trip__c` anchors BD trip planning; `Trip_Target__c` (15) holds the prospects/targets per leg.
`Pitch_Proposal_Builder__c`, `Pitch_Element__c`, `Panel__c`, `Plan_Objective__c`, `Plan_Appendix__c`, `Business_Plan__c`	Pitch/proposal assembly from reusable elements; plans and panel-counsel arrangements.
`Referral__c`, `Referral_Contact__c`, `Target_Client__c`, `Strategic_Intelligence__c`, `Intelligence_Asset__c`, `Opportunity`, `Opportunity_Competitor__c`, `OpportunityTeamMember`, `Lead`	Pipeline, referrals, and captured client intelligence. `Opportunity` (42) and `Lead` (63) are standard objects extended for the firm.

~20 objects. See Trip__c, Pitch_Proposal_Builder__c, Referral__c, Strategic_Intelligence__c, Intelligence_Asset__c in core-key.yaml.

Marketing, Campaigns & Content¶

Campaign execution, budgets, and the firm content library.

Representative objects	Notes
`Campaign`, `CampaignMember`, `Marketing_Asset__c`, `Venue__c`	`Campaign` (62) and `CampaignMember` (22) are standard objects extended for events/sends.
`Firm_Content__c`, `CV_Content__c`, `CV_Content_Send__c`	The content library and its send tracking. `Firm_Content__c` (15).
`Budget__c`, `Budget_Allocation__c`, `Budget_Category__c`, `Budget_Classification__c`, `Actual_Spend__c`	Marketing budgeting and spend tracking.

~12 objects. See Firm_Content__c in core-key.yaml.

Platform, Logging & Support¶

Cross-cutting platform objects: logging, support cases, FAQs, rollups, notifications, training, and framework scaffolding.

Representative objects	Notes
`Clientverse_Log__c`, `Case`, `FAQ__c`, `Notification_Request__c`, `Notification_Template__c`	`Clientverse_Log__c` (14) is the central logging object (also extended by Modules — see Modules).
`Rollup_Definition__c`, `Rollup_Filter__c`, `Company_Profile__c`, `Module_User__c`	Declarative rollups admins configure; `Rollup_Definition__c` (13) + `Rollup_Filter__c`.
`Course__c`, `Learning_Module__c`, `Training_Offering__c`, `Task`, `Activity`, `Event`, `User`, `Job_Posting__c`, `Project__c`, `Project_Team_Member__c`, `Task_Template__c`, `di_Configurations__c`	Training, task/activity (also extended by Modules), and platform scaffolding.

~22 objects.

Group totals are approximate and exist only to organize this page. The exact set, package, kind, and field count for every object are authoritative in catalog.json.

2. Configuration objects (custom metadata & platform events)¶

Core ships 27 custom metadata types (deploy-time configuration, __mdt) and 3 platform events (__e). These are configuration/infrastructure, not per-record business data.

Custom metadata types (21)¶

Area	Types
Apex framework (fflib bindings)	`ApplicationFactory_DomainBinding__mdt`, `ApplicationFactory_SelectorBinding__mdt`, `ApplicationFactory_ServiceBinding__mdt`, `ApplicationFactory_UnitOfWorkBinding__mdt`, `DomainProcessBinding__mdt`, `SelectorConfig_FieldSetInclusion__mdt`, `di_Binding__mdt`
Classification	`CV_Classification_Trigger_Config__mdt`, `Classification_Picker_Mapping__mdt`
Experience search	`Experience_Search_Objects__mdt`, `Experience_Search_Object_Config__mdt`, `Experience_Search_Object_Field_Facet__mdt`, `Facets_Config_Setting__mdt`, `Hover_Field__mdt`
Collaboration / scoring / naming	`Collaborator_Field_Mappings__mdt`, `Engagement_Score_Weight__mdt`, `Object_Naming_Rule__mdt`
Notifications / platform	`Notification_Template_Config__mdt`, `PlatformEvents_Subscription__mdt`, `Key_Vault__mdt`, `TestDataSupplementer__mdt`

Platform events (3)¶

AT4DXImmediateMessage__e, AT4DXMessage__e, Notification_Event__e — the eventing backbone (AT4DX messaging framework + ClientVerse notifications).

Full field lists for any of these are in catalog.json.

3. Applications (6)¶

Core ships 6 Lightning applications. Which app a user lands in is driven by their permission-set assignment (§4).

Application (developer name)	Audience
`CV_Lawyer`	Attorneys — day-to-day client, matter, and relationship work.
`CV_BD`	Business development — pipeline, trips, pitches, intelligence.
`CV_Marketing`	Marketing — campaigns, lists, content, budgets.
`CV_Experience`	Experience management — capturing and reusing the firm's work.
`CV_Intelligence`	Client/strategic intelligence and analytics surfaces.
`CV_Admin`	Administration — configuration, classification, rollups, logging.

Source: applications in clientverse-core-1.1.7.json.

4. Permission sets & groups¶

Core ships 66 permission sets and 8 permission-set groups — up from 24 and 6 in 1.1.6. For the role → access mapping and the assignment workflow (groups vs. individual sets, muting), see the Admin Guide §4–5 and the Security Architecture.

The 1.1.7 restructure was additive. Every set that existed in 1.1.6 is still present, so no assignment broke on upgrade. What changed is that 42 new sets were added in a tiered pattern, and those are what new access should be granted through.

4.1 The three-tier pattern¶

Most functional areas now expose three sets:

Tier	Suffix	Grants
Schema Access	`_Schema_Access`	Object, field, record-type and tab visibility. No Apex, LWC or admin capability — the right choice for reporting and integration users.
User	`_User`	Schema access plus the components and actions an everyday user needs.
Admin	`_Admin`	User access plus configuration of that area.

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`	—
Relationships	`CV_Relationship_Schema_Access`	`CV_Relationship_User`	—
Recognition	`CV_Recognition_Schema_Access`	—	`CV_Recognition_Admin`
Rollups	`CV_Rollups_Schema_Access`	—	`CV_Rollups_Admin`
Governance	`CV_Governance_Schema_Access`	—	`CV_Governance_Admin`

4.2 Capability & legacy sets (35)¶

Sets that grant a specific capability rather than an area tier, plus those carried forward from the pre-1.1.7 model.

Permission set (API name)	Grants
`CV_Analytics_Executive_Admin`	Executive-scope analytics administration.
`CV_Analytics_PracticeLead_Admin`	Practice-lead-scope analytics administration.
`CV_BD_Operations`	BD operations. Predates the tiered sets.
`CV_BD_Task_Management`	BD task management. Predates the tiered sets.
`CV_BD_Trip_Management`	BD trip planning. Predates the tiered sets.
`CV_Base_Access`	The ClientVerse baseline — assign to every user.
`CV_Bulk_Tools_Access`	CSV Import, Bulk Add, Bulk Activity.
`CV_Data_Import_Full_Access`	Full data-import access.
`CV_Data_Manager`	Ongoing data stewardship.
`CV_Data_Migration`	Migration tooling access.
`CV_Executive_Analytics`	Firm-wide analytics and forecasts.
`CV_Export_Child_Records`	Exporting child records alongside parents.
`CV_Financial_Data_Access`	Financial summaries and time/billing data.
`CV_Full_Access`	Everything. Administrators only.
`CV_Marketing_Campaign_Record_Types`	Campaign record types.
`CV_Marketing_Operations`	Marketing operations. Predates the tiered sets.
`CV_Mass_Update_Admin`	The Mass Update tool.
`CV_Merge_Records`	Deep merge of duplicate records.
`CV_Practice_Leadership`	Practice-leader views and access.
`CV_Recognition_Manage`	Record and manage recognitions.
`CV_Recognition_Read`	Read-only recognition access.
`CV_Relationship_Data_Access`	Relationship (ERM / `Connection__c`) data. Predates the tiered sets.
`CV_Relationship_Intelligence_User`	Relationship-intelligence end-user access.
`CV_Setup_Checklist_Admin`	The Admin Setup Checklist.
`CV_Trip_Target_Override_Access`	Overriding trip-target selection rules.
`CV_View_Child_Clients`	Visibility of child accounts in a hierarchy.
`Classification_Management`	Manage the classification taxonomy and rules. Predates the tiered sets.
`Collaborator_Admin`	Administer the collaboration / Wall model. Predates the tiered sets.
`Collaborator_Config`	Configure collaboration settings. Predates the tiered sets.
`ListBuilder_User`	Use List Builder. Predates the tiered sets.
`List_Builder_Admin_Permission`	Administer List Builder. Predates the tiered sets.
`MCAE_Integration`	The MCAE marketing-automation integration user.
`Override_Auto_Generated_Name`	Override auto-generated record names (e.g. during import).
`Rollup_Definition_Admin`	Rollup definition administration.
`Wall_Permitted_User`	Access to the Wall collaboration feature.

Source: permission_sets in clientverse-core-1.1.7.json — that file is authoritative if this table and it ever disagree.

4.3 Permission-set groups (8)¶

Groups bundle the sets above for a role; assigning a group is the recommended default.

Permission-set group (API name)	Typical role
`CV_Admin_Team`	CRM administrators. New in 1.1.7.
`CV_Lawyer_Team`	Attorneys / fee-earners. New in 1.1.7.
`CV_Partners`	Partners.
`CV_Practice_Leads`	Practice-group leaders.
`CV_BD_Team`	Business-development team.
`CV_Marketing_Team`	Marketing team.
`CV_Matters_Access`	Roles needing matter access.
`CV_Executive`	Firm executives.

The two new groups fill the gaps the earlier six left — there was previously no group for administrators or for fee-earners, so both roles had to be assembled from individual sets.

Source: permission_set_groups in clientverse-core-1.1.7.json.

5. Field-level detail → Data Dictionary v3.0¶

This page is structural by design. For any field on any object above — type, picklist values, formula, data source, inline help — use the canonical Data Dictionary v3.0 in ../../../data-model/, which also holds the DB Schema. The object-level descriptions, data_source, and audience for the priority Core objects are in objects/core-key.yaml.

Unresolved facts¶

Functional-group counts are editorial groupings for navigation; the authoritative per-object package/kind/field facts are in catalog.json, not this page.