Skip to content

ClientVerse Implementation Guide

This guide is the end-to-end playbook for standing up ClientVerse in a firm's Salesforce org: who needs to be involved, how to sequence the org and environment work, what order to install the packages in, how to assign access, how to load legacy data, and how to get to go-live. It is customer-neutral — it describes the standard implementation, not any one firm's delivery plan.

ClientVerse ships as two packages, and the implementation path depends on which the firm has licensed:

Edition Package Who has it
ClientVerse Core 1.1.7 unlocked, namespace clientverse every client
ClientVerse Modules 0.4.0 managed add-on (Dispatch, Whitespace, AI, Analytics) some clients

Authoritative package contents (objects, apps, permission sets, versions) come from ../_package-facts/. This guide cites those facts; it never restates counts from memory. See clientverse-core-1.1.7.json, clientverse-modules-0.4.0.json, and the sync-report.md.

1. Who this is for & prerequisites

Audience: implementation teams and consultants standing up a new org, plus the firm-side admins who will own it after handoff.

Before you begin, confirm the firm has:

  • A Salesforce org on a supported edition. ClientVerse is a managed/unlocked package product that relies on custom objects, Apex, Lightning Web Components, Flows, and custom permission sets — Core 1.1.7 alone introduces a large object and Apex footprint (see counts in clientverse-core-1.1.7.json). An Enterprise or Unlimited edition (or a Developer/partner org for sandboxes) is the working assumption. Confirm the edition supports the required custom-object, Apex, and permission-set capacity before scoping.
  • Sufficient Salesforce licenses for every intended user, plus headroom for integration/service accounts used by migration and ongoing integrations.
  • System Administrator access to the target org (and to each sandbox) for the implementation team — package installs, permission-set assignment, and configuration all require it.
  • Decisions on org strategy (new org vs. existing org, sandbox topology) made with the firm — see §2.
  • A data source inventory for migration and integrations: legacy CRM (InterAction), experience/matter data, opportunity pipeline, and the firm's data platform feeds (PMS/ERM/MAP). See §5 and §6.

For the day-to-day administration that follows handoff (user setup, ongoing permission management, configuration), this guide hands off to the Admin Guide.

2. Org & environment strategy

ClientVerse is installed into the firm's Salesforce org and configured on top of the packaged metadata. Plan environments before any install.

  • Understand the system shape first. Review the architecture docs for how ClientVerse is structured, how data flows, and the security model the packages assume: ../../architecture/ (start with ClientVerse_Technical_Architecture.md, then the security companion).
  • Sandboxes. Stand up the package install and all configuration in a sandbox first, validate, then promote. A typical topology is:
  • a developer/config sandbox for the initial install and configuration build-out,
  • a full or partial-copy sandbox for migration dry-runs and integration testing against representative data volumes,
  • a UAT/staging sandbox for firm sign-off,
  • then production.
  • Promotion discipline. Move the packages and configuration through environments in a controlled sequence rather than building directly in production. The product-level deployment framework and rollout sequence live in ../../deployment/ — align the sandbox-to-production path with it (see §8).

The actual per-customer Salesforce orgs, pipelines, and deployment repos are delivery artifacts and live outside these product docs. This guide documents the standard environment strategy only.

3. Install order

Install the packages in dependency order: Core (unlocked) first, assign permission sets, then Modules (managed). Do this in a sandbox before production (§2).

  1. Install ClientVerse Core (unlocked) first. Core is the foundation every client gets — the data model, apps, security, and BD/relationship workflows. Install the Core unlocked package (namespace clientverse) into the target sandbox. Nothing else can go in ahead of it.
  2. Run post-install steps for Core — Flows activated, any required settings in place — and confirm the install completed cleanly before assigning access.
  3. Assign Core permission sets / permission-set groups to the implementation and pilot users so the org is usable and verifiable. Core ships 66 permission sets and 8 permission-set groups (see clientverse-core-1.1.7.json). Start with CV_Base_Access for everyone plus the role group, rather than picking individual sets; assignment specifics are in the Admin Guide (§4).
  4. Verify Core — confirm the 6 Core applications (CV_Admin, CV_BD, CV_Experience, CV_Intelligence, CV_Lawyer, CV_Marketing) load and that a representative user can navigate the apps and tabs. Treat this as a gate before adding Modules.
  5. (Modules clients only) Install ClientVerse Modules (managed). Only after Core is installed, configured, and verified do you add the Modules managed package. See the dependency callout immediately below for the Core version Modules requires.

