--- id: FEAT-CRM-ENT-06 title: Classification Types and CRM Settings product_area: crm module: entities revision: 1 status: approved product_intent: proposed source_sha: services-crm: 7ea48a414c42eade10d60753b8bcc323b1dd726f react-console: da63075876b2c5f4a6af07d457bb24ea8bf4c0c7 purpose: >- Administrators organize the classifications and defaults staff use. These choices help the workspace work with consistent categories and forms. outcomes: - Administrators organize the classifications and defaults staff use. concepts: - CON-CRM-ENT-007 - CON-CRM-ENT-008 - CON-CRM-ENT-004 - CON-CRM-ENT-005 - CON-CRM-ENT-020 actors: - ACT-CRM-001 - ACT-CRM-002 - ACT-CRM-003 - ACT-CRM-004 - ACT-CRM-005 acceptance: FAS-CRM-ENT-06 capabilities: - CAP-CRM-ENT-017 - CAP-CRM-ENT-018 - CAP-CRM-ENT-019 journeys: - JNY-CRM-ENT-004 related_concepts: - CON-CRM-ENT-003 - CON-CRM-ENT-001 - CON-CRM-ENT-002 - CON-CRM-ENT-033 approved_by: Andrew approved_at: 2026-10-22T00:00:00.000Z narrative: status: verified review: NARRATIVE-REVIEW-2026-10-23 narrative_sources: - section: Why It Exists provenance: inferred source: CAP-CRM-ENT-017; CAP-CRM-ENT-018; CAP-CRM-ENT-019 note: >- Operational consequences are the reviewer’s reading of the child contracts, not attributed historical motivation. The affiliation milestone supplies the current-membership distinction where named. - section: Decisions and Tradeoffs provenance: inferred source: "CAP-CRM-ENT-017; CAP-CRM-ENT-018; CAP-CRM-ENT-019" note: The tradeoffs interpret the child contracts; no historical motive is attributed. - section: How It Works provenance: observed source: >- services-crm:modules/entities/tests/e2e/affiliation-types.e2e.spec.js#answers 400 naming the field for a create whose name is nothing but spaces; services-crm:modules/entities/tests/e2e/affiliation-types.e2e.spec.js#answers 400 for an id that is not a configuration id, saying what an id may hold; services-crm:modules/entities/tests/integration/services/persistence/contact-roles.integration.spec.js#refuses it with the legacy words, naming the organization types whose rules depend on it; react-console:acceptance/crm/playwright/journeys/affiliations/CRM-ACC-0196.spec.ts#CRM-ACC-0196; services-crm:modules/entities/tests/e2e/affiliation-types.e2e.spec.js#refuses the delete (409) while an affiliation of a contact is of that type; services-crm:modules/entities/tests/e2e/affiliation-types.e2e.spec.js#refuses a caller who may only read affiliation types the change of the default (403); services-crm:modules/entities/tests/integration/services/persistence/affiliation-types.integration.spec.js#keeps the mappings, as an omitted collection means unchanged; services-crm:modules/entities/tests/e2e/contact-roles.e2e.spec.js#answers 400 for a reorder that leaves a role of the tenant out, naming it; services-crm:docs/milestones/CRM-M2-affiliations-roles-compliance.md#D-11; services-crm:modules/entities/tests/e2e/contact-roles.e2e.spec.js#answers a portal user of the tenant; react-console:acceptance/crm/playwright/journeys/affiliations/CRM-ACC-0199.spec.ts#CRM-ACC-0199; services-crm:modules/entities/tests/e2e/contact-types.e2e.spec.js#answers 400 naming the field for a create whose name is nothing but spaces; services-crm:modules/entities/tests/e2e/contact-types.e2e.spec.js#answers 400 for an id that is not a configuration id, saying what an id may hold; services-crm:modules/entities/tests/e2e/address-types.e2e.spec.js#says which records keep the type when it refuses the delete; services-crm:modules/entities/tests/e2e/contact-types.e2e.spec.js#answers 400 for a reorder that leaves a type of the tenant out; services-crm:modules/entities/tests/e2e/phone-number-types.e2e.spec.js#answers only the types usable on organizations when the query asks for them; services-crm:modules/entities/tests/e2e/address-types.e2e.spec.js#answers 403 to a read-only caller’s reorder; services-crm:modules/entities/tests/e2e/contact-types.e2e.spec.js#then, when the version is off, refuses the change (409); react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0033.spec.ts#CRM-ACC-0033; services-crm:modules/entities/tests/e2e/page-layouts.e2e.spec.js#is not answered the section it may not read: it is ABSENT, not null, so "forbidden" and "unset" never look alike; services-crm:modules/entities/tests/e2e/page-layouts.e2e.spec.js#writes NEITHER section for that refused save: the decision is made before anything is written; services-crm:modules/entities/tests/e2e/page-layouts.e2e.spec.js#refuses a save from a stale version (409); services-crm:modules/entities/tests/integration/services/persistence/crm-settings.integration.spec.js#refuses a definition of the wrong kind: a console form in the console page layout slot; services-crm:modules/entities/tests/e2e/page-layouts.e2e.spec.js#KEEPS all five through a PUT that does not mention them: an older client cannot wipe a tenant’s assignments; services-crm:modules/entities/tests/e2e/page-layouts.e2e.spec.js#falls back to the tenant’s default for a kind the type leaves empty; services-crm:modules/entities/tests/e2e/page-layouts.e2e.spec.js#is refused the tenant’s defaults (403): reading a record does not make one an administrator of layouts acceptance_suite: FAS-CRM-ENT-06 --- # Classification Types and CRM Settings ## Overview Classification Types and CRM Settings gives a workspace a shared vocabulary for its CRM records and relationships. Contact Type, Organization Type, Affiliation Type, and Contact Role explain different choices; they are not interchangeable labels. Address and phone types are facets of contact details that describe how a contact point is used. Settings connect those choices to defaults and presentation. Staff encounter the configured catalogue when choosing a record type or responsibility, and the effective form or layout can come from a type override or a workspace default supplied through Platform metadata. ## Why It Exists Our reading is that an association needs a shared vocabulary because coordinators work on the same identities and relationships. Member classifies a person, Chapter classifies a body, Employer describes a tie, and Billing Contact describes a responsibility. If those choices are treated as interchangeable free text, staff cannot reliably distinguish record presentation from relationship meaning or organizational expectations. Reusable definitions let the workspace configure those meanings once and refer to them from many records. Defaults also reduce repeated decisions during entry, while type-specific assignments can supply different presentation where the baseline is insufficient. A configuration change still needs boundaries: retiring a used category must preserve existing interpretation, and changing a sharing default must not silently replace choices already made on individual people. ## Who Uses It The CRM Administrator maintains catalogue order, address and phone applicability, workspace defaults, and form or layout assignments. The CRM Editor uses those choices during record work and can perform catalogue operations where the formal permissions allow it. The CRM Reader retrieves authorized classifications, while the CRM System resolves effective assignments and the Data Importer references existing categories. ## How It Works An authorized user creates or edits a classification with a stable configuration identity and a name. Catalogue order and active choices shape selection; records retaining an inactive classification keep their meaning. Deletion checks references, so retiring a used choice differs from removing an unused definition. Affiliation types can carry default address and phone mappings, and a workspace default supplies the type used by the Organization command. Contact and organization types can name Platform forms and layouts. Resolution considers the relevant type override before the workspace default for each slot, and authorized settings reads omit sections the caller cannot read rather than confusing them with unset values. The five business concepts influence different parts of staff work. Contact Type classifies a person and can select that person's forms, layouts and cards. Organization Type classifies a body and supplies the role restrictions and compliance expectations used by neighboring capabilities. Affiliation Type describes the connection and can offer default address and phone links when an eligible connection is added. Contact Role describes the responsibility held through that connection; compliance and notification recipient selection consume it. CRM Settings holds workspace choices that apply when a more specific assignment does not supply an answer. Presentation resolves each slot independently. A Member type can override a console page layout while inheriting the workspace's form. Clearing a type assignment means inheritance rather than a command to show nothing. An untyped record also uses workspace defaults. If neither level provides a usable definition, the response states that none is configured. Asking for an unknown type is refused instead of silently answering for an untyped record. CRM chooses Platform definitions of the appropriate kind and purpose; it does not author a competing form or layout language. Administration begins by reading the current catalogue or settings version. The caller saves permitted changes, and a stale version refuses them. A reorder supplies the complete list so an omitted choice cannot disappear into an ambiguous position. Settings authority is divided between the contact and organization sections; an unauthorized section is omitted from a read, and a mixed unauthorized save writes neither section. Ordinary record readers can resolve what a record uses without acquiring permission to administer defaults. Retirement preserves meaning. Existing contacts can retain inactive types even when new-contact choices exclude them. References block hard deletion of used classifications. Address and phone applicability distinguishes person and organization purposes, while existing contact-point entries have their documented retention boundary after applicability changes. Changing affiliation sharing defaults affects later eligible applications, not every previously saved person. ## Examples An administrator creates a Member Firm affiliation type with mappings from a firm's billing address and main phone to a person's work details, then makes it the default. A later Organization command uses that type. If the vocabulary changes, deactivating Member Firm preserves existing ties; deletion remains blocked while those ties or the workspace default reference it. The association configures a workspace contact form and assigns a different console page layout to Member. Ruth's Member record can therefore resolve a type-specific page and an inherited form. The administrator inspects the effective definitions before asking coordinators to use them; changing only the layout does not imply the form changes too. A colleague who saves settings from an older version is refused and rereads the current assignments before making another change. For a chapter, the administrator chooses an Organization Type whose allowed roles and compliance expectations differ from a member firm. Coordinators then select the corresponding responsibilities on chapter affiliations. The Member Firm affiliation type still supplies the shared-detail defaults for firm relationships; it is not the chapter's Organization Type or Ruth's Contact Type. If Member Firm is retired, existing ties keep their meaning. Deletion while it is default or referenced is refused, so the administrator changes the default and deactivates it instead of removing historical interpretation. ## Decisions and Tradeoffs Our reading is that separating classifications avoids making one catalogue label control unrelated business questions. A contact category cannot substitute for a relationship meaning or responsibility. Stable identities permit renamed vocabulary without forcing record rewrites, while reference checks preserve the meaning of retained information. Per-slot fallback combines workspace consistency with selective exceptions. Requiring a full type-specific copy of every assignment would make a simple layout exception duplicate configuration that should still follow the baseline. Permission-section omission distinguishes lack of authority from an unset value; atomic refusal protects against partially applying a mixed save. These explanations interpret the observed contracts. They do not convert inherited forms into product-approved workflow or grant new administration authority. ## Scope and Boundaries Entities owns these CRM catalogues and their assignments, even where a separate configuration service function serves the routes. Platform metadata owns custom field definitions, forms, and layouts; CRM selects those definitions rather than duplicating them. Organization Compliance owns assessment, and Contact Details and Communication Preferences owns the meaning of values and shared-source states. ## Outcomes Staff use consistent categories and administrators can configure presentation without rewriting every record. The Classification Types and CRM Settings acceptance suite exercises catalogue use, reference-safe retirement, defaults, and effective definitions. Configure an affiliation type and use it on a contact demonstrates how one administration choice reaches subsequent contact work without changing existing affiliations retroactively. ## Its Capabilities Configure affiliation types and contact roles maintains the relationship vocabulary and default mappings. Organize the workspace’s record classifications maintains record and contact-point types with reference and ordering safeguards. Resolve the forms and layouts used for CRM records chooses effective Platform definitions from type assignments and workspace defaults. The configuration journey follows those choices into contact editing.