What is a junction object?

A junction object in Salesforce is a custom object whose only purpose is to connect two other objects in a many-to-many relationship. It carries two master-detail fields, one pointing to each side, plus any attributes that describe the pairing itself (status, role, dates, quantities). Each row of the junction object represents exactly one link between one record on the left and one record on the right.

The minimum structure

A pure junction object has, at minimum:

Custom Object: Course_Enrollment__c
  ├── Name (autonumber or composite)
  ├── Master-Detail #1 → Student__c     (primary master)
  ├── Master-Detail #2 → Course__c      (secondary master)
  └── Optional fields about the pairing:
        Enrolled_Date__c
        Status__c
        Grade__c

The Name field is often auto-number (ENR-{0000}) because the junction usually doesn’t have a meaningful “name” of its own — its identity is the pair.

Primary vs secondary master — what changes

When you create the junction, the order in which you add the two master-details matters:

This is why senior architects pick the primary master deliberately — usually the side whose owner and access logic should govern the junction.

When the junction is the right pattern

You need a junction object whenever the relationship is many-to-many and you might need:

• To capture per-pair attributes (grade, role, status, quantity).
• To run reports across all pairings.
• To enforce uniqueness on the pair (e.g., a student can only enroll in a given course once).
• Roll-up summaries on either side counting or summing junction-level data.

If the relationship is one-to-many or zero-to-many, you don’t need a junction — a single lookup or master-detail on the child suffices.

Real-world examples

Common admin-scenario question

“You created a junction object Student_Class__c with two master-detail relationships. Why might a student appear twice in the same class on the related list?”

Almost always: no uniqueness constraint on the pair. The data model allows it. To prevent duplicate enrollments:

1. Create a custom Text formula field on the junction concatenating the two master IDs: Student__c & '-' & Class__c.
2. Mark that field as Unique (External ID optional but commonly paired).
3. Salesforce now rejects any duplicate (student, class) pair at the database layer — no trigger required.

This is a frequent senior-admin interview pattern: the candidate proposes a trigger or validation rule, the interviewer pushes them toward the declarative unique-formula-field approach.

Junction-object limits

• The junction is a regular custom object — so it counts against your custom object limit per edition.
• Two master-details means the junction inherits both cascade-delete behaviors.
• The junction has no OwnerId field (master-detail children never do — owner is inherited from primary master).
• Roll-up summaries can be defined on either master object, pulling from the junction’s fields.
• The junction object’s OWD is locked to “Controlled by Parent” — the primary parent’s parent.

Lookup-based junction — when the pattern bends

A junction with two lookups instead of master-details is sometimes used when:

• The junction must have its own owner (sharing the pair independently).
• The junction should survive deletion of either side (audit trail of past relationships).
• Both sides might be missing during a data migration phase.

Trade-offs: no roll-up summaries on either master, sharing is independent, junction rows persist even if a master is deleted. Most orgs use the master-detail pattern by default and only fall back to lookup-based junctions when the requirements force it.

Verified against: Salesforce Help — Create a Many-to-Many Relationship and the Sharing & Visibility Architect resources. Last reviewed 2026-05-17.