CTAs know everything. And then there are moment when they don’t. Or they challenge documentation. Or just read the documentation differently. Or its different part. Or speak with someone else who read it differently.
Junction Object Security might be one of those small things, even though you probably rarely hit this question – what drives access to junction records?
Assumptions
As taken from Help, you can explain it in multiple ways.
Sharing access to a junction object record is determined by a user’s sharing access to both associated master records and the Sharing Setting option on the relationship field.
Looks like we need access to both parent records to have access to the child.
The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:
….
Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Owner field, this is only relevant if you later delete both master-detail relationships on your junction object.….
As sharing is driven by ownership maybe only access to the primary record might be enough.
Let’s find out.
What we have
- role hierarchy with two Child role and one Master;
- two users, each of them assigned to one Child role;
- one manager user, assigned as their boss;
- one system admin;
- two Master objects, both OWDs set to private;
- one Junction object.
Testing
Scenario 1
User 1 creates a new master & child records.
They are not visible to User 2, they are visible to Manager.
Scenario 2
User 1 creates both master records, system admin creates a new junction record.
They are not visible to User 2, they are visible to Manager and User 1.
Scenario 3
User 1 creates one master record, Manager second one plus junction record.
The record created by Manager is not visible to User 1, junction record is not visible to User 1 as well.
Scenario 4
User 1 creates both master records and junction record, shared the primary master record one with User 2 for Read Only access.
User 2 can see the shared master record, cannot see any junction object.
Scenario 5
Continuation of Scenario 4 – the second master record is shared with User 2 as well.
User 2 can see the same junction records as User 1.
Scenario 6
User 2 tries to edit junction records. The relationship is set for Read/Write on both relations, he has only Read access to the both records.
User 2 is not unable to save the record, he will get an error when saving. He cannot change any relation (User 1 can if they allow re-parenting).
Scenario 7
User 2 tries to edit junction records. The relationship is set for Read/Write on both relations, he has Read/Write on primary one, Read Only on the secondary one.
User 2 is not unable to save the record, he will get an error when saving.
Scenario 8
Continuation of Scenario 7 – the MD fields has Sharing Settings changed to Read Only, User 2 tries to edit junction record.
User 2 can edit junction record if its sharing is the same or higher as in Sharing Settings.
Scenario 9
Continuation of Scenario 4 – User 2 tries to create junction record.
User 2 is unable to save the record as he will get the following error.
Scenario 10
Continuation of Scenario 9 – primary parent record is shared with User 2 for Read/Write. User 2 creates junction record, where the second master record is not shared with User 1.
User 1 cannot see the new junction record.
Results
- you need access to both parent records to see the child;
- Sharing Settings on field definition can change results for savings/creating.