Starting November 20, the site will be set to read-only.
On December 4, 2023,
Apex Code Development (90768)
General Development (55146)
Visualforce Development (37251)
Lightning (18265)
APIs and Integration (17146)
Trailhead (11680)
Formulas & Validation Rules Discussion (11337)
Other Salesforce Applications (8116)
Jobs Board (6655)
Force.com Sites & Site.com (4842)
Mobile (2694)
You need to sign in to do that
Don't have an account?
sfdeveloper9 Is there a way to hide some opportunities from the related account owner.
Ex : Account1 - owner is John
Opty 1 - owner is John
Opty 2 - owner is Mike
Can we hide opty2 from John?
Thanks in Advance.
Did you figure it out yet? I had to play with this in my DE org, before I could come up with an answer that I was reasonably confident with. Here's what I think.
It depends on the account owner's Opportunity Access setting on their role, and the two user's relative placement in the role hierarchy. If John is above Mike in the role hierarchy, John will be able to see Mike's opportunity regardless of the Opportunity Access setting on his (John's) role. If John is at the same level or below Mike in the role hierarchy, and the Opportunity Access setting on John's role is set to "Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own", John will not be able to see Mike's opportunity. If the Opportunity Access on John's role is set to read or edit, John can access Mike's opportunity regardless of his relative position in the role hierarchy.
Ownership and record permissions are still a little dizzying for me, even after 6 years of full-time Salesforce administration.
In this case, John would not be able to see his opportunity eiter.
@sfdeveloper9
If you modify the account sharing rule for the Account, there is a field for Opportunity Access. Set that field to Private and John will only see his opportunities and Mike will only see Mike's....
John would not be able to see it as he has no access to the object.. (UI)
Now, he could access the data through the API, it would show up for him in APEX SOQL queries, etc, but the UI would not show it.
As for sharing rule, it is actually the opposite. OWD are the only way to RESTRICT access. Everything else grants access.
A few points of clarification:
Sharing rules affect DATA (SOQL, API, etc)
CRUD affects the UI.
As for your testing, not sure what you were testing, if you take away R,E,C,D (No Access) permissions for the Opportunity for a given role. Log in as that role and you will not even have an opportunity tab nor will you have a related list on the account page. Again, they may have access to the Data, but not to the UI that allows them to view the data.
As for the documentation, it is not in one spot and is pieced together. As with most salesforce documentation, much of it is speciifc but a lot has to be infered from multiple related pieces of information. I do have the Developer (DEV401 and 501) books that explicitly state such. Here is a link that may help as well:
https://login.salesforce.com/help/doc/en/security_data_access.htm
Take a step back, think it through a bit, and test it out. I guarentee you that if you remove CRUD for a profile for the opportunity the user with those permissions removed will NOT be able to access the oportunity through the UI. Depending on the sharing settings, they may be able to access the data through the API and Apex SOQL.
Starz26, please forgive me if you feel I'm coming across as argumentative. That's not my intention. That being said, I think you're wrong on this one.
Per the document you referenced:
"Sharing rules let you make automatic exceptions to organization-wide sharing settings for particular sets of users, to give them access to records they don't own or can't normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records—they can't be stricter than your organization-wide default settings."
I stand by my original reply, with one clarification. When I said "no access", I was not referring to object-level access, but rather the setting on an individual role where it says "Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own". Sorry if I caused some confusion with my lack of detail. I edited my original reply to compensate for this.
sfdeveloper9, please tell us if any of this is helping or not.
And my apologies for coming across in a negative manner. I should have clarified the "step back" comment. I meant that as in when I get frustrated with things like this, I have to step back and think a bit.. When I come back I usually get it pretty quickly.
And it appears we are both right just talking about different things.
Also, My comment above was incorrect, SFDC mantra is OWD is the only way to restrict access.....everything else adds additional access
I agree with you 100% that sharing, access, etc are all very confusing...
sfdeveloper9, it would appear you have two options:
1. Role Based: Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own
2. Profile Based: By setting the sharing setting of the opportunity on account to private.
This conversation has been a good one...
guys, thanks for the replies. But I am not able to still understand how to configure using sharing settings on role basis. can somebody please elaborate on that. And also my requirement changed a little bit.
Ex : Account1 - owner is John
Opty 1 - owner is John
Opty 2 - owner is Mike
John should be able to see opty2 but cannot edit.
Thanks in advance.
Do you already have a role hierarchy setup? If you don't, you should implement it. Setting up the role hierarchy is fairly simple, but it does take a little bit of planning on the front end, depending on how big your org is.
Here's a link to some of the help available on Salesforce.com: Controlling Access Using Hierarchies
Other than that, I would think that our previous comments would be enough information. If you already have these users assigned to roles in your hierarchy, you just have to specify the correct Opportunity Access setting on the appropriate role.
Also, I'm sure you already know this, but always do your configuration and testing in a sandbox, so you don't screw up any existing functionality. If you're implementing a new role hierarchy in an well-established instance (i.e. your users haven't been in a role hierarchy before), they might see some differences in the availability of records that they used to have access to, and these differences might cause you to have to do some training after you complete the changes.
Should Mike be able to see Opportunity 1 (Johns?)
https://success.salesforce.com/answers?feedtype=RECENT&criteria=BESTANSWERS#!/feedtype=SINGLE_QUESTION_DETAIL&dc=Security&criteria=OPENQUESTIONS&id=9063A000000DiD5QAK