Core version requirement — Modules 0.4.0 needs Core 1.1.7. ClientVerse Modules 0.4.0 declares a package dependency on ClientVerse Core Unlocked@1.1.7-6. An org on any earlier Core must be upgraded before the Modules install; attempting Modules first fails the install.

This floor moved. Modules 0.3.0 required only Core 1.1.4, so an org that is currently running Modules 0.3.0 on Core 1.1.4, 1.1.5, or 1.1.6 is not ready for Modules 0.4.0 — it needs the Core upgrade first. Check the installed Core version against 1.1.7-6 rather than assuming a working Modules org is already compatible. Source: clientverse-modules-0.4.0.json (depends_on) and the sync-report.md.

  1. (Modules clients only) Run post-install for Modules and assign the Modules permission sets — CV_Modules_Access as the baseline, then CV_Dispatch_User / CV_Dispatch_Admin (see clientverse-modules-0.4.0.json). Leave the AI and Analytics sets unassigned for now — see §9.
  2. (Modules clients only) Configure Dispatch and Whitespace — see the Core-only vs Core+Modules contrast in §9.
  3. Complete the manual post-install steps. Two things do not ship as packaged metadata and must be configured in the org by hand after every fresh install:
  4. Restriction rules — Show_Wall_Accounts and Show_Wall_Records. Salesforce cannot package restriction rules in 2GP at all, managed or unlocked, so these are always a manual step. Wall record visibility is not correct until they exist.
  5. Lightning page assignment for Opportunity and Trip__c — assign the CV record pages in Lightning App Builder.

Neither is optional, and neither will show up as an install error — the install succeeds and the behaviour is simply wrong. Put both on the go-live checklist (§10).

4. Post-install permission assignment

ClientVerse access is delivered entirely through permission sets and permission-set groups — assign these rather than editing profiles.

  • Core provides the 66 permission sets and 8 permission-set groups enumerated in clientverse-core-1.1.7.json. Since 1.1.7 these follow a three-tier pattern per functional area — *_Schema_Access (data visibility only), *_User (everyday use), *_Admin (configuration) — alongside capability sets like CV_Full_Access and CV_Data_Migration. Groups (CV_Admin_Team, CV_Lawyer_Team, CV_BD_Team, CV_Marketing_Team, CV_Partners, CV_Practice_Leads, CV_Executive, CV_Matters_Access) bundle them for role-based assignment.
  • Modules adds 11 permission sets (see clientverse-modules-0.4.0.json), assigned only to firms that licensed Modules: CV_Modules_Access as the baseline, the Dispatch tier (CV_Dispatch_Schema_Access / _User / _Admin, plus the retained CV_Dispatch_Lawyer), the AI tier (CV_AI_Schema_Access / _User / _Admin, CV_AI_Chat_User, CV_AI_Actions_Permission), and CV_BI_Visualization.

Assign by group, not by set. With 66 Core sets, picking individually is how orgs drift. Give every user CV_Base_Access, then one group per role, then individual sets only for genuine exceptions (a data lead needing CV_Data_Migration, say).

The mapping of personas to specific permission sets / groups, and the mechanics of assigning them, are owned by the Admin Guide — follow it for the authoritative assignment matrix rather than duplicating it here. During implementation, the practical sequence is: assign migration/admin sets first (e.g. CV_Data_Migration) so the team can load data, then assign role-based groups to pilot and production users ahead of go-live.

5. Initial data load & migration

Most implementations bring legacy data into ClientVerse before go-live. Migrations are one-shot data moves (distinct from the ongoing integrations in §6) and are governed by the playbooks in ../../migrations/ — start with 00_Migration_Strategy.md.

At a high level, plan for these legacy sources (neutralized — exact scope is a per-firm decision):

  • Legacy CRM (InterAction). Contacts, companies, relationships, and activity history from the firm's incumbent CRM. This is typically the largest and most active migration — see ../../migrations/ (Migration_InterAction.md).
  • Experience / matter data. Experience records and the matter/experience model — see Migration_Experience_System.md.
  • Opportunities / pipeline. BD opportunity and pipeline data — see Migration_Opportunities.md.

