Configure affiliation types and contact roles
Purpose
Staff need shared meanings for organizational ties and responsibilities before assigning them to people. This capability maintains the affiliation-type and contact-role catalogues, sets the default relationship type for the Organization command, and configures shared-detail mappings. It separates changing that vocabulary from rewriting relationships that already use it.
How It Works
Authorized users create or edit named roles and affiliation types with stable configuration identities. The supplied identity follows the configuration grammar and stays immutable. Contact roles can be ordered as a complete catalogue, while delete authority is separate from ordinary maintenance. Existing holders and organization-type policy references can block role deletion.
Affiliation types can carry same-kind address or phone mappings with distinct destination types. Omitted mappings on replacement remain; an explicit clearing value removes them. The workspace default initially uses Other and can be changed with separate administrator authority. Existing affiliations and the selected default block type deletion.
Deactivating an affiliation type retains its dataset columns with an inactive label. The description-editing requirement remains recorded as proposed behavior rather than being proved solely by the presence of configuration lists. Portal role-list reading has its own supported paged path.
Example
An administrator creates Member Firm with a mapping from organization main phone to contact work phone and selects it as the workspace default. A subsequent Organization command creates a tie of that kind. Deleting Member Firm is refused while it remains default or referenced. Switching the default and deactivating it retires new selection without rewriting the affiliations already bearing that meaning.
In the Member Firm configuration journey, the administrator inspects the new type and its main-phone-to-work-phone mapping before using it. A mapping with two sources targeting Work phone is refused rather than selecting whichever source happens to run last. Resetting the workspace default requires the dedicated set-default authority, so a role-catalogue editor cannot infer that authority from ordinary maintenance access. After the administrator selects the type, a coordinator's Organization command can create the corresponding tie. Changing the mapping later leaves that saved person's choices intact. The administrator verifies retirement by retaining existing affiliations and excluding the deactivated choice from new selection.
Why It Works This Way
Our reading is that immutable catalogue identities let a name or description improve without breaking references to the underlying business meaning. Reference-aware deletion protects historical holders and configured policies, which still need an understandable role or relationship type. Separate default authority limits a choice that influences later record work across the workspace.
Unique mapping destinations prevent two competing organization sources from trying to supply one contact slot. Same-kind checks keep address and phone purposes distinct. Preserving omitted mappings protects clients that do not administer that collection from silently clearing it. Deactivation offers retirement while retaining interpretability; it is not a promise that every saved-query execution path has been proven after retirement.
Relationships
Maintain a person’s organizational relationships uses the catalogue and workspace default. Shared contact points consumes default mappings only at its stated eligible moments. Role assignment and organization compliance consume Contact Role definitions. CRM Settings holds the default choice, and Platform datasets expose relationship columns. Catalogue route hosting does not transfer product ownership away from Entities.