Skip to content

Classification

Part of: ClientVerse Core (every client). Roadmap: Classification Picker (1.1).

What it is

Classification is ClientVerse's firm taxonomy — the structured vocabulary the firm uses to describe its world: practice areas, industries, regions, sectors, and any other dimension the firm segments on. A Classification is one node in that taxonomy; a Classification Assignment ties a node to a record. Together they turn loose tags into a consistent, reportable structure that drives segmentation, list building, and reporting across ClientVerse.

Who it's for

  • Admins own the taxonomy: which classifications exist and how they're assigned.
  • BD and marketing consume it — filtering, building lists, and reporting by practice/industry/region.

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 lives in the Data Dictionary.

Classification (Classification__c)

A single node in a firm taxonomy (41 fields). Its data source is user-entered / configuration — admins define the set of classifications and their structure (e.g. a practice-area tree, an industry list, a region hierarchy). Records are assigned classifications; the node itself just defines the vocabulary.

Core 1.1.10 added fifteen taxonomy fields to the node:

  • an abbreviation;
  • a legal/non-legal flag;
  • nine type checkboxes for filtering;
  • four fields recording which system a value was loaded from.

Classification Assignment (Classification_Assignment__c)

The join that makes the taxonomy actionable (51 fields). An assignment links a Classification__c to a record. Assignments can be:

  • Manual — a user picks a classification on a record (the Classification Picker, roadmap 1.1).
  • Rule-driven / calculated — classification assignment rules apply classifications automatically based on record data.

Because assignment is its own object (not just a picklist), a record can carry many classifications, each with its own metadata, and the same taxonomy can be reused everywhere.

How to use it

Tagging records (BD / marketing)

  • Use the Classification Picker on a record to assign one or more classifications (practice, industry, region, …).
  • Filter and report by classification, and feed it into List Builder to build dynamic, taxonomy-driven lists.

Managing the taxonomy (admins)

  1. Define the Classification__c nodes that make up each dimension of the firm taxonomy.
  2. Decide which assignments are manual vs rule-driven; configure classification assignment rules for the automatic ones.
  3. Grant the Classification_Management permission set to taxonomy owners.

Since Core 1.1.10 the rebuilt CV Admin app has a Taxonomy tab. A data steward can reach it without full admin access through the CV_Data_Steward permission-set group, but the group alone can't read Classifications. Assign CV_Data_Manager and CV_Classification_Schema_Access alongside it, or the tab fails to load for a steward.

Why it matters

The taxonomy is foundational: lists, campaigns, experience search, content distribution, and reporting all lean on consistent classifications. A clean taxonomy makes segmentation reliable; a messy one undermines every downstream feature that filters by it.

Key objects

Object Fields Role
Classification__c 41 A node in the firm taxonomy (practice/industry/region/…)
Classification_Assignment__c 51 Assigns a classification to a record (manual or rule-driven)

Configuration pointers

  • Permission set: Classification_Management.
  • See the Admin Guide for taxonomy setup and assignment rules, and the Data Dictionary for the full 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

  • Assignment rules are only as good as the underlying record data; classifications applied to incomplete records may need review.
  • Restructuring a live taxonomy (renaming or merging nodes) affects every record assigned to the changed nodes — plan taxonomy changes deliberately.
  • Namespaced orgs: if the Classification_SCR_BulkAssign flow shows an error, re-pick its Apex action in Flow Builder.
  • Fixed in 1.1.10: the rule editor no longer shows stale values, bulk and auto-assign cope with many active rules, the Classification Rollups seed data loads, and tagging no longer deletes Primary Industry.