Sequence migration after Core is installed and the migration permission set (CV_Data_Migration) is assigned, and run it against a copy sandbox first to validate volumes, mappings, and de-duplication before loading production. The extraction/staging tooling itself is a delivery artifact and is referenced from the migrations docs, not reproduced here.

6. Integration setup pointers

Beyond the one-shot migration, ClientVerse connects to the firm's surrounding systems on an ongoing basis — typically fed through the firm's data platform. The authoritative specs live in ../../integrations/ (start with 00_Integration_Architecture.md); do not re-derive them here.

  • PMS (practice/financial management — e.g. 3E, Aderant): financial and client/matter data feeds. See Integration_PMS_Salesforce_Detailed_Spec.md.
  • ERM (relationship intelligence — e.g. Introhive, SigParser): relationship and interaction signal. See Integration_ERM_Introhive_SigParser.md.
  • MAP (marketing automation — e.g. Pardot/MCAE): marketing engagement. See Integration_Marketing_Pardot_MCAE.md.

Plan integration enablement after the core data model is in place and validated, and test each connection in a sandbox against representative data before production cut-over.

7. Configuration-first governance

ClientVerse is delivered as packaged metadata (unlocked Core + managed Modules). Do not edit packaged components in place. Instead:

  • Extend through configuration, not modification — add fields, page-layout and Lightning-page adjustments, list views, reports/dashboards, and declarative automation alongside the packaged metadata rather than altering it.
  • Treat the managed Modules package as a black box — managed components are not editable by design; configure the behavior they expose (e.g. Dispatch configuration objects and custom metadata) rather than trying to change the package itself.
  • Keep firm-specific configuration separate from the product packages so that Core and Modules upgrades (such as the Core upgrade to 1.1.7 required for Modules 0.4.0, §3) remain clean and non-destructive.
  • Govern changes through the environment promotion path in §2/§8 — build configuration in a sandbox, validate, then promote. Governance and the deployment framework are detailed in ../../deployment/.

This keeps the firm on a supported upgrade path: because nothing packaged was modified, package upgrades apply cleanly and the firm's configuration is preserved.

8. Rollout sequence

The standard rollout follows the product-level deployment framework and GTM sequence in ../../deployment/ (start with the GTM & Deployment Strategy Memo, then the deployment framework). Summarized, the standard sequence is:

  1. Provision & install — stand up the sandbox(es) per §2 and install Core (and Modules where licensed) in dependency order per §3.
  2. Configure — apply firm configuration on top of the packages (§7), assign permission sets (§4).
  3. Migrate — load legacy data into a copy sandbox, validate, iterate (§5).
  4. Integrate — enable and test PMS/ERM/MAP feeds against representative data (§6).
  5. UAT — firm validates in a UAT/staging sandbox and signs off.
  6. Promote to production — install packages and deploy validated configuration to production along the controlled promotion path.
  7. Production data load & integration cut-over — run the production migration and switch on integrations.
  8. Go-live & hand-off — assign production users, go live, and hand operational ownership to firm admins (§1, Admin Guide).

Use ../../deployment/ as the source of truth for the deployment framework, sprint plan, and build-instruction template behind each step.

9. Core-only vs Core+Modules implementation paths

Every firm gets Core. Only some license Modules. The Modules path is a strict superset of the Core path — same foundation, with extra steps. Use this to scope the engagement.

Step Core-only client Core + Modules client
Install Core (unlocked) Yes Yes
Assign Core permission sets / groups (66 / 8) Yes Yes
Manual post-install: restriction rules + Lightning page assignment Yes Yes
Migrate legacy data; enable PMS/ERM/MAP integrations Yes Yes
Upgrade Core to 1.1.7 (if below 1.1.7-6) Not required Required before Modules install (§3 callout)
Install Modules (managed) — Yes
Assign Modules permission sets (CV_Modules_Access, Dispatch tier) — Yes
Configure Dispatch (notifications/digests) — Yes 🧩
Configure Whitespace (revenue-opportunity scoring) — Yes 🧩
Decide on AI and Analytics (early access, ship off) — Optional 🧩

