Contact

What It Is

A Contact is the continuing CRM record of a person an association needs to recognize, reach, or connect to organizations. Staff create it from name components and the other information they know. Its identity persists when the person changes a phone number, employer, title, or classification; those are changes to the person record rather than reasons to create another person.

The record has a workspace identity and an assigned contact number, with derived names for display and sorting. It holds personal information and owns collections such as contact points, communication preferences, custom values, and affiliations. A contact can exist without a classification, while a chosen Contact Type supplies a specific workspace category.

Why It Exists

Our reading is that association work needs a shared person identity because the same member can appear in many operational situations. Treating an employer name or e-mail address as the person would make changes of circumstance look like changes of identity. A continuing contact lets staff correct the information they know and preserves a reference for organizational relationships and other applications' work.

What It Is Not

A Contact is not a membership, a user account, or an organization. Calling a contact Member in the workspace's classification does not itself establish a membership entitlement. Platform security owns users and access, while a person record contains CRM information. A spouse reference is an interim personal connection, not a general household or person-relationship model. Archive is also separate from the person's business status.

What It Controls

The contact owns the information saved and validated with it, including affiliations and their role periods. Changing those owned values can change related organizational coverage through follow-up processing. Its name components determine derived names used by display and discovery. Contact Type influences effective presentation assignments; current primary affiliation supplies prominent organization and title context without excluding secondary affiliations.

Status affects ordinary selection, primary-e-mail reservation, and eligibility for new automatic roles under their capability contracts. Archive and locks impose separate availability and mutation constraints. A record version anchors edits, including system changes to the person, and committed differences supply attributed history. These effects have their authoritative rule homes in the corresponding capabilities rather than in the contact definition alone.

How It Is Used

The CRM Editor creates and corrects contacts, while the CRM Reader finds and inspects them. Create a member record and inspect the saved information follows entry through visible cards, service values, and history. Record an employer change while retaining the previous affiliation shows how a person keeps one identity while organizational context changes.

Good use distinguishes a correction from a duplicate creation and a current label from the full relationship history. Staff inspect a contact's current version before mutation and investigate source states on shared details. Integrations submit values under the same record rules; their channel does not make foreign references or stale edits acceptable.

Example

Ruth Kim joins a professional association while employed by Harbor Engineering and serving a regional chapter. Staff create one contact with those separate affiliations and appropriate communication details. A later employer change ends the Harbor tie and adds a new one without replacing Ruth's person identity. Her chapter role remains intelligible as a separate responsibility, and staff can inspect the former employer through past affiliations.

If Ruth's work address follows her firm's main address, its source is a relationship-backed link rather than a claim that Ruth independently owns that address. Source removal can mark it disconnected and require staff attention without creating a new person. The shared identity keeps this work together.

How It Relates

Affiliation joins the Contact to an Organization; Contact Role describes responsibilities within that tie. Contact Type classifies the person, and Contact Details and Communication Preferences explains how staff reach them and interpret instructions. Record Protection and History explains versions, locks, lifecycle actions, and revisions. Platform metadata owns custom field definitions, forms, layouts, and files; other applications own business records that reference the person.