Skip to content

List Builder

Part of: ClientVerse Core (every client). Roadmap: M1.1–M1.4.

What it is

List Builder is how the firm builds and maintains lists of people and accounts — the audiences behind campaigns, mailings, events, and targeted outreach. A list can be static (a fixed set of members you curate) or dynamic (a rule defined by SOQL/criteria that keeps itself current). Lists feed campaigns and outreach, and can be derived from other lists.

Who it's for

  • Marketing — builds mailing/event audiences and syncs them to campaigns.
  • BD — builds targeted outreach and pursuit lists.

How it works

Two Core objects, cited from objects/core-key.yaml, with field counts from catalog.json (Core 1.1.10); field-level detail is in the Data Dictionary.

List (List__c)

A curated or rule-driven set of members (22 fields), built with List Builder:

  • Static lists hold a fixed set of members you add and remove explicitly.
  • Dynamic lists are defined by SOQL / criteria — membership is evaluated from the rule, so the list stays current as data changes.

Since Core 1.1.10, filters support AND/OR with parentheses, and "has / has no related record matching…" conditions — for example "has a Connection scored 3 or higher". Related-record filters also work in namespaced orgs. The Manual update frequency is retired.

When a list draws on several source lists, an exclusion always wins: an exclusion from any source list overrides an inclusion from another, whatever order the background jobs finish in.

List Member (List_Member__c)

The membership of a record in a List__c (22 fields), with the metadata needed to manage and sync list/campaign membership.

Since Core 1.1.10, adding someone to a list records the adding user's firm-personnel Contact as Initial Sponsor, and later sponsors are appended. This is CV automation, which ships switched off (CV_Trigger_Setting.Org_Default.Triggers_Enabled__c is false), so it does nothing until automation is enabled for the object.

Roadmap mapping (M1.1–M1.4)

List Builder is delivered as a sequence of roadmap features (asana-feature-index):

Code Capability
M1.1 Build static lists
M1.2 Build dynamic lists with SOQL
M1.3 Update lists/campaigns from existing lists
M1.4 Flexible list/campaign member management

How to use it

Building a list (marketing / BD)

  1. Create a List__c. Choose static (curate members) or dynamic (define a SOQL/criteria rule).
  2. For a dynamic list, write the criteria — often filtering on classifications (practice, industry, region) so audiences stay taxonomy-driven.
  3. Add or refine members; List_Member__c records track membership.
  4. Derive a new list from an existing one, or update a campaign from a list (M1.3).
  5. Manage members flexibly — add, remove, and sync between lists and campaigns (M1.4).

Ties to campaigns

Lists are the bridge to campaigns: members sync from a List__c into a campaign, and updates can flow from existing lists into campaigns (M1.3). This keeps the marketing audience and the campaign membership in step without manual re-entry.

My Contacts (since 1.1.10)

On list and campaign pages, the My Contacts panel splits the user's own relationships into "on this list" and "not on this list", with a coverage meter. It needs ERM relationship data and the CV_Relationship_Intelligence_User permission set, which no permission-set group includes. It sits on the record-type List and Campaign pages, which an admin has to assign by hand. See Connections.

Sharing a list (since 1.1.10)

  • Inside Salesforce. An owner can remove one person or group without clearing everyone else's access, and the share picker no longer shows raw Ids or system groups.
  • Outside Salesforce. An owner can share a list with an email address. The recipient reviews it, adds or removes members and leaves notes on a page that needs no login. Each link has one purpose, can be revoked, and is audited. View-only, add-only and remove-only sharing are enforced on the server, and a link for one list can't write to another. This needs an Experience Cloud site with a public page and the entry component, CV_Magic_Link_Guest on the site's guest user, Key_Vault.Community_Site_Name set, and at least one Magic_Link_Policy__mdt record; see the 1.1.10 release notes.

Key objects

Object Fields Role
List__c 22 A static or dynamic (SOQL/criteria) set of members
List_Member__c 22 Membership of a record in a list

Preconfiguring the builder

List_Builder_Config__c lets an administrator decide, in advance, what the builder offers — so a marketing user opens it already scoped to the right object with the right filters, instead of assembling the same criteria by hand each time.

Field Controls
Object_API_Name__c Which object this configuration applies to
Filters__c The preset filters, as JSON
Predefined_Field_Mappings__c Preset field mappings, as JSON
Can_Edit_Mapping_Before_Add__c Whether the user may change the mapping before adding members
Default_Saved_View_Id__c The view the builder opens on
Invoke_Flows__c Flows to run from the builder
Config_JSON__c The wider configuration payload (e.g. columns)
Config_Id__c, Record_Id__c Identifiers used to bind a configuration to its context

Can_Edit_Mapping_Before_Add__c is the one to think about. Left on, a preconfiguration is a convenience — a sensible starting point the user can adjust. Turned off, it is a control: the mapping is fixed, and the user adds members on the firm's terms rather than their own. Which of those you want is a policy decision, not a technical one.

It ships empty and unreachable, both deliberate-looking and both worth knowing.

  • No records ship. A configuration encodes your firm's policy, not the vendor's, so the package cannot supply one. Until someone creates a configuration, the builder simply behaves as though none exists — no error, no prompt. The one exception is the default Contact filters below, which a Setup Checklist step creates on request.
  • No page surfaces it. The listBuilderConfigManager component is not placed on any packaged page or tab, so an administrator has to add it in the Lightning App Builder before it can be managed in the UI. See Components that ship unplaced.

Default Contact filters (since 1.1.10)

A new Contact list can start from 13 ready-made filters covering company, location, title and relationship strength. To create them, run the List Builder Contact Filters step in the Setup Checklist, on the CV Admin app's Automation Health tab.

They don't appear on Campaign and List pages yet. The step saves its presets under Config ID CV_Default_Contact_Filters for Contact, but the shipped Campaign and List pages look up Config ID Template_One for their own object. 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.

Configuration pointers

  • Permission sets: ListBuilder_User (build/use lists), List_Builder_Admin_Permission (admin).
  • See the Admin Guide for enabling List Builder and campaign sync, and the Data Dictionary for the field reference.

Since Core 1.1.7 there are also tiered sets for this area (_Schema_Access / _User / _Admin). The set named above still exists and still works — nothing broke on upgrade — but new access is best granted through the tier that matches the need. See Admin Guide §4.1.

Limits & known issues

  • Dynamic list freshness depends on when criteria are evaluated; a dynamic list reflects data as of its last refresh, not necessarily the instant you view it.
  • A dynamic list is only as precise as its SOQL/criteria — broad criteria can pull in unintended members, so validate the rule against a known sample before syncing to a campaign.