Really great job... you've managed this to look simple, despite all possibilities and overlaps! Everyone should watch this video before working with security related topics in SF!
Thanks so much! We definitely take security seriously and are always recommending upgraded protocols. Let us know if there are any other topics we should cover next.
Please make more instructional videos! Thank you so much for this one, very very informative. This topic is always absolutely confusing to those who are starting out.
I had Read, Edit, and View all access for Opportunities for a profile but when I created a conditional sharing rule to make certain opportunity records read only for users in the profile which I put in a public group they were still able to edit those records. What am I doing wrong?
Hi Black Phillip. The reason for that is because Sharing Rules can never reduce sharing, they can only add sharing beyond what a user already has. Because the profile already grants edit access, the sharing rule can't restrict it down to read-only if they already have access to these records based on sharing defaults. So, you also need to look at your Sharing defaults for Opportunity - is it public or private? The question you have to ask is: "what can these users already do before I created this sharing rule?". If the answer is that they can already edit these opportunities, then the sharing rule can't take that away. If they can't already edit these opportunities, then the sharing rule should be extending the "Read-only" access as you describe. But, I have a hunch that you are expecting the sharing rule to perform a conditional restriction and not a conditional extension. The bottom line is that your baseline from profiles, permissions and sharing defaults should always result to the strictest behavior, and then sharing can be extended beyond that behavior using sharing rules. I hope this helps.
@@leedssource I understand it now. If you had edit access at the profile level but no sharing rule it would go by the OWD for records you don't own and go by the profile for records you do own unless you select view all or modify all which would affect access to all records. Also OWD and Sharing rules can't have access greater than your Profile level of access. So if the OWD for opportunities is read only, a sharing rule can open that up to read/edit for the records governed by OWD (i.e. records you don't own) as long as you have edit access for the object at the profile level.
Definitely a very clear explanation. Thank you.
you are the best SF trainer.
Best till date on this topic
Really great job... you've managed this to look simple, despite all possibilities and overlaps! Everyone should watch this video before working with security related topics in SF!
Thanks so much! We definitely take security seriously and are always recommending upgraded protocols. Let us know if there are any other topics we should cover next.
Finally, this Salesforce sluster-F is explained in English which you can understand. Thank you, man!
You are very welcome!!
So much respect for you, your way of expalining is awsome.
Thanks, we appreciate that!
Thank you so much. This is so clear, i needed this explination.
One of the best videos I've come across on this subject, love how you peel the layers and help us visualize the overlaps.
Thank you so much, you have put really commendable effort!
Awesome, helpful. I feel knowledgable now :)
Great video, very helpful !!
Please make more instructional videos! Thank you so much for this one, very very informative. This topic is always absolutely confusing to those who are starting out.
Great video, thank you!
So glad you enjoyed it! We're working on more videos this month - let us know if there is a topic you'd recommend us covering next!
super!
I am so glad that I found your videos! Please keep creating great content. Thank you! 🙏
Thank you!!
Best explanation I've seen on here of the model
I had Read, Edit, and View all access for Opportunities for a profile but when I created a conditional sharing rule to make certain opportunity records read only for users in the profile which I put in a public group they were still able to edit those records. What am I doing wrong?
Hi Black Phillip. The reason for that is because Sharing Rules can never reduce sharing, they can only add sharing beyond what a user already has. Because the profile already grants edit access, the sharing rule can't restrict it down to read-only if they already have access to these records based on sharing defaults. So, you also need to look at your Sharing defaults for Opportunity - is it public or private? The question you have to ask is: "what can these users already do before I created this sharing rule?". If the answer is that they can already edit these opportunities, then the sharing rule can't take that away. If they can't already edit these opportunities, then the sharing rule should be extending the "Read-only" access as you describe. But, I have a hunch that you are expecting the sharing rule to perform a conditional restriction and not a conditional extension. The bottom line is that your baseline from profiles, permissions and sharing defaults should always result to the strictest behavior, and then sharing can be extended beyond that behavior using sharing rules. I hope this helps.
@@leedssource I understand it now. If you had edit access at the profile level but no sharing rule it would go by the OWD for records you don't own and go by the profile for records you do own unless you select view all or modify all which would affect access to all records. Also OWD and Sharing rules can't have access greater than your Profile level of access. So if the OWD for opportunities is read only, a sharing rule can open that up to read/edit for the records governed by OWD (i.e. records you don't own) as long as you have edit access for the object at the profile level.
Exactly right.