A one-to-one (1:1) relationship means each record on object A relates to exactly one record on object B, and each record on B relates to exactly one record on A. Salesforce does not provide a native 1:1 field type — all relationship fields (Lookup, Master-Detail) are inherently one-to-many. To model 1:1 you combine a relationship field with uniqueness constraints.
When 1:1 makes sense
Most CRM models don’t actually require strict 1:1 — most “1:1-looking” data is better stored as fields on the same record. But genuine 1:1 use cases include:
- Account ↔ External Vendor Profile — one extension record per Account when you want to keep optional / rarely-used fields in a separate object to keep the main object lean
- Employee ↔ Compensation Record — sensitive comp data in a separate object with tighter sharing, but exactly one comp record per employee
- Contact ↔ Contact Preferences — large preference data split into its own object
- Order ↔ Shipment — when business rule guarantees one shipment per order
When you find yourself with optional fields, sensitive fields, or fields that fill up only a small percentage of rows on a wide object, 1:1 is a reasonable normalization.
Why Salesforce doesn’t have a “1:1” type
A relationship in Salesforce is technically a column on the child object holding the parent’s Id. There’s nothing in the schema that says “no two child rows can share the same parent Id” — that’s a uniqueness constraint. So Salesforce implements 1:1 as lookup + uniqueness, not as a distinct relationship type.
The standard pattern
To enforce 1:1 between Parent__c and Child__c:
- Create a relationship field (Lookup or Master-Detail) on
Child__cpointing toParent__c. - Make the field Unique if it’s a Text/Number — but relationship fields can’t be marked Unique in the field properties. So you use one of the workarounds:
- Validation rule on
Child__cthat fires before insert/update if anotherChild__calready has the same Parent_Id - Trigger on
Child__c(before insert/update) that queries for existing siblings - Duplicate Management rule with matching on the lookup field
- Validation rule on
The validation-rule path is the most common admin solution; the trigger path scales better for bulk loads.
Properties of the result
Once enforced:
- Each parent has at most one child
- Each child has exactly one parent (if the relationship is required)
- Reports can join the two like normal master-detail/lookup
- Both sides retain their own ownership (unless master-detail) and lifecycle
1:1 vs putting it all on one object — the trade-off
| Pattern | Pros | Cons |
|---|---|---|
| Everything on one object | Simpler, no joins, default sharing applies uniformly | Object gets wide (field limits), all fields share OWD, page layouts bloat, sensitive data harder to isolate |
| 1:1 split | Narrow objects, separate sharing for sensitive data, optional fields don’t clutter main record | More complex queries, must enforce 1:1 yourself, two records to maintain |
The split is worth it when sharing differs (sensitive data) or when the secondary record is genuinely optional and rare.
Compared to other cardinalities
| Cardinality | Field | Enforcement |
|---|---|---|
| 1:1 | Lookup or Master-Detail | + uniqueness rule (validation/trigger) |
| 1:Many | Lookup or Master-Detail | Default |
| Many:Many | Junction object with 2 M-Ds | Default |
| Self | Lookup pointing to same object | Default; cycle-prevention up to you |
What this question usually leads to
Interviewers commonly follow up with: “OK, then how do you actually achieve 1:1 in Salesforce?” — and the expected answer is the uniqueness-rule / trigger pattern described above, which has its own question and full implementation in the inventory.
Verified against: Salesforce Help — Object Relationships Overview. Last reviewed 2026-05-17.