Last night, I almost drove myself mad over something that, honestly, I thought I had already mastered. I kept asking myself, “Why can’t this be done using sharing rules?” 😂🤏
The task required creating a Student custom object and controlling who could create, read, update, or delete student records. At first, it felt logical that sharing rules should handle this. However, after revisiting the requirement, it finally clicked that the task was specifically about object-level permissions, not record visibility.
That was the moment the formula made sense:
PROFILE → Object-level access (Create, Read, Edit, Delete)
SHARING RULES → Record-level access (which records users can see or edit)
PERMISSION SETS → Additional access layered on top of the profile
Once I understood this separation, it became clear why the solution required profiles (Student Manager and Student Viewer) rather than sharing rules. Sharing rules can only extend access to records after object-level permissions have already been granted... they cannot define create, edit, or delete rights.
A simple concept, but a powerful reminder that Salesforce security works in layers, and each layer has a distinct role.