Relationship
What It Is
A relationship describes a connection between records. Its type defines the two categories, labels in each direction and the constraints that apply. An individual link records the fact that particular records are connected, such as a contact crewing a boat during a period.
The same link can be read from either endpoint. Optional dates, a primary designation, position and notes add information to the connection. This model differs from a reference property, which names another record as a field value, and from CRM affiliations with their own domain-specific structure.
Why It Matters
Connections affect more than presentation. A boat can need one insurer during a period, a record can have one primary relationship and an owner’s deletion can affect dependent records. Defining those constraints once makes linked-record work consistent from either endpoint.
Dates also matter to correctness. An end date remains inclusive for occupancy, so the place does not become free merely because someone entered a future ending. Concurrent writers must not both acquire a restricted place that the definition allows only once.
How It Works
An administrator defines supported endpoints, cardinality, labels, optional dating and primary support, and a deletion policy for each side. The type’s structural choices are protected after creation. A used type deactivates instead of deleting its retained links; owner dependencies can prevent retirement.
A caller creates a link under an active type between compatible existing records. The service validates dates and occupancy and serializes competing place claims. Endpoint identity cannot be replaced on an existing link, while permitted attributes can be corrected with version and lock checks.
Ending requires a dated type and a valid span. Removing an open dated link records an ending; removing an already end-dated or undated link deletes it. Existing links can still be maintained after type deactivation, with their locks remaining effective.
What It Contains
The type, link, current occupancy, restricted place, endpoint deletion policies, ownership and merge treatment are its principal facets. Occupancy depends on the date span and type constraints, while historical links remain relevant to limits and inspection.
Detach removes the connection without removing the other record. Cascade removes dependent custom records through the deletion protocol. Restrict refuses deletion while a protecting link is current. Cascades have depth and lock safeguards and must not delete native contacts or organizations as dependants.
What It Is Related To
Record types define the endpoint categories. Custom objects can name an eligible relationship as their owner type. Custom records show links and retain applicable relationship changes in history. CRM deletion and merge invoke the shared endpoint protocol rather than treating these connections as private page content.
Merging duplicates redirects links and references to the survivor. Collisions, self-links and competing primary designations need corrective treatment, and the impact plan reports the movements and endings before application. These effects preserve relationships across data-quality work while retaining relevant revision context.
What Needs Deciding
The product should resolve the intended administrative boundary for relationship types and strengthen proof for deletion and merge effects that span services. Existing-link maintenance after type deactivation needs an explicit product decision. Before design extends the endpoint model, it should preserve the difference between defining a connection, recording it and applying its consequences to another record.