Sharing Rules in salesforce:
1. What are different levels of security in salesforce?
2. What is Organization wide default?
OWD stands for Organization wide defaults. This setting is defined at object level. OWD defined the default record level sharing for objects. All profiles get at least the privileges defined in OWD. OWD takes three different values -
Most restrictive record access is defined using OWD. Access to additional records is made available through Role hierarchy, Sharing rules, Manual sharing.
3. What is role hierarchy?
Role Hierarchy allows additional users access to records. A hierarchy of roles is defined based upon access requirements at record level. Each user belongs to a unique role. If a role has access to some record, than its parent and ancestors will also have access to this record. Roles can be created using the Manager Users menu. Roles are used to control record access, where as profiles are used to specify access at object and field level.
4. What is public group?
Public group consists of users, roles or "roles and subordinates". Sharing rule is defined using public groups. Record that match certain condition can be assigned to users in public groups using Sharing Rules. Sharing rules functionality is available via the menu Sharing Settings.
5. What is manual sharing (User Managed Sharing)?
Manual Sharing is used to grant one-off access. Manual sharing can be granted by record owner, any one above the owner in role hierarchy and System Administrator. Manual sharing is used to handle exception cases where access to a particular record needs to be given to a specific user. There is a Sharing button on the records page. This is used to provide manual sharing.
- Object level security
The bluntest way that we can control data is by preventing a user from seeing, creating, editing, and/or deleting any instance of a particular type of object, like a Position or Review. Object-level access allows us to hide whole tabs and objects from particular users, so that they don't even know that type of data exists.
On the platform, we set object-level access rules with object permissions on user profiles.
- Field level security
A variation on object-level access is field-level access, in which a user can be prevented from seeing, editing, and/or deleting the value for a particular field on an object. Field-level access allows us to hide sensitive information like the maximum salary for a position or a candidate's social security number without having to hide the whole object.
On the platform, we set field-level access rules with the field-level security.
- Record level security
To control data with a little more finesse, we can allow particular users to view an object, but then restrict the individual object records that they're allowed to see. For example, record-level access allows an interviewer like Melissa Lee to see and edit her own reviews, without exposing the reviews of everyone else on her team.
On the platform, we actually have four ways of setting record-level access rules:
- Organization-wide defaults
- Role hierarchies
- Sharing rules
- Manual sharing
2. What is Organization wide default?
OWD stands for Organization wide defaults. This setting is defined at object level. OWD defined the default record level sharing for objects. All profiles get at least the privileges defined in OWD. OWD takes three different values -
A. Private
B. Public Read only
C. Public Read-Write
To find out what should be set as OWD for an object, first find out which user requires least access to an object. OWD is set based upon this users access requirements.Most restrictive record access is defined using OWD. Access to additional records is made available through Role hierarchy, Sharing rules, Manual sharing.
3. What is role hierarchy?
Role Hierarchy allows additional users access to records. A hierarchy of roles is defined based upon access requirements at record level. Each user belongs to a unique role. If a role has access to some record, than its parent and ancestors will also have access to this record. Roles can be created using the Manager Users menu. Roles are used to control record access, where as profiles are used to specify access at object and field level.
4. What is public group?
Public group consists of users, roles or "roles and subordinates". Sharing rule is defined using public groups. Record that match certain condition can be assigned to users in public groups using Sharing Rules. Sharing rules functionality is available via the menu Sharing Settings.
5. What is manual sharing (User Managed Sharing)?
Manual Sharing is used to grant one-off access. Manual sharing can be granted by record owner, any one above the owner in role hierarchy and System Administrator. Manual sharing is used to handle exception cases where access to a particular record needs to be given to a specific user. There is a Sharing button on the records page. This is used to provide manual sharing.
6. When Share button will be available on record detail page?
When OWD for object is “Public Read Only” or “Private”.
If OWD is Public Read-Write, then everyone in org have access to all records of object.
7. How to check whether user has access to a particular record or not?
Query “userRecordAccess” to check whether has access to record or not.
For example:
SELECT RecordId, HasReadAccess, HasTransferAccess, MaxAccessLevel, HasAllAccess, HasDeleteAccess, HasEditAccess FROM UserRecordAccessWHERE UserId = “005xxxxxxxxx”AND RecordId = “001xxxxxxxx”
HasAllAccess Indicates whether a user has all access–read, edit, delete, and transfer—to the record (true) or not (false).
HasReadAccess, HasEditAccess , HasDeleteAccess ,HasTransferAccess return Boolean value.
MaxAccessLevel return access level like None, read, Edit,Delete,Transfer and All.
8. What will happen if a field is hidden through Field level security and user search a values in that field?
Field-level security doesn’t prevent searching on the values in a field. When search terms match on field values protected by field-level security, the associated records are returned in the search results without the protected fields and their values.
9. What does “View all” and “Modify all” permission do at object level?
10. If object-level permissions conflict with record-level permissions, then what will happen?
If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.
When OWD for object is “Public Read Only” or “Private”.
If OWD is Public Read-Write, then everyone in org have access to all records of object.
7. How to check whether user has access to a particular record or not?
Query “userRecordAccess” to check whether has access to record or not.
For example:
SELECT RecordId, HasReadAccess, HasTransferAccess, MaxAccessLevel, HasAllAccess, HasDeleteAccess, HasEditAccess FROM UserRecordAccessWHERE UserId = “005xxxxxxxxx”AND RecordId = “001xxxxxxxx”
HasAllAccess Indicates whether a user has all access–read, edit, delete, and transfer—to the record (true) or not (false).
HasReadAccess, HasEditAccess , HasDeleteAccess ,HasTransferAccess return Boolean value.
MaxAccessLevel return access level like None, read, Edit,Delete,Transfer and All.
8. What will happen if a field is hidden through Field level security and user search a values in that field?
Field-level security doesn’t prevent searching on the values in a field. When search terms match on field values protected by field-level security, the associated records are returned in the search results without the protected fields and their values.
9. What does “View all” and “Modify all” permission do at object level?
- When you grant “View All” or “Modify All” for an object on a profile or permission set, you grant any associated users access to all records of that object regardless of the sharing and security settings.
- In essence, the “View All” and “Modify All” permissions ignore the sharing model, role hierarchy, and sharing rules that the “Create,” “Read,” “Edit,” and “Delete” permissions respect. Furthermore, “Modify All” also gives a user the ability to mass transfer, mass update, and mass delete records of that specific object, and approve such records even if the user is not a designated approver.
- These tasks are typically reserved for administrators, but because “View All” and “Modify All” let us selectively override the system, responsibilities that are usually reserved for the administrator can be delegated to other users in a highly controlled fashion.
If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.
- If a user’s profile grants him update permission on an object, he will not be able to edit records of that type owned by other users unless read/write record-sharing has been granted.
- If read/write sharing has been granted, a user whose profile does not specify update permission will not be able to edit records of that type.
11. What will happen if profile related to user U1 above in role hierarchy doesn’t have CRUD permission for object say A. User U2 below in his role hierarchy have CRUD permission to object A. Will user U1 will be able to see or edit record if Grant Access Using Hierarchies is checked for object A in sharing settings?
No.If a user does not have read or edit access to an object via OWD, a profile or permission set, they will have no visibility over an object regardless of their role and role hierarchy.
Always remember that User above in role hierarchy can see records of users below in hierarchy but operation which he can perform depends on permission on his profile (CRUD & View All & Modify All).
12. What is permission Set?
A permission set is a collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles.
For example, to give users access to a custom object, create a permission set, enable the required permissions for the object, and assign the permission set to the users. You never have to change profiles, or create a profile for a single use case. While users can have only one profile, they can have multiple permission sets.
13. Is it possible to restrict permission for users using permission set?
No. Permission Set always extends the permission.
14. If you have two record types for an object, do you need to have two page layouts for that objects?
No. It is not required but if user want different UI for different record type then we can create 2 different page layout and assign page layout to profiles based on record type.
15. If a user does not have access to a specific record type, will they be able to see the records that have that record type?
Yes. Record type controls only visibility of record on UI not its access to users.
16. True or False: A field hidden by field-level security is still visible through the API?
False
17. True or False: Child records in master-detail relationships have their own OWD?
False. In Master detail relationship, child inherit OWD from OWD. If you see OWD for child in master detail relationship, then system will display “Controlled by parent” in OWD settings page.
Child in look up relationship have different OWD as they are loose coupled.
18. If even one person in your organization is not allowed to see position data, what will be OWD ?
Private
19. What is apex manage sharing?
Apex managed sharing is a type of "Programatic Sharing" which allows you to define a custom sharing reason to associate with your programatic share. Standard Salesforce objects support "Programatic Sharing" while custom objects support Apex managed sharing. More specifically, object shares can be written to both standard and custom objects, however custom sharing reasons can only be defined for shares written to custom objects.
apex manage sharing is used for custom objects as we can define apex sharing reason for custom objects. For standard object, apex sharing reason will be “Mannual”.
Salesforce create share table for all objects for which OWD is either public read only or Private. For standard object, share table name is table name followed by share word. For example: AccountShare, ContactShare, CaseShare
For custom object, it is followed by __share. For example : For Position__c, share table name is Position__share
20. How to create share table record using apex?
Share table contains four columns: ParentId, UserOrGroupId, RowCause, AccessLevel.
Below is code to create position__share record:
21. Can we define apex sharing reason for standard object?
No. We can define apex sharing reasons for custom object.
Apex sharing reasons are defined object by object. - so, positions might have different reasons than candidates.
False
17. True or False: Child records in master-detail relationships have their own OWD?
False. In Master detail relationship, child inherit OWD from OWD. If you see OWD for child in master detail relationship, then system will display “Controlled by parent” in OWD settings page.
Child in look up relationship have different OWD as they are loose coupled.
18. If even one person in your organization is not allowed to see position data, what will be OWD ?
Private
19. What is apex manage sharing?
Apex managed sharing is a type of "Programatic Sharing" which allows you to define a custom sharing reason to associate with your programatic share. Standard Salesforce objects support "Programatic Sharing" while custom objects support Apex managed sharing. More specifically, object shares can be written to both standard and custom objects, however custom sharing reasons can only be defined for shares written to custom objects.
apex manage sharing is used for custom objects as we can define apex sharing reason for custom objects. For standard object, apex sharing reason will be “Mannual”.
Salesforce create share table for all objects for which OWD is either public read only or Private. For standard object, share table name is table name followed by share word. For example: AccountShare, ContactShare, CaseShare
For custom object, it is followed by __share. For example : For Position__c, share table name is Position__share
20. How to create share table record using apex?
Share table contains four columns: ParentId, UserOrGroupId, RowCause, AccessLevel.
Below is code to create position__share record:
Position__share p = new Position__share();
p.parentId = ‘Position Record Id which needs to be shared’;
p.userOrGroupId= ‘User id or Group id with which we want to share record’;
p.RowCause=’ apex sharing reason defined for custom object, here for position__c’;
p.AccessLevel =’access level for record’; //can be Read or Edit
insert p;
Note: you cannot update share table record. System only allows insert or delete of records for share table. So if you have to change access for user, you have create new record and can delete already existing record if you want.p.parentId = ‘Position Record Id which needs to be shared’;
p.userOrGroupId= ‘User id or Group id with which we want to share record’;
p.RowCause=’ apex sharing reason defined for custom object, here for position__c’;
p.AccessLevel =’access level for record’; //can be Read or Edit
insert p;
21. Can we define apex sharing reason for standard object?
No. We can define apex sharing reasons for custom object.
Apex sharing reasons are defined object by object. - so, positions might have different reasons than candidates.
Sharing Records with Manager Groups
While leaving manager how transfer to other manager in sales force:
Share records up or down the management chain using sharing rules or manual sharing.
The role hierarchy controls the level of visibility that users have into your organization’s data. With Spring ’15, you can use manager groups to share records with your management chain, instead of all managers in the same role based on the role hierarchy. Manager groups can be used wherever other groups are used, such as in a manual share or sharing rule. But they cannot be added to other groups and don’t include portal users. Manager groups can contain Standard and Chatter Only users only.
Every user has two manager groups—Managers Group (1) and Manager Subordinates Group (2)— where (1) includes a user’s direct and indirect managers, and (2) includes a user and the user’s direct and indirect reports. On a sharing rule setup page, these groups are available on the Share with drop-down list.
To find out who a user’s manager is, from Setup, enter Users in the Quick Find box, then select Users. Click a user’s name. The Manager field on the user detail page displays the user’s manager.
To enable users to share records with the manager groups, follow these steps.
- From Setup, enter Sharing Settings in the Quick Find box, then select Sharing Settings.
- On the Sharing Settings page, click Edit.
- In Other Settings, select Manager Groups and then click Save.
NOTE You can’t disable manager groups if your organization uses Work.com or have any sharing rules that uses manager groups.
With manager groups, you can share records to these groups via manual sharing, sharing rules, and Apex managed sharing. Apex sharing reasons is not supported. For Apex managed sharing, include the row cause ID, record ID, and the manager group ID. For more information, see the Lightning Platform Apex Code Developer's Guide.
Inactive users remain in the groups of which they are members, but all relevant sharing rules and manual sharing are retained in the groups.
NOTE If your organization has User Sharing enabled, you can’t see the users whom you don’t have access to. Additionally, a querying user who doesn’t have access to another user can’t query that user’s groups.
EXAMPLE You might have a custom object for performance reviews whose organization-wide default is set to Private. After deselecting the Grant Access Using Hierarchies checkbox, only the employee who owns the review record can view and edit it. To share the reviews up the management chain, administrators can create a sharing rule that shares to a user’s Managers Group. Alternatively, the employee can share the review record with the user’s Managers Group by using manual sharing.
How to restrict sharing access in Salesforce?
We often heard that business would like to restrict x number of users to access Account, while open it to rest of users. How we can do that in Salesforce?
However in Salesforce, it is the other way round. You need to specify who can access an object, NOT about who cannot access an object.
If your company decide not to give access to anyone in company (to view or edit an object), Organization-Wide Defaults (OWD) should be set to Private, then add sharing rule for that object based on: Criterias, Public Groups, Roles or 'Roles and Subordinates'.
If OWD is set to Private or Public Read-Only. It will be shared in following rule:
To investigate who can access a record, system admin can click on 'Sharing' button in record detail. Then, click 'Expand List' to get more details on user being shared and why they being shared.
However in Salesforce, it is the other way round. You need to specify who can access an object, NOT about who cannot access an object.
If your company decide not to give access to anyone in company (to view or edit an object), Organization-Wide Defaults (OWD) should be set to Private, then add sharing rule for that object based on: Criterias, Public Groups, Roles or 'Roles and Subordinates'.
If OWD is set to Private or Public Read-Only. It will be shared in following rule:
- Role Hierarchy, any user in higher role hierarchy of record owner will be able to access the record
- Sharing Rule, any user and user in higher role hierarchy of users being shared in Sharing Rule will be able to access the record
- Manual Sharing, owner or user in higher role hierarchy of record owner, will be able to share records owned.
To investigate who can access a record, system admin can click on 'Sharing' button in record detail. Then, click 'Expand List' to get more details on user being shared and why they being shared.
Salesforce sharing button
Sharing is a nice feature in Salesforce to share a record to other user, particularly when 'Organization-Wide Defaults' is set to Private or 'Public Read Only'.
By clicking Sharing button, you’ll see who can see that record and why (sharing rule, group, role hierarchy, manual share etc).
The Sharing button allows users to extend the sharing of a record such as a lead, opportunity, or case. However, the Sharing button only displays when appropriate.
The Sharing button is available when your sharing model is either Private or Public Read Only for a type of record or related record. For example, the Sharing button may appear on an account even though your sharing model for accounts is Public Read/Write if your sharing model for related opportunities is Public Read Only.
But, sometimes Sharing button is not shown for particular user, while administrator able to see the button in the same page layout. So many admins think, user not able to see the button because user do not have permission set in the profile assigned, and this is not correct.
Sharing button only will be shown if user fulfill following criteria:
- administrator
- the record owner
- users in a role hierarchy above the record owner, and
- users that has been granted with “Full Access” sharing
If user is not one of them, he/she will not see the button, although user able to access the record.
Furthermore, sharing is disabled if the sharing model is set to "Controlled By Parent", which happens when you create a master-detail relationship.
Lastly, you cannot manually share a contact which not linked to an account.
Sharing is a nice feature in Salesforce to share a record to other user, particularly when 'Organization-Wide Defaults' is set to Private or 'Public Read Only'.
By clicking Sharing button, you’ll see who can see that record and why (sharing rule, group, role hierarchy, manual share etc).
The Sharing button allows users to extend the sharing of a record such as a lead, opportunity, or case. However, the Sharing button only displays when appropriate.
The Sharing button is available when your sharing model is either Private or Public Read Only for a type of record or related record. For example, the Sharing button may appear on an account even though your sharing model for accounts is Public Read/Write if your sharing model for related opportunities is Public Read Only.
But, sometimes Sharing button is not shown for particular user, while administrator able to see the button in the same page layout. So many admins think, user not able to see the button because user do not have permission set in the profile assigned, and this is not correct.
Sharing button only will be shown if user fulfill following criteria:
- administrator
- the record owner
- users in a role hierarchy above the record owner, and
- users that has been granted with “Full Access” sharing
If user is not one of them, he/she will not see the button, although user able to access the record.
Furthermore, sharing is disabled if the sharing model is set to "Controlled By Parent", which happens when you create a master-detail relationship.
Lastly, you cannot manually share a contact which not linked to an account.
By clicking Sharing button, you’ll see who can see that record and why (sharing rule, group, role hierarchy, manual share etc).
The Sharing button allows users to extend the sharing of a record such as a lead, opportunity, or case. However, the Sharing button only displays when appropriate.
The Sharing button is available when your sharing model is either Private or Public Read Only for a type of record or related record. For example, the Sharing button may appear on an account even though your sharing model for accounts is Public Read/Write if your sharing model for related opportunities is Public Read Only.
But, sometimes Sharing button is not shown for particular user, while administrator able to see the button in the same page layout. So many admins think, user not able to see the button because user do not have permission set in the profile assigned, and this is not correct.
Sharing button only will be shown if user fulfill following criteria:
- administrator
- the record owner
- users in a role hierarchy above the record owner, and
- users that has been granted with “Full Access” sharing
If user is not one of them, he/she will not see the button, although user able to access the record.
Furthermore, sharing is disabled if the sharing model is set to "Controlled By Parent", which happens when you create a master-detail relationship.
Lastly, you cannot manually share a contact which not linked to an account.
How to configure Sharing Rules in Salesforce?
Continuing on setting up security with for our example sales organization, let’s say that you have support staff in the role of Sales Engineer that report directly to the VP, North America Sales. Sales Engineers lend technical assistance on Opportunities, and thus need to see Accounts and Opportunities owned by the salespeople under the VP, North America Sales. To do this, you would have a Sharing Rule as follows:
Continuing on setting up security with for our example sales organization, let’s say that you have support staff in the role of Sales Engineer that report directly to the VP, North America Sales. Sales Engineers lend technical assistance on Opportunities, and thus need to see Accounts and Opportunities owned by the salespeople under the VP, North America Sales. To do this, you would have a Sharing Rule as follows:
What is Organization-Wide Defaults(OWD) in salesforce?
Organization-Wide Defaults, or OWDs, are the baseline security you for your Salesforce instance. Organizational Wide Defaults are used to restrict access. You grant access through other means we will talk about later (sharing rules, Role Hierarchy, Sales Teams and Account teams, manual sharing, etc).
There are four levels of access that can be set:
- Public Read/Write/Transfer (only available of Leads and Cases)
- Public Read/Write
- Public Read/Only
- Private
To reduce the number of variables in this discussion let’s collapse the three “Public” flavors to a single bucket and frame the discussion around the impact of changing your OWDs from “Public” to “Private.” As we mentioned before, Organization-Wide Defualts are used restrict access, not grant access. If you need to restrict access to even one individual out of a 1,000 Users, the only way to do that is to set your Organizational Wide Defaults to “Private,” and grant access back to everyone else but that single User you need to keep in the dark.
When you flip an Object in your OWDs to “Private” you’ve in essence erected walls between users in the same level of the Role Hierarchy. To illustrate using my diagram below, the restricted access walls set by the flipping an Object to “Private” are represented by the dashed green, red and blue lines. For the Object set to “Private,” the Users in the Role ofEastern Sales Team can no longer see records owned by the Western Sales Teambecause they are at the same level of the Role Hierarchy (looking “across” the same level is represented by the solid blue, red and green double headed arrows in the diagram below). The same is true the next level up in the Role Hierarchy. The Users in the role Director, Direct Sales cannot see records owned by the Director, Channel Sales. Not surprising, access continues to be limited up the ladder across the same tiers of the Role Hierarchy. OurVP, North America Sales, the VP, Marketing and the VP, International Sales cannot see records owned by their peers, nor can they see the records owned by their peer’s subordinates. If you can’t look across, then you can’t look across and then down – e.g. theDirector, Direct Sales cannot see the records owned by the Channel Sales Team(because they are a subordinate to the Director, Direct Sales peer, the Director, Channel Sales).
Here is where the Role Hierarchy grants access in a Private setting. Manager’s (meaning, Users that have a higher position in the Role Hierarchy) can always see the records owned by their role subordinates. Using our diagram again, access granted by the Role Hierarchy is represented by the curved pink, yellow and blue lines. The SVP, Sales & Marketing can see the records owned by his role subordinates – the VP, North America Sales, VP, Marketingand the VP, International Sales. Not surprising the VP, North American Sales can see records owned by the Director, Channel Sales, Director, Direct Sales and down the Role Hierarchy to their direct reports – the Channel Sales Team, the Western Sales Team and the Eastern Sales Team.
On an Object with its OWDs set to “Private,” the Role Hierarchy grants access down to subordinate roles’ records, but does not grant access upward. For example, The Western Sales Team cannot see records owned by their manager the Director, Direct Sales(because it is one level up the Role Hierarchy).
The impact to Reports, Views, Search and Lookups
Organization-Wide Defaults, or OWDs, are the baseline security you for your Salesforce instance. Organizational Wide Defaults are used to restrict access. You grant access through other means we will talk about later (sharing rules, Role Hierarchy, Sales Teams and Account teams, manual sharing, etc).
There are four levels of access that can be set:
- Public Read/Write/Transfer (only available of Leads and Cases)
- Public Read/Write
- Public Read/Only
- Private
To reduce the number of variables in this discussion let’s collapse the three “Public” flavors to a single bucket and frame the discussion around the impact of changing your OWDs from “Public” to “Private.” As we mentioned before, Organization-Wide Defualts are used restrict access, not grant access. If you need to restrict access to even one individual out of a 1,000 Users, the only way to do that is to set your Organizational Wide Defaults to “Private,” and grant access back to everyone else but that single User you need to keep in the dark.
Shields up!
What does setting your OWDs to “Private” really do? The best way to explain this concept is with an org chart. A traditional Org Chart would look cleaner, but let’s look use the Role Hierarchy diagram shown in “Tree View” since it’s available inside Salesforce.com.
When you flip an Object in your OWDs to “Private” you’ve in essence erected walls between users in the same level of the Role Hierarchy. To illustrate using my diagram below, the restricted access walls set by the flipping an Object to “Private” are represented by the dashed green, red and blue lines. For the Object set to “Private,” the Users in the Role ofEastern Sales Team can no longer see records owned by the Western Sales Teambecause they are at the same level of the Role Hierarchy (looking “across” the same level is represented by the solid blue, red and green double headed arrows in the diagram below). The same is true the next level up in the Role Hierarchy. The Users in the role Director, Direct Sales cannot see records owned by the Director, Channel Sales. Not surprising, access continues to be limited up the ladder across the same tiers of the Role Hierarchy. OurVP, North America Sales, the VP, Marketing and the VP, International Sales cannot see records owned by their peers, nor can they see the records owned by their peer’s subordinates. If you can’t look across, then you can’t look across and then down – e.g. theDirector, Direct Sales cannot see the records owned by the Channel Sales Team(because they are a subordinate to the Director, Direct Sales peer, the Director, Channel Sales).
Here is where the Role Hierarchy grants access in a Private setting. Manager’s (meaning, Users that have a higher position in the Role Hierarchy) can always see the records owned by their role subordinates. Using our diagram again, access granted by the Role Hierarchy is represented by the curved pink, yellow and blue lines. The SVP, Sales & Marketing can see the records owned by his role subordinates – the VP, North America Sales, VP, Marketingand the VP, International Sales. Not surprising the VP, North American Sales can see records owned by the Director, Channel Sales, Director, Direct Sales and down the Role Hierarchy to their direct reports – the Channel Sales Team, the Western Sales Team and the Eastern Sales Team.
On an Object with its OWDs set to “Private,” the Role Hierarchy grants access down to subordinate roles’ records, but does not grant access upward. For example, The Western Sales Team cannot see records owned by their manager the Director, Direct Sales(because it is one level up the Role Hierarchy).
The impact to Reports, Views, Search and Lookups
NOTE: If a User cannot see a record due to security settings, that restriction cascades throughout Salesforce.com. Meaning, that User will not see the record using Search, Views on Tabs, Reports, and Lookups.
How to Configure Groups in Salesforce?
Let’s say that the Director, Direct Sales does want to allow her team to have access not only to her records but also access to records owned by the Eastern Sales Team and theWestern Sales Team. First you would create a Public Group from Setup >Administration Setup > Manage Users > Public Groups and click the “New” button.
We create a group name called “Direct Sales Team,” we searched by Roles to include theDirector, Direct Sales, the Western Sales Team and the Eastern Sales Team, and clicked the “Save” button. Now that we have our group we can create a Sharing rule to grant access. Let’s say that we want to grant access to Leads for this new Group. We would go to Setup > Administration Setup > Security Controls > Sharing Settings. Under the related list of “Lead Sharing Rules” we’d click “New” and from the new window we’d set the rule as follows:
We’ve basically said anyone in that group gets to access records owned by anyone else in the group.
Now our security diagram looks a little different than before. We tore down the blue dotted line that separated the Eastern Sales Team and the Western Sales Team and the new opaque red bubble illustrates the new sharing rule created above – it’s an exception to our overarching OWD security!
Let’s say that the Director, Direct Sales does want to allow her team to have access not only to her records but also access to records owned by the Eastern Sales Team and theWestern Sales Team. First you would create a Public Group from Setup >Administration Setup > Manage Users > Public Groups and click the “New” button.
We create a group name called “Direct Sales Team,” we searched by Roles to include theDirector, Direct Sales, the Western Sales Team and the Eastern Sales Team, and clicked the “Save” button. Now that we have our group we can create a Sharing rule to grant access. Let’s say that we want to grant access to Leads for this new Group. We would go to Setup > Administration Setup > Security Controls > Sharing Settings. Under the related list of “Lead Sharing Rules” we’d click “New” and from the new window we’d set the rule as follows:
We’ve basically said anyone in that group gets to access records owned by anyone else in the group.
Now our security diagram looks a little different than before. We tore down the blue dotted line that separated the Eastern Sales Team and the Western Sales Team and the new opaque red bubble illustrates the new sharing rule created above – it’s an exception to our overarching OWD security!
Salesforce change account owner
Do you know or realize, when account owner is changed manually through salesforce UI the new owner will also gain ownership of
- all notes and open activities for this account (completed activities will not be transferred)
- all contacts tagged to account owned by old owner
- all opportunities tagged to account (including closed opportunities if you select the "Transfer closed opportunities" and opportunity owned by different owner if you select "Transfer open opportunities..." as screenshot below
But, if you change the account owner through API, or API tool such as: Data Loader, only the Account Owner is changed. It will not change owner of contact, opportunity and other object related.
Here are two Salesforce document related ownership change:
- How do I change Account Ownership using the Data Loader?
- How to Change the Record owner using the Data Loader?
Do you know or realize, when account owner is changed manually through salesforce UI the new owner will also gain ownership of
But, if you change the account owner through API, or API tool such as: Data Loader, only the Account Owner is changed. It will not change owner of contact, opportunity and other object related.
Here are two Salesforce document related ownership change:
- How do I change Account Ownership using the Data Loader?
- How to Change the Record owner using the Data Loader?
- all notes and open activities for this account (completed activities will not be transferred)
- all contacts tagged to account owned by old owner
- all opportunities tagged to account (including closed opportunities if you select the "Transfer closed opportunities" and opportunity owned by different owner if you select "Transfer open opportunities..." as screenshot below
But, if you change the account owner through API, or API tool such as: Data Loader, only the Account Owner is changed. It will not change owner of contact, opportunity and other object related.
Here are two Salesforce document related ownership change:
- How do I change Account Ownership using the Data Loader?
- How to Change the Record owner using the Data Loader?
Salesforce delete record: 'Insufficient
privileges' error
In some organisation, user
allow to delete records, but sometimes user get error message 'Insufficient
privileges' although Delete button exist. What's happening? Let us analyze:
1. User able to access the record
There are few scenario:
- Organization-Wide Defaults sharing setting on that
object is Public Read Only or Public Read/Write; or
- Sharing rule added based on record owner or
criteria for Public Groups or Roles; or
- User is the owner of the records; or
- User in higher role hierarchy of record owner; or
- User profile have "View all Data" or
"Modify all Data" permission.
2. User see Delete button
This is happened because:
- Delete button is added in record page layout; and
- User profile have permission to delete that object
3. Error 'Insufficient
privileges'
- The user attempting to delete the record is a
System Administrator.
- The user attempting to delete the record is the
owner, or higher on the role hierarchy than the record owner.
Any other user that
attempts to delete a record will receive an "Insufficient Privilege"
error message.
1. User able to access the record
There are few scenario:
This is happened because:
No comments:
Post a Comment