Skip to content

ClientVerse Configuration Reference

This is the structural reference for what ships in a ClientVerse org: the objects, applications, permission sets, and configuration (custom metadata / custom settings) that make up the product. It is for administrators and implementation consultants who need to know what exists and how it is organized — not how to use a feature day-to-day (that's the User Guide) and not how to install it (that's the Implementation Guide).

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

All package facts here (counts, app names, permission-set names, object lists) 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.

How this reference is organized

This reference splits along the two packages, because which package an object comes from determines who has it and how it is upgraded:

Page Scope What it covers
Core applies_to: [core] — every client The object inventory grouped by function, the 6 applications, and the 66 permission sets + 8 permission-set groups.
Modules applies_to: [modules] — optional add-on The Dispatch, Whitespace, AI and Analytics object reference, their custom-metadata settings, the 11 Modules permission sets + app, and the objects Modules extends.

Authoritative package definitions: clientverse-core-1.1.7.json · clientverse-modules-0.4.0.json.

Where this reference sits relative to the canonical sources

This reference is a structural index, not a field dictionary. It tells you which objects exist, in which package, in which functional group — and points you to the canonical sources for the detail:

  • Field-level detail → the Data Dictionary v3.0. For every field's type, picklist values, data source, and meaning, use the canonical Data Dictionary v3.0 (../../data-model/). This reference deliberately does not reproduce the ~2,000 Core fields; it summarizes objects by group and links out. The data-model directory also holds the DB Schema.
  • Object meaning → the annotation catalog. Authored object-level descriptions, data_source, audience, and key-field notes live in the annotation catalog under ../_package-facts/objects/ (core-key.yaml, dispatch.yaml, whitespace.yaml, ai.yaml).
  • Structural facts → the synced package JSON + catalog.json. Counts, package membership, kinds, and the full object→field inventory are authoritative in catalog.json and the two package JSON files. If the package changes, those files are re-synced — this prose is not a substitute for them.

Rule of thumb. Object exists and belongs to package X → cite catalog.json / the package JSON. Object means Y → annotation catalog. Field is a date/picklist/ formula → Data Dictionary v3.0. This page never overrides those.

How to read the tables on these pages

Object-group tables (on the Core page) list a functional group, the number of objects in it, and a few representative objects by API name — not every field. To go from a group to a field, open the named object in the Data Dictionary v3.0.

Object reference tables (on the Modules page) list an object's API name, its authored purpose, and selected key fields with their role. Key fields are a curated subset from the annotation catalog; they are not the object's full field list.

Permission tables list permission sets and permission-set groups by their exact API name from the package JSON. This reference states what they are called and what they bundle; for the role → access mapping and the assignment workflow, see the Admin Guide and the Security Architecture.

Application tables list the apps (Lightning applications) shipped by each package by their exact developer name.

API names are in code font throughout. Salesforce custom objects/fields end in __c, custom metadata types in __mdt, platform events in __e.

Conventions

This page follows ../_conventions.md: customer-neutral (no customer names — NDA), Markdown only, relative links, and the 🧩 badge on every Modules-only section. The domain vocabulary (Experience, Matter, Opportunity, Classification, ERM, Connection vs Relationship, …) is defined in ../../GLOSSARY.md; known traps are in ../../GOTCHAS.md.

Pages