What Modules adds, concretely:

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

  • A Core version-upgrade prerequisite (if Core is below 1.1.7-6). Modules 0.4.0 requires ClientVerse Core Unlocked@1.1.7-6, so a client on any earlier Core must complete a Core upgrade before the Modules install (§3). This is the single biggest sequencing difference and should be scoped as its own step. Note it now catches orgs that were fine under Modules 0.3.0, whose floor was only 1.1.4.
  • A Modules (managed) package install — adding the Modules objects, the CV_Dispatch_Setup application, tabs, and Apex/LWC on top of Core (see clientverse-modules-0.4.0.json).
  • Eleven extra permission sets available, of which a standard Dispatch rollout uses three — CV_Modules_Access, CV_Dispatch_User, CV_Dispatch_Admin.
  • Dispatch configuration — set up notification/digest definitions, sections, subscriptions, and run settings (Dispatch's configuration objects). 🧩 (Modules: Dispatch)
  • Whitespace configuration — set up revenue-opportunity scoring (scoring config, score weights, thresholds). 🧩 (Modules: Whitespace)

Scope note — AI and Analytics are now in the package, and are early access. In Modules 0.4.0, Dispatch and Whitespace are the mature modules and are what a standard implementation configures. AI (the CV_AI_Chat interface and AI Actions) and Analytics (Power BI / Tableau embedding) also ship, but they are off until their permission set is assigned and engineering still tracks them as maturing. This corrects the pre-0.4.0 guidance that AI was foundation-only and Analytics absent.

How to scope them. Do not put either on the critical path to go-live. Treat them as a post-go-live option, and for AI settle the firm-policy question first: the chat sends CRM query results to Anthropic or OpenAI, which for a law firm is a decision for the general counsel or risk function, not the implementation team. Record access itself is enforced (queries run in USER_MODE). See the Admin Guide §13–§14. Source: clientverse-modules-0.4.0.json and sync-report.md.

10. Go-live checklist

Confirm each before declaring go-live. Items marked 🧩 apply only to Modules clients.

  • [ ] Edition & licenses confirmed sufficient for all production users plus service accounts (§1).
  • [ ] Environment path exercised: configuration and data validated in sandbox(es) before production (§2).
  • [ ] Core (unlocked) installed in production, post-install steps complete, install verified clean (§3).
  • [ ] Core apps verified — all 6 applications load for a representative user (§3).
  • [ ] Permission sets / groups assigned to all production users per the Admin Guide matrix — CV_Base_Access for everyone, then role groups (§4).
  • [ ] Restriction rules created — Show_Wall_Accounts and Show_Wall_Records. These are never packaged; Wall visibility is wrong without them and the install reports no error (§3, step 8).
  • [ ] Lightning pages assigned for Opportunity and Trip__c in App Builder — also not packaged (§3, step 8).
  • [ ] 🧩 Core upgraded to 1.1.7 (Modules clients only) — Modules 0.4.0 requires ClientVerse Core Unlocked@1.1.7-6. Verify the actual installed version; an org already running Modules 0.3.0 satisfied a lower floor (1.1.4) and may still need this (§3 callout).
  • [ ] 🧩 Modules (managed) installed and post-install steps complete (Modules clients only) (§3).
  • [ ] 🧩 Modules permission sets assigned — CV_Modules_Access plus the Dispatch tier (Modules clients only) (§4).
  • [ ] 🧩 AI / Analytics decision recorded (Modules clients only) — either deliberately left off, or enabled with the firm's sign-off on sending CRM data to an external AI provider (§9).
  • [ ] 🧩 Dispatch configured — notification/digest definitions in place and test-run (Modules clients only) (§9).
  • [ ] 🧩 Whitespace configured — scoring config/weights/thresholds set (Modules clients only) (§9).
  • [ ] Migration complete & validated — production legacy data loaded and reconciled (§5).
  • [ ] Integrations live & verified — PMS/ERM/MAP feeds connected and tested (§6).
  • [ ] Configuration is additive only — no packaged metadata modified; upgrade path intact (§7).
  • [ ] UAT sign-off captured from the firm (§8).
  • [ ] Operational hand-off to firm admins complete, with the Admin Guide as their reference (§1, §8).