Skip to content

Post-install steps

Some things a Salesforce package cannot do on its own behalf. A few of them are needed for shipped features to work at all, and most fail silently — the feature appears installed, the UI looks correct, and nothing works until someone notices.

Work through this list after every install, and re-check it after every upgrade.

Why this exists. Salesforce does not namespace-rewrite certain references, does not allow some metadata types in packages, and does not let a package assign permissions on a subscriber's behalf. None of these are defects in ClientVerse; all of them produce a broken feature if skipped.

The checklist

# Step Symptom if skipped
1 Fix list-view button links Buttons error on click
2 Set org-wide defaults Walls and sharing silently do nothing
3 Assign permission set groups Users see empty apps
4 Activate flows that ship inactive Automation never fires
5 Enable wall object mappings Walls cover the wrong objects
6 Create restriction rules List views show walled records
7 Assign Lightning record pages Records show the stock Salesforce layout
8 Configure the docs link In-product Help goes nowhere
9 Place the components that ship unplaced Whole tools are unreachable
10 Create a List Builder configuration Preset filters and mappings never apply

This is the one users notice first, because it produces a visible error.

A button's URL is a plain string. Salesforce does not apply the package namespace to it at install, so a button pointing at /flow/Classification_SCR_BulkAssign looks for a flow of that name — while the installed flow is actually clientverse__Classification_SCR_BulkAssign. The button 404s.

Affected (checked on 1.1.7):

Button Object(s) Points at Should point at
Assign Classification Account, Contact /flow/Classification_SCR_BulkAssign /flow/clientverse__Classification_SCR_BulkAssign
Add to List or Campaign Contact /flow/Contact_SCR_AddToList /flow/clientverse__Contact_SCR_AddToList
Generate Itinerary Trip /apex/TripItineraryPDF /apex/clientverse__TripItineraryPDF

To fix: Setup → Object Manager → the object → Buttons, Links, and Actions → the button → Edit → insert clientverse__ before the flow or page name → Save. Repeat per object — Assign Classification exists separately on Account and on Contact.

Then click each one from a list view to confirm. This is quick and is the only real proof.

🧩 With Modules 0.8.0, also edit CV_Convert_To_Opportunity on Task and Event so it points to /flow/clientverse__Opportunity_SCR_Create.

You may have read that the flows' Apex actions also need re-picking in Flow Builder. Checked against a 1.1.7 install, every packaged flow's Apex action reference was already namespace-qualified — ten references across seven flows. The 1.1.10 release notes name two flows to watch, though: if Classification_SCR_BulkAssign or Opportunity_SCR_Create shows an error in a namespaced org, re-pick its Apex action in Flow Builder. Verify by running one button end to end; if the flow completes, no further action is needed.

2. Set org-wide defaults

The package ships permissive OWD. Until you tighten it, walls and sharing rules restrict nothing. This is the highest-consequence item on this list and the least visible.

See Who sees what for what to set and the two practical constraints (the Account/Opportunity/Case cascade, and packaged custom objects needing the Setup UI).

3. Assign permission set groups

A package cannot assign permissions to a subscriber's users. Until you assign a persona group, users see an app with nothing in it.

Assign groups, not individual permission sets. The nine personas are listed in Who sees what.

In 1.1.10 the eight original persona groups don't give access to a CV app or to Lightning Experience, so assign app visibility separately. Only CV_Data_Steward includes it.

4. Activate flows that ship inactive

Several packaged flows install in Draft status and never fire until activated. Checked on 1.1.7, these included the account-hierarchy automation (Account_AfterUpdate_DemoteToRelatedCompany, Account_AfterUpdate_PromoteHiddenAccount) and NotificationEvent_EVT_DispatchNotification. 1.1.10 adds Block_Lead_Convert_Unapproved, the Lead approval gate's conversion block, which ships inactive.

Some of this is deliberate — features ship dark so a firm can enable them selectively. The risk is assuming all of it is deliberate. Review every packaged flow's status against what your firm expects to be running, rather than assuming the defaults match your intent.

Setup → Flows, filter by status.

The reverse case in 1.1.10: two flows that ship active. The Lead approval gate's two flows are active on install. As soon as a queue named Data_Steward exists, every new Lead, including Leads created by MCAE and ERM, is reassigned to it, and its members get an email about each one. Create that queue only when you want this; see the release notes' Upgrade notes.

Packaged Apex automation has its own switch, and in 1.1.10 it ships off. See Turning automation off.

5. Enable wall object mappings

Collaborator_Field_Mappings__mdt controls which objects participate in wall-based sharing. It ships with nine rows; Account, Matter, List and DMS Document are enabled, and Campaign, Contact, Experience, Opportunity and Plan are present but switched off.

If your firm's walls need to cover Experience or Opportunity, enable those rows. Setup → Custom Metadata Types → Collaborator Field Mappings → Manage Records.

6. Create restriction rules

Restriction Rules cannot be packaged at all — Salesforce does not support them in 2GP, managed or unlocked. They must be created by hand in each org.

Create the rules that keep walled records out of list views, and switch the relevant list views to the scoping filter. Without them, a walled record can still surface in a list view even when the sharing model is correct.

7. Assign Lightning record pages

Packaged Lightning pages are installed but page assignment is org configuration, not packaged metadata. If records open with the stock Salesforce layout rather than the ClientVerse one, the pages are present but unassigned.

