1.profile/permission Set level object Settings (CRED)
2.Profile/Permission Set Level object Settings (View All,Modify All)
3.Profile Level System Permissions (View All Data,Modify All Data)
4.Organization Wide Defaults (OWD)
5.Record Ownership
6.Role Hierarchy
7.Teams
8.Queues
9.Sharing Rules
10.Groups
11.Manager Group
12.Territory Management
13.Sharing sets
14.Sharing groups
15.Super User Access
16.Manual Sharing
17.Programmatic/apex sharing
18.Visualforce with Apex
19.Implicit sharing
20. Master-detail Relationship
1.Profile/Permission Set Level Object Settings (CRED)
-> The first minimum thing that the user needs to have
'Read','Create','Edit' or 'Delete'(CRED) permission on
the object either through profile or permission Set.
-> In Fact the user's profile/permission set must have
these Object level Permissions(CRED) for other sharings
to work.
-> For profile tied to specific license types (e.g Community User Licenses),
you can't set CRED on some of the objects.
E.g. for "Customer Community" License, the 'Lead' object is
not available.
Note :
Different License Types
1.Customer Community License
2.Customer Plus Community License
3.Partner Community License
Customer Community Plus users have greater access to sharing
features.They can have up to 3 roles, and therefore are able to
utilize sharing rules.
Partner Community licenses features the same benefits as
Customer community plus, and also have access to sales- related
objects (Lead,campaigns and Opportunities).
Note :
There are no workaround for Customer Community Profile
user to access leads.
You need to upgrade to Partner Community License
(Opportunities,Leads,Quotes,Campaigns objects available).
2.Profile/Permission Set Level Object Settings (View All/Modify All)
-> The next option that you have is to grant 'View All' and/or
'Modify All' at the object level.
-> Once these permissions are granted to the user's
profile/permission set, they can view/edit all records in that
object, irrespective of the sharing model.
-> For profiles tied to specific license types,
view all/modify all options will not be available on some of the objects.
3.Profile Level System Settings (View All Data, Modify All Data)
-> Probably one of the most powerful permission that you grant
is to specify 'view All Data' / 'Modify All Data' at the system level
on user's profile.with this option the user will be able to view/modify
all records across all objects.
-> For profiles tied to specific license types,
view all data/modify all data system privilege is not available.
-> use this option sparingly and with caution.
4.Organization Wide Defaults (OWDs)
-> Another way to grant users access to records is by setting
the OWD to "Public Read only" or "Public Read/Write" for individual
objects.
-> When set to "Public Read Only" or "Public Read/Write ",
All users in your Org will have view/edit privileges
provided the user has CRED permissions on the object(s)
through profile/permission set.
5. Record Ownership
-> if the user is the owner of the record, they automatically
have read/edit/transfer privileges on that record.
-> However, if you have removed the object level CRED permission
from user's profile/permission set, then they won't be able to
view/edit the records EVEN IF they are owner of the record.
-> This can happen if the user's profile/permission set had CRED
privileges, they created some records and later CRED permissions
were removed.
6.Role Hierarchy
-> All the users who have above in the role hierarchy
chain of the user who has access to the records, will
automatically inherit the same permissions as their subordinates
on that record.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note :
Community users having 'Customer Community' license type
cannot be assigned a role and hence this rule does not apply
to them.
7. Teams (Account,case,Opportunity)
-> To share records in Account,Case & Opportunities,
you can enable teams and add user to the team.
-> For each user being added to the team, you can define
whether they canjust 'View' the record or 'Edit' the record.
In Case of 'Account Team' , you can define whether the users
in the 'Account Team' has access to the 'Cases' & 'Opportunities'
for that Account.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note : Community users having 'Customer Community'
license cannot be added to the team and hence this rule
does not apply to them.
8.Queues
-> you can create Queues in salesforce, assign the user to
the queue and set the queue as the owner of the record.
-> Users assigned to the queue will then automatically
have "Owner" like access to those records.
-> User must have CRED permissions on the object(s)
through profile/permission set.
Note :
1. you can't set the queue as the owner on the 'Account'
and 'Task' objects.
2.Community users having 'Customer Community' license
cannot be added to the queue and hence this rule does not apply
to them.
9. Sharing Rules
-> Create sharing Rules on the object. You can define the following
type of sharing rules.
1.Ownership Based Sharing Rule - Where you can share records
owned by a specific set of users with another specific
set of users.
2.Criteria Based sharing Rule - Where you can share records
meeting a specific criteria with specific set of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note : cannot be used for sharing records with Community
users having 'Customer Community' license type.
10. Groups
-> you can create Groups in salesforce and assign users
to the groups (you can also assign roles, territories or
other groups to a group).
-> Then use Sharing Rules to grant access to the records
to this group of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note :
Community users having 'Customer Community' license type cannot
be added to groups and hence this rule does not apply to them.
11.Manager Group
-> you can enable 'Manager Group' sharing option to share records
with the 'Manager' of user defined on the 'User' object.
-> Use Manager groups to share records with your management chain
instead of ll managers in the same role based on the role hierarchy.
-> Then use Sharing Rules to grant access to the records to this
group of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note : Manager groups can contain standard and chatter only users only
and doesn't include portal users.
12. Territory Management
-> Another powerful way to share records with users -
Create Territories and assign users to territories.
-> For sharing Account records, define the Account Assignment rule
on the Territories.
-> For sharing records in other objects, define sharing rules and
use Territories in the sharing rules.
-> User must have CRED permissions on the object(s) through
profile/ permission set.
Note :
Community users having 'Customer Community' license type
cannot be assigned to territories and hence this rule does not
apply to them.
13. Sharing Set
-> Use Sharing Set to share records with users having 'Customer Community' license type.
-> This is the only way to share records with these types of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note :
-> Applicable only for community users having 'Customer Community' license type.
-> NOT applicable for any other user type.
14. Sharing Group
-> Use this option to share records created by 'Customer Community'
license users with other internal/community users.
-> Works together with Sharing Set.
-> While Sharing Set is used to share records created by other
usres with 'Customer Community' license users,sharing Group
is used to share records created by 'Customer Community' license users
with other users .
-> User must have CRED permissions on the object(s) through
profile/permission set.
15. Super User Access
-> Applicable only for users with license type 'Partner community'
& 'Customer community Plus'.
-> Used to share records created by the community user
belonging to the same Account.
-> User must have CRED permission on the Object(s) through
profile/permission set.
16. Manual Sharing
-> Owner of a record/person higher in the role hierarchy
of the owner/ System Administrator, can grant manual access to other
users, groups, roles. This is done manually on record by record basis.
Note : if you change the owner of the record or transfer the record
to someone else, Salesforce will remove all the manual sharing.
-> User must have CRED permission on the Object(s) through
profile/permission set.
17. Programmatic/apex Sharing
-> You can also share records with other users, groups, roles programmatically.
-> This is usually done by defining a sharing reason and inserting a record in <object_name>__share object.
-> A use case is you want to share the ‘Job’ record with the Hiring Manager of that job.
So as soon as the hiring manager is assigned to the job record, the record should then automatically be shared with that hiring manager.
This is achieved by writing a trigger on the ‘Job’ object and using programmatic sharing
-> User must have CRED permissions on the object(s) through profile/permission set.
Note :
Cannot be used to share records with Community users having 'Customer Community' license type.
18. Visualforce with Apex
->If nothing else works, then you can create a Visualforce Page with Custom Apex Controller in "without sharing" mode
and grant users view/edit access to the record.
-> This option requires heavy custom development and maintenance.
-> Before going down this route, do ensure that you will not be flouting Salesforce licensing rules
when exposing records through this method.
E.g.
Salesforce Licensing model does not grant access to 'Lead' object to Customer Community Plus users.
If you are creating a Visualforce page with Custom Apex Controller
to expose lead object records to Customer Community Plus user, this may not be allowed.
19.Implict Sharing
->Salesforce grants implicit access to the records when you have access to other related records.
-> For example if you have access to a 'Contact', 'Case' or 'Opportunity' record,
Salesforce will grant you implicit read only access to the corresponding Account.
This is known as 'Implicit Parent'
-> Or if you have access to the Account through Role Hierarchy / Account Team
and have selected the option to grant access to 'Contact', 'Case' or 'Opportunity'
when defining Account Team or Role Hierarchy, then Salesforce will grant you implicit Access to
'Contract', 'Case', or 'Opportunity' records. This is known as 'Implicit Child'.
->User must have CRED permissions on the object(s) through profile/permission set.
20.Master-detail Relationship
->If you have objects in Master-Detail relationship, then the sharing rules defined on the master
automatically cascades to the object on the ‘Detail’ side of the relationship.
-> You cannot define separate sharing rule on the child object as the sharing rules are inherited from the Master.
-> This means that if a user has ‘View’ access on a record in the Master object,
he will also be able to view the corresponding child records in the detail object.
->User must have CRED permissions on the object(s) through profile/permission set.
2.Profile/Permission Set Level object Settings (View All,Modify All)
3.Profile Level System Permissions (View All Data,Modify All Data)
4.Organization Wide Defaults (OWD)
5.Record Ownership
6.Role Hierarchy
7.Teams
8.Queues
9.Sharing Rules
10.Groups
11.Manager Group
12.Territory Management
13.Sharing sets
14.Sharing groups
15.Super User Access
16.Manual Sharing
17.Programmatic/apex sharing
18.Visualforce with Apex
19.Implicit sharing
20. Master-detail Relationship
1.Profile/Permission Set Level Object Settings (CRED)
-> The first minimum thing that the user needs to have
'Read','Create','Edit' or 'Delete'(CRED) permission on
the object either through profile or permission Set.
-> In Fact the user's profile/permission set must have
these Object level Permissions(CRED) for other sharings
to work.
-> For profile tied to specific license types (e.g Community User Licenses),
you can't set CRED on some of the objects.
E.g. for "Customer Community" License, the 'Lead' object is
not available.
Note :
Different License Types
1.Customer Community License
2.Customer Plus Community License
3.Partner Community License
Customer Community Plus users have greater access to sharing
features.They can have up to 3 roles, and therefore are able to
utilize sharing rules.
Partner Community licenses features the same benefits as
Customer community plus, and also have access to sales- related
objects (Lead,campaigns and Opportunities).
Note :
There are no workaround for Customer Community Profile
user to access leads.
You need to upgrade to Partner Community License
(Opportunities,Leads,Quotes,Campaigns objects available).
2.Profile/Permission Set Level Object Settings (View All/Modify All)
-> The next option that you have is to grant 'View All' and/or
'Modify All' at the object level.
-> Once these permissions are granted to the user's
profile/permission set, they can view/edit all records in that
object, irrespective of the sharing model.
-> For profiles tied to specific license types,
view all/modify all options will not be available on some of the objects.
3.Profile Level System Settings (View All Data, Modify All Data)
-> Probably one of the most powerful permission that you grant
is to specify 'view All Data' / 'Modify All Data' at the system level
on user's profile.with this option the user will be able to view/modify
all records across all objects.
-> For profiles tied to specific license types,
view all data/modify all data system privilege is not available.
-> use this option sparingly and with caution.
4.Organization Wide Defaults (OWDs)
-> Another way to grant users access to records is by setting
the OWD to "Public Read only" or "Public Read/Write" for individual
objects.
-> When set to "Public Read Only" or "Public Read/Write ",
All users in your Org will have view/edit privileges
provided the user has CRED permissions on the object(s)
through profile/permission set.
5. Record Ownership
-> if the user is the owner of the record, they automatically
have read/edit/transfer privileges on that record.
-> However, if you have removed the object level CRED permission
from user's profile/permission set, then they won't be able to
view/edit the records EVEN IF they are owner of the record.
-> This can happen if the user's profile/permission set had CRED
privileges, they created some records and later CRED permissions
were removed.
6.Role Hierarchy
-> All the users who have above in the role hierarchy
chain of the user who has access to the records, will
automatically inherit the same permissions as their subordinates
on that record.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note :
Community users having 'Customer Community' license type
cannot be assigned a role and hence this rule does not apply
to them.
7. Teams (Account,case,Opportunity)
-> To share records in Account,Case & Opportunities,
you can enable teams and add user to the team.
-> For each user being added to the team, you can define
whether they canjust 'View' the record or 'Edit' the record.
In Case of 'Account Team' , you can define whether the users
in the 'Account Team' has access to the 'Cases' & 'Opportunities'
for that Account.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note : Community users having 'Customer Community'
license cannot be added to the team and hence this rule
does not apply to them.
8.Queues
-> you can create Queues in salesforce, assign the user to
the queue and set the queue as the owner of the record.
-> Users assigned to the queue will then automatically
have "Owner" like access to those records.
-> User must have CRED permissions on the object(s)
through profile/permission set.
Note :
1. you can't set the queue as the owner on the 'Account'
and 'Task' objects.
2.Community users having 'Customer Community' license
cannot be added to the queue and hence this rule does not apply
to them.
9. Sharing Rules
-> Create sharing Rules on the object. You can define the following
type of sharing rules.
1.Ownership Based Sharing Rule - Where you can share records
owned by a specific set of users with another specific
set of users.
2.Criteria Based sharing Rule - Where you can share records
meeting a specific criteria with specific set of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note : cannot be used for sharing records with Community
users having 'Customer Community' license type.
10. Groups
-> you can create Groups in salesforce and assign users
to the groups (you can also assign roles, territories or
other groups to a group).
-> Then use Sharing Rules to grant access to the records
to this group of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note :
Community users having 'Customer Community' license type cannot
be added to groups and hence this rule does not apply to them.
11.Manager Group
-> you can enable 'Manager Group' sharing option to share records
with the 'Manager' of user defined on the 'User' object.
-> Use Manager groups to share records with your management chain
instead of ll managers in the same role based on the role hierarchy.
-> Then use Sharing Rules to grant access to the records to this
group of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note : Manager groups can contain standard and chatter only users only
and doesn't include portal users.
12. Territory Management
-> Another powerful way to share records with users -
Create Territories and assign users to territories.
-> For sharing Account records, define the Account Assignment rule
on the Territories.
-> For sharing records in other objects, define sharing rules and
use Territories in the sharing rules.
-> User must have CRED permissions on the object(s) through
profile/ permission set.
Note :
Community users having 'Customer Community' license type
cannot be assigned to territories and hence this rule does not
apply to them.
13. Sharing Set
-> Use Sharing Set to share records with users having 'Customer Community' license type.
-> This is the only way to share records with these types of users.
-> User must have CRED permissions on the object(s) through
profile/permission set.
Note :
-> Applicable only for community users having 'Customer Community' license type.
-> NOT applicable for any other user type.
14. Sharing Group
-> Use this option to share records created by 'Customer Community'
license users with other internal/community users.
-> Works together with Sharing Set.
-> While Sharing Set is used to share records created by other
usres with 'Customer Community' license users,sharing Group
is used to share records created by 'Customer Community' license users
with other users .
-> User must have CRED permissions on the object(s) through
profile/permission set.
15. Super User Access
-> Applicable only for users with license type 'Partner community'
& 'Customer community Plus'.
-> Used to share records created by the community user
belonging to the same Account.
-> User must have CRED permission on the Object(s) through
profile/permission set.
16. Manual Sharing
-> Owner of a record/person higher in the role hierarchy
of the owner/ System Administrator, can grant manual access to other
users, groups, roles. This is done manually on record by record basis.
Note : if you change the owner of the record or transfer the record
to someone else, Salesforce will remove all the manual sharing.
-> User must have CRED permission on the Object(s) through
profile/permission set.
17. Programmatic/apex Sharing
-> You can also share records with other users, groups, roles programmatically.
-> This is usually done by defining a sharing reason and inserting a record in <object_name>__share object.
-> A use case is you want to share the ‘Job’ record with the Hiring Manager of that job.
So as soon as the hiring manager is assigned to the job record, the record should then automatically be shared with that hiring manager.
This is achieved by writing a trigger on the ‘Job’ object and using programmatic sharing
-> User must have CRED permissions on the object(s) through profile/permission set.
Note :
Cannot be used to share records with Community users having 'Customer Community' license type.
18. Visualforce with Apex
->If nothing else works, then you can create a Visualforce Page with Custom Apex Controller in "without sharing" mode
and grant users view/edit access to the record.
-> This option requires heavy custom development and maintenance.
-> Before going down this route, do ensure that you will not be flouting Salesforce licensing rules
when exposing records through this method.
E.g.
Salesforce Licensing model does not grant access to 'Lead' object to Customer Community Plus users.
If you are creating a Visualforce page with Custom Apex Controller
to expose lead object records to Customer Community Plus user, this may not be allowed.
19.Implict Sharing
->Salesforce grants implicit access to the records when you have access to other related records.
-> For example if you have access to a 'Contact', 'Case' or 'Opportunity' record,
Salesforce will grant you implicit read only access to the corresponding Account.
This is known as 'Implicit Parent'
-> Or if you have access to the Account through Role Hierarchy / Account Team
and have selected the option to grant access to 'Contact', 'Case' or 'Opportunity'
when defining Account Team or Role Hierarchy, then Salesforce will grant you implicit Access to
'Contract', 'Case', or 'Opportunity' records. This is known as 'Implicit Child'.
->User must have CRED permissions on the object(s) through profile/permission set.
20.Master-detail Relationship
->If you have objects in Master-Detail relationship, then the sharing rules defined on the master
automatically cascades to the object on the ‘Detail’ side of the relationship.
-> You cannot define separate sharing rule on the child object as the sharing rules are inherited from the Master.
-> This means that if a user has ‘View’ access on a record in the Master object,
he will also be able to view the corresponding child records in the detail object.
->User must have CRED permissions on the object(s) through profile/permission set.
No comments:
Post a Comment