Implement sharing is defined and maintained by the system.
1.Parent
2.child
3.Portal
4.Case
5.Share Groups (High Volume)
Parent Implicit Sharing :
'Parent implicit sharing' provide read-only access to parent records(Account only),
when user has access to children record,such as : Opportunities,Cases,or Contacts for that account.
This does not mean the user must be the record owned of the child ecord.
(or)
The Parent Implicit sharing provides read-only access to parent record if the user
is having access to the child record.
Note :
Only affects Account to Case, Contact and Opportunity.
Account = private and Child !='Controlled by Parent'
As soon as a user has atleast Read access to a Case,Contact or Opportunity the user has Read access to the related Account.
Child Implicit Sharing :
Child Implicit Sharing is ability for Account owner to access child records (contacts, opportunities, and cases),even they are not owned by Account owner.
The account owner's role determines the level of access to child records (read-only or read/write).
The child Implicit sharing provides Read/Write access to child record if the user is the owner of the parent record.
Access to child records for the owner of the parent account.
Not used when sharing on the child is 'Controlled by Parent'.
Controlled by child access settings for the account owner's role.
Supports account sharing rules that grant child record access.
Supports account team access based on team settings.
When a user loses access to the parent, Salesforce needs to remove all the implicit childern for that user.
Note :
Only affects Account to Case, Contact and Opportunity.
Only affects Account Owner.
Each role independently can define whar child-record access the Account Ownership provides.
Portal Implicit Sharing :
Portal Implicit Sharing will provide Read-only access to portal account
and all associated portal user's contact record using portal role sharing.
Access to portal account and all associated contacts for all portal users under that account.
Shared to the lowest role under the portal account.
High Volume Portal Implicit Sharing :
In this Implicit sharing any record owned by high volume portal users will be shared
with other high volume users who are part of sharing set.
High Volume Parent Implicit Sharing :
In this implicit sharing, read only access will be given to parent account
of records shared through a sharing set to other user members.
Controlled by Parent vs Implicit Sharing :
Note : Controlled by Parent isn't the same as Implicit Sharing.
Implicit Sharing :
Implicit Sharing is when a user gains access to a child record and also gains read-only access to the parent.
e.g. a contact is assigned to a user, and thus gains read-only access to the account.
Implicit sharing only has an effect when the parent object is Private and the child is not Controlled by Parent
Controlled by Parent :
Controlled by Parent, in contrast, grants read or read-write access to the child records when access is granted to the parent.
It has an effect in all parent share modes (private, read-only, and write).
Using Controlled by Parent will decrease row lock time on the parent, but not eliminate it.
There has to be a lock on the parent while the children are being updated.
Controlled by Parent will increase performance because there's no child share table while in this mode
(the children's access is checked using the parent's share table).
Case share :
If a portal or customer community plus user is a contact on a case,then the user has read and write access on the case.
The contact for a Case has Read & Edit Access on that Case.
Only affects Partner and Community Plus Licenses.
Community License Users need Sharing-Set.
Share Group (High Volume) :
Access to data owned by high volume users associated with a sharing set for users member of the sharing set's access group.
All members of the sharing set access group gain access to every record owned by every high volume user associated with that sharing set.
profile : Customer Community
Record Ownership by User is necessary.
Affects(almost?) all objects.
Record Owner needs Profile in share Set.
Any Record owned by a profile mentioned in the Share Set is shared with any user mentioned in the related share group.
Record Locks & Skews :
======================
Record Locks can happen
1.Business-related
Defined by business process and implemented intentionally (e.g.Approval Process,read-only record types).
2.System-related
Done by Salesforce, available and implemented out of the box (cannot be changed)
System Related Record Locks :
Quality of a database is often measured by its data integrity:
1.Data accuracy
2.Data Completeness
3.Data consistency
One measure by Salesforce (and many other databases) to maintain data integrity is to place record locks on records(and their parent records)
while they are being edited.
Note :
A given transaction can only wait a maximum of 10 seconds for a lock to be released,
otherwise it will throw and UNABLE_TO_ROW exception.
Data Skews :
In a database, a skew refers to a situation in which there is an uneven distribution of data.
Data Skews in Salesforce
In salesforce, data skews happen when records relate to one another and child records are unevenly distributed across the parent records.
They will typically result in performance issues.
There are three kinds of data skews that can occur :
1.Account Skew
2.Ownership Skew
3.Lookup Skew
Lookup Skew :
Lookup Skew happens in object relationships when a large number of child records are associated to one parent record.
When a child record is inserted or updated, Salesforce locks the parent record the child will be associated to in order
to maintain data inegrity.When you work with large data, and there are processes (e.g. custom code, automated processes, integrations)
you can easily run into lock contention.
Lookup skews happen in lookup relationships AND master-detail relationships.
Lookup skews can effect standard AND custom objects.
How to identify a Lookup Skew :
There is no exact identifier by which you will be able to identify a lookup skew .
Don't wait until somebody complains, try to address to problem right away.
Take a look at the following
1.Objects with a lot of records.
2.Objects where a lot of inserts and updates happening in parallel.
3.Objects where you get complaints about locks from users.
How to avoid Lookup Skews?
1.Reduce Record Save Time (Apex Best Practices,Asynchronous Processing,Consolidate Automation).
2.Picklist fields.
3.Distributing the skew.
4.Reducing the load (Serial loading, order by Parent Id and chunk the data carefully).
Account Skew :
An Account Skew arises, when a large number of child records (>10,000) are related to a single account.
There are two main problems that can be caused by an Account Skew:
1.Record Locking
2.Sharing Problems
Account skew - sharing problems
Sharing problems arise because of Salesforce built-in parent implicit sharing.
(Users with access to contacts,cases and opportunities get read access to the related account).
If sharing of a child record of a certain object is updated, Salesforce will have to check all other
children of that object to check, if the implicit share for the Account can be removed.
Depending on the amount of childern, the recalculation can take long and will cause performance issues.
During the whole operation, a lock is placed on the account preventing other from editing it.
How to avoid Account Skews?
Limit the amount of Account Children per object to 10,000.
If you need generic Accounts, create a pool of accounts and use a round robin algorithm to distribute them.
Consider setting the Account OWD to 'Public Read/Write'(The record locking
Ownership Skew :
An ownership skew happens, if a single user owns more than 10,000 records of one object.
Performance issues caused by an ownership skew will most typically appear in large organisation where
data chnages that require sharing recalculation happen frequently. These changes could happen on :
Ownership based sharing rules
Record ownerships
Group members/ Role Hierarchy
How to avoid Ownership Skews?
1.Ensure that the 'Skewed' owner is not part of the role hierarchy or put them in a role
at the top of the hierarchy/ within its own branch.
2.Don't move the user into another role/move the role within the role hierarchy.
3.Keep the user out of public groups used for sharing.
4.For organization wide sharing, review OWDs(is private necessary?)
In Overall to avoid DataSkew :
Avoid Large number (>10,000)of child records in master/Detail relationship
Avoid Large Number of records owned by one user
Avoid RecordLocking
No comments:
Post a Comment