Setup → Object Manager → the object → Lightning Record Pages → Assign as Org Default (or by app and record type).

In 1.1.10 these record-type page assignments don't install, so assign them by hand:

  • the Event and Webinar campaign pages;
  • record-type List and Campaign pages, which carry My Contacts;
  • Prospective and Former Client pages, which carry the Client Intelligence tab;
  • record-type Contact and Account pages, which carry the MCAE compliance fields.

Re-check this after upgrades, and particularly after any change to record types — per-record-type assignments are the most common casualty.

Since 1.1.10, each of the six CV apps has a Help tab that links to the ClientVerse documentation site. It reads its destination from a CV_Docs_Site__mdt record that the package deliberately does not ship — a packaged row would hard-code a vendor URL into every subscriber org, frozen at package-version time.

Create one CV_Docs_Site__mdt record with Base_URL__c set to the documentation site's root (no trailing slash), Version_Path__c set to latest, and Is_Active__c checked.

9. Components that ship unplaced

Standalone components ship with no route to them. In 1.1.10 there are sixteen, including three new in Modules 0.8.0 (marked below). They declare themselves placeable but are referenced by no packaged page, tab, quick action, app or flow, so nobody can reach them until you add them in the Lightning App Builder.

The rebuilt CV Admin app now places four that 1.1.7 left unplaced: - cvMassUpdateTool (Mass Update tab); - dataQualityIssuesQueue (Home, My Work and Data Quality); - cvGovernanceConfigScreen (Automation Health); - rollupMonitorDashboard (Automation Health).

These placements were checked against the installed 1.1.10 package.

This is easy to mistake for a feature not existing. Several of these are tools an admin would actively look for and conclude the product lacks.

Component What it is
cvExportAnyObject Export from any object
rollupDefinitionForm Create and edit rollup definitions
wallAccessManager Manage wall access
clientLocator Find clients by location or address
cvPitchTaskBoard Pitch task board
cvEnrichmentPreview Preview enrichment results
listBuilderAccessToggle List Builder access control
cvWhitespaceHeatmap 🧩 Whitespace heatmap
whitespaceOpportunityDashboard 🧩 Whitespace opportunity dashboard
ermAdminQueue 🧩 ERM administration queue
ermContactReview 🧩 ERM contact review
ermSubscriptionManager 🧩 Modules subscription management
cvDigestDataTable 🧩 Digest data table
cvEventCheckInConsole 🧩 Event Check-In staff console, for the Campaign page (new in 0.8.0)
cvEventCheckInKiosk 🧩 Event Check-In self-service kiosk, for an App Page (new in 0.8.0)
cvEventCloseAttendance 🧩 Close Attendance, which marks no-shows; add it through a quick action (new in 0.8.0)

🧩 = requires ClientVerse Modules.

The Global Search home page, CV_Global_Search_Component (new in 1.1.10), also ships assigned to no app. Activate it, or place cvGlobalSearch on a page. Then click Manage Configurations to create the first configuration, and paste its Unique ID into the page's Configuration ID.

To place one: Setup → Lightning App Builder → edit or create a page → drag the component from the Custom list → Save and Activate.

Decide deliberately which your firm needs rather than adding all of them. An unused tool on a page is clutter; a missing one is a capability nobody knows they have.

Modal and picker components (classificationCreateModal, fieldPicker, flowPicker and similar) are also unplaced, and correctly so — they are opened by a parent component, not added to a page.

10. Create a List Builder configuration

List_Builder_Config__c preconfigures what the List Builder offers — the object, the preset filters, the field mappings, and whether users may change them. No records ship, because a configuration encodes firm policy rather than vendor defaults.

Until one exists the builder behaves as though unconfigured: no error, no prompt, just no presets. Its manager (listBuilderConfigManager) isn't placed on its own; it opens from the List Builder's edit-configuration control on a Campaign or List page.

From 1.1.10, the List Builder Contact Filters step in the CV Admin Setup Checklist seeds 13 default Contact filters under Config ID CV_Default_Contact_Filters. The shipped Campaign and List pages look up Config ID Template_One for their own object, so those presets don't appear there yet. Copy the seeded record's Filters__c into a List_Builder_Config__c record with Config_Id__c = Template_One and Object_API_Name__c = Campaign, and into another for clientverse__List__c.

See List Builder for the field reference.

After every upgrade

Upgrades preserve org configuration — OWD, sharing rules, permission set assignments, and page assignments all survive. What needs re-checking:

  1. New buttons — any new list-view button or page-launching button needs step 1
  2. Flow statuses — a new flow may arrive in Draft
  3. New CMDT rows — an upgrade can add configuration rows that ship disabled
  4. Record page assignments — especially after record-type changes
  5. Setup Checklist — re-run it in CV Admin so new seed rows are created

Verifying the install

A short acceptance test that catches most of the above:

  1. Log in as a non-admin test user with one persona group
  2. Open each app the persona should have; confirm the tabs are there
  3. Open an Account and a Contact; confirm the ClientVerse page renders, not the stock layout
  4. Select records in a list view and click Assign Classification; confirm a flow opens
  5. Confirm the user cannot see a record the persona should not
  6. Open a Trip and click Generate Itinerary; confirm a document renders

Step 1 is not optional. An administrator testing their own access has View All Data and will see everything work regardless of whether the model is correct.