Skip to content

Connections & relationship intelligence

Part of: ClientVerse Core (every client).

What it is

A Connection (Connection__c) is a relationship signal between one of the firm's people and an external contact — evidence that a relationship exists, and how strong it is. Connections answer the question that starts most business development: who at the firm has the warmest path to this person?

Connections are derived, not entered. They are populated from an ERM (Enterprise Relationship Management) system — Introhive, SigParser, or similar — which mines email and calendar traffic to infer who actually knows whom. Nobody types a Connection in.

"ERM" is overloaded in this product. Here it means the external relationship-intelligence system category. It is not the contact review queue, despite some engineering artifacts using ERM* prefixes for that feature. See the Glossary.

Connection vs Relationship

Two words that sound interchangeable and are not:

  • A Connection is observed — inferred from real interaction signal.
  • A Relationship is asserted — a structural fact someone recorded, such as a formal account team assignment.

Observed signal can contradict the asserted structure, and that is often the useful finding: the partner formally assigned to an account may not be the person who actually talks to the client.

Who it's for

  • Attorneys find the warmest introduction before reaching out cold.
  • BD uses connection strength to plan trips, target lists, and pursuits.
  • Relationship managers monitor whether key relationships are being maintained.
  • Admins configure the feed and the query adapter.

How it works

Connections appear as a related list on Contacts and Accounts. Each carries the firm person, the external contact, and strength indicators derived from interaction signal.

Relationship strength is surfaced on the Contact as Relationship_Strength__c and — since Core 1.1.6 — is a filter in Client Locator and in trip-target selection. That turns "who do we know here?" into "who do we know well here?", which is the version of the question worth acting on.

The query layer behind relationship views is configuration-driven rather than hardcoded, so which relationships are surfaced and how they are ranked can be adjusted without a deployment.

Engagement score

A related but distinct signal: an engagement score computed per contact/account from activity, giving a consistent measure of whether a relationship is warming or going quiet. Where relationship strength says how well someone is known, engagement says how current that is.

What to check when it looks wrong

Connections are only as good as the feed. Before treating sparse or stale Connections as a product defect:

  • Has the ERM sync run, and when?
  • Is the contact in scope for the feed — some firms exclude domains, individuals, or practice groups?
  • Are privacy exclusions suppressing the signal deliberately?

An empty Connections list is far more often a feed question than a ClientVerse one.

Access and sensitivity

Relationship intelligence is among the most sensitive data in the product — it describes who knows whom, derived from people's mail. CV_Relationship_Data_Access gates it, and the sharing model applies to relationship data as it does to records. Treat any visibility of relationship data by a user who should not have it as a serious defect, not a cosmetic one.

  • Client Locator — where connections drive discovery.
  • Trip planning — connection strength drives target selection.
  • ERM integration spec — how the feed works.
  • QA coverage: REL in core-relationships.md.