sharing and visibility designer certification crib sheet › 2018 › 02 › ... · 2018-05-03 ·...

SANTOSH KUMAR SRIRAM 1

SHARING AND VISIBILITY DESIGNER CERTIFICATION CRIB SHEET

Table of Contents

Performance and Data Security – 8% ........................................................................................ 3

Reducing lock contention by preventing account data skew .............................................................. 3

Salesforce group membership architecture ....................................................................................... 5

Technical enablement case study ....................................................................................................... 6

Group Membership Locks – could not acquire lock ............................................................................ 6

Designing Record Access for Enterprise Scale..................................................................................... 7 Implicit Sharing ............................................................................................................................................. 8

Protecting Your Data in the cloud ...................................................................................................... 9

Declarative Sharing – 67% ....................................................................................................... 10

Who can see my file? ....................................................................................................................... 10

Control Access to records ................................................................................................................. 10

On Overview of force.com sharing ................................................................................................... 11

Locking down record access in salesforce ........................................................................................ 13

Behind the scenes of record ownership ........................................................................................... 13

Define External Objects .................................................................................................................... 14

Record Level Access – under the hood ............................................................................................. 14

Account teams ................................................................................................................................. 14

Create a custom list view in Salesforce classic.................................................................................. 15

Share a Report or Dashboard Folder in Salesforce Classic ................................................................ 15

Communities User Licenses .............................................................................................................. 15

Sharing Sets in community ............................................................................................................... 16

Sharing groups ................................................................................................................................. 17

Territory Management ..................................................................................................................... 17

Territory Management Considerations.................................................................................... 18

Programmatic Sharing – 25% .................................................................................................. 18

Sharing a Record Using Apex ............................................................................................................ 18


Apex Managed Sharing and Customer Community Plus Users ................................................ 18

Dynamic Data Sharing ...................................................................................................................... 19

Protecting Force.com Custom Sharing Code ..................................................................................... 19

Without sharing ............................................................................................................................... 19

Enforcing Sharing Rules .................................................................................................................... 19

Using Apex Managed Sharing to Create Custom Record Sharing Logic ............................................. 20

Enforcing Object and FLS in Apex and VF ......................................................................................... 20

Sharing Cheat Sheet .................................................................................................................. 21 Sharing Metadata Records ........................................................................................................................... 21 Implicit Sharing ........................................................................................................................................... 21 Organisation-Wide Defaults (OWD) ............................................................................................................. 21 No Relationship ........................................................................................................................................... 21 Master Detail .............................................................................................................................................. 21 Lookup ........................................................................................................................................................ 21

Manual Sharing ................................................................................................................................ 21

Apex Managed Sharing .................................................................................................................... 22 Recalculation ............................................................................................................................................... 22

Choosing the Right Share Type ......................................................................................................... 22 “Traditional” / Ownership-based Sharing Rules ............................................................................................ 22 Criteria-based Sharing Rules ........................................................................................................................ 22 Apex Managed Sharing Rules ....................................................................................................................... 22 Manual Sharing Rules .................................................................................................................................. 22 Share Groups .............................................................................................................................................. 22 Sharing Sets................................................................................................................................................. 22

Portals .............................................................................................................................................. 23 High Volume Portals (Service Cloud Portals) ................................................................................................ 23 other portals ............................................................................................................................................... 23 Large Data Volumes..................................................................................................................................... 23


We are starting with Performance (8%) as that’s one of the sections that deals with use-case based learning. I am big proponent of learning via experiences and I feel that tackling that sections with some pre-reading can benefit the understanding of the certification.

Performance and Data Security – 8% Reducing lock contention by preventing account data skew To understand what is Account data skew, we need to get a little non-Salesforce-y. I love Breaking Bad and let’s use that as an example. You know Jessie is a meth-head who goes through an arc in the series to be a free soul. Imagine you are Walter White and you had to work with an irresponsible, nerve cracking bloke like Jessie. His actions are certainly going procrastinate your planned activities and you have to anticipate delays due to surprises as well. Let’s hypothesis this further. Imagine you had to work with 10,000 Jessies to create a batch of meth. As I type this, my head explodes considering the hypothetical visualization my head went through. Well, what you just read is indeed Account Data Skew!

Shar

ing

and

visib

itlity

des

igne

r

Declarative sharing 67%

Performance and Data Security 8%

Programmatic sharing 25%


What is Account Data Skew? ************* EXAM FOCUS ************ When an account has more than 10,000 children, it results in lock contention and reduced data/database concurrency. Let’s break down the jargons there! Lock Contention – When you are trying to retrieve/update a record in Salesforce where already an existing process is modifying, then the record is locked temporarily by Salesforce and hence results in Lock contention if the executing process takes more than 10 seconds. Database concurrency – Ability to transact with the database by multiple users at the same give point of time.

Aftermath of a CHILD insert/save In a PRIVATE SHARING MODEL, when a child of an account is created, ie Contact, the parent is also shared with a READ access. This is called PARENT IMPLICIT SHARING IMPACT OF DATA SKEW

• Recalculates sharing for any change • Longer record contention a.k.a LOCK • Reduced database concurrency • Post 10 seconds, the user will see a UNABLE_TO_LOCK_ROW

Child•Child is inserted/updated•Child record is locked for the transaction.

Parent•Related parent is also locked once the child record is locked. This could be for various reasons -parent child relationship, sharing settings in the org


************* EXAM FOCUS ************ To avoid data skew issues:

• Limit Child records per parent/account: Use round robin for assigning parents or use custom settings to set limits to number of children

• Open up security – If possible, Public Read/Write sharing model. In this case, the lock still occurs but the sharing recalculation doesn’t happen. This way the lock contention is eliminated.

• Redistribute existing skewed accounts. For complex redistribution use Batch APEX or BULK API for better performance.

Salesforce group membership architecture Groups provide a layer of abstraction. Wait what? Abstraction – what does it mean and what does it do? It is a fancy technical term to group and go layer above. Instead of saying – “I own a Tesla Model X and a Toyota Rav4 SE”, you just say “I own cars!”. See what I did there? I abstracted all my ‘automobiles’ as ‘cars’ instead of naming them individually. Well, groups do the same. It abstracts individual users to a collection of users called groups. Aaaah, neat right?! Group membership is used in sharing rules and other customizations by many architects today. Do you know that Salesforce uses them extensively within the platform? We are going to deal with one such use-case. Consider a share table of say Account RowCause Shared With ParentId Owner User A 001xxxxxxxxxxxx Sharing Rule Group A 001xxxxxxxxxxxx

If you realize, the share table doesn’t create individual records for each user in the group, rather “abstracts” them into group and stores just 1 record. This prevents the use case of 1:1 relationship between user and share access record. Salesforce enhances its performance in sharing recalculations but creating this layer of abstractions. ************* EXAM FOCUS ************ Creating groups for very small member groups or single users can negatively affect sharing performance – because it has traverse through relationships. When user moves in-or-out of group, lock occurs and affects the movement of all users in all types of groups – including role hierarchy, queues, public groups, territory hierarchy.


************* EXAM FOCUS ************ In use cases where there is a very high volume of users’ movement between groups – share directly and prevent group sharing. Technical enablement case study The use case is interesting and made me think, is this is a 1% snapshot of what’s in store in the CTA review board. It talks about delays in record reassignment and hierarchy changes. Let’s get to the crux and learn to mitigate such issues from the document:

• Child Record Access Settings – Every role in Salesforce defines access settings to standard children of account. When roles have composite settings/access, the system may have to significantly work to recalculate when a re-assignment occurs. Single access policy for all roles

• Portal Roles – . Remove empty portal roles - If owner of portal account is changed, portal roles that provide access to portal users must be moved in the hierarchy if new owner is in a different role.

• Reduce the number of children per account – Archive the old record like opportunities and cases. Contacts have to updated/archiving based on changes in the clientele relationship.

• Bulk API – In worst case scenario when the custom dev should execute, use Batch APEX or Bulk API as Salesforce provides peak performance and scalability.

Forget cramming that up, lets talk simple English: Too many unnecessary records that result in delay – try to minimalize records (reduce the number of children per account) Too many conditions that make decision making dizzy – reduce all those conditions (child record access settings – reduce complexity and simplify it) Too slow to walk? Get a bike - use what can make your day easy (switch to Salesforce efficient solutions like Batch APEX or Bulk API) Group Membership Locks – could not acquire lock When administrative changes occur to Role Hierarchy, Territory Hierarchy, Queues, Public groups – Salesforce locks group membership to ensure data integrity is maintained while compiling complex sharing rules. The following are the architectural strategies to manage group membership locks:

• Identify business critical operations – If operations are processing asynchronously and the transaction time is very high causing group membership locks – then try to


synchronize the operation. If this is already executing synchronously then execute the same in batches and perform them in ‘near real time’ execution so that they don’t lock each other.

• Granular locking feature enabled -** EXAM FOCUS ** If Granular locking is turned on, the system employs additional logic to allow multiple updates to the roles and groups, if there are no hierarchical or relationship between the roles and groups involved in the update. Customers who experience frequent locking that restricts their ability to manage manual and automated updates or who receive an error message of a group membership lock can use this feature.

• Architectural sequencing of lock causing operations – o Tune code and change batch size of these operations to ensure locks don’t occur

more than 10 seconds o Retry logic can be implemented in case of lock and failing scenarios.

• Segregate code to aid functional requirement – Trim code and marginalize business critical operation code and group membership update code. This way the lock doesn’t block business critical operative code.

************* EXAM FOCUS ************ Most important of the lot Designing Record Access for Enterprise Scale Group Membership Operations and Sharing Recalculation

• When a user is moved from one branch of hierarchy to another • When a role is moved from one branch of hierarchy to another • Changing the owner of a portal account

Ownership Data Skew When a single user owns more than 10,000 records of an object we call it as ‘Ownership Data Skew’. If this user is moved around the hierarchy, more in or out of groups or role – Salesforce has to recalculate and adjust the sharing for several records which leads to longer running time. If it is a mandate for few users to own records in Salesforce, then:

• Ensure that the user who owns the records has a role. • Place them in the top of the hierarchy • Not move them from the top role • Keep them out of sharing rules

Single Portal Account Skew If a large amount of data is visible or owned to users under a single portal account, changing the owner of the portal account would result in longer sharing and inheritance calculations.


Record Locking

• Updates to parent records and their children are being processed simultaneously in separate threads.

• Updates to child records that have the same parent records are being processed simultaneously in separate threads.

Parallel Sharing Rule recalculation ** exam focus ** If experiencing long processing times or cancellation of jobs, we should consider Parallel Sharing Rule Calculation. When this feature is turned on, then the sharing recalculations are processed asynchronously. This results in resilient processing – reexecuting the queue when a server fires back after a brief hiatus. Deferred sharing maintenance ** exam focus ** Admin can “turn off” the group membership maintenance operation, that recalculates the sharing rules to maintain data integrity within the Salesforce instance. In this window, the admin can make desired changes to roles, groups and sharing rules ** This does not include the sharing recalculation for Implicit Sharing ** . Once the changes are completed, the admin can resume the sharing recalculation for all the changes performed in the window. At this point, the org is a FULL SHARING RECALCULATION mode. Implicit Sharing Type of sharing Provides Details Parent Read-only access to the parent

account for a user with access to child record

• Not used when child is controlled by parent

• Expensive to maintain with many account children

• When a user loses access to a child, Salesforce needs to check all other children to see if it can delete the implicit parent – O(n)

Child Access to child records for the owner of the parent account

• Not used when child is controlled by parent

• Controlled by child access settings on the owner’s role

• When a user loses access to a parent account, Salesforce has to remove all access to the implicit children for that account


************* EXAM FOCUS ************ Here are some specific suggestions.

• If the time required to recalculate sharing is affecting your overall realignments schedule, consider using parallel recalculation of sharing rules.

• Consider whether it is more efficient to: • Set aside specific maintenance windows • Defer organizational or sharing rule maintenance while processing your updates

• If you have encountered issues with organizational locking, compare the maintenance you perform regularly with the increased concurrency allowed by granular locking. You might be able to increase throughput by allowing some operations to safely run in multiple threads with granular locking turned on.

Protecting Your Data in the cloud

• The basics of data security starts with something as simple as storing passwords. Nope sticky notes on your desk with usernames and password is perhaps not a great idea To rub the wound with salt, hashing even with salt is vulernable to brute-force attacks (pun intended). So use techniques that can slow the attacker and that can buy us time to react. Introducing……brypt (the hashing function that is pessimal)

• Now that we have identified what to secure, the questions is where to secure: o Protected Custom Metadata Type

§ Can be updated via Metadata API § Can be read via APEX @ runtime (but not updated)

o Protected Custom Setting § Can be updated via APEX @ runtime § Cannot be updated via Metadata API

o Named credential § Not need for remote site settings if this approach is chosen § Primarily for storing auth tokens and secret keys. But users with customize

applications can view these info.

• Salesforce also provides encrypted fields in every object o Limitations:

§ Cant be external ID § Cant have default values § Cant be unique § Limited to 175 chars § Not used in report criteria, list view/roll up fikter


• Salesforce Shield Encryption

o Uses 256AES, classic enrcyption is AES 126 o Read about the Shield toolkit o Allows search, API access, available in workflows and apporvals

Declarative Sharing – 67% Who can see my file? There are 3 sharing settings that define a file access across an organization

a) Private – Who can see a private file? – File owner, users with “Modify all data”. If the file is in a private library, only file owner has access to it. b) Privately shared – users with “Modify all data” or “view all data” and specific users/groups with whom the file is shared via a group, feed, library or user(s) to whom the file is shared via a link. c) Your company – All users in the company can find and view the file Content role also determine the type of access a user has on the file a) File viewer – view/preview, download, share, attach a file to a post, sync a file b) File collaborator – File viewer + upload a new version, edit details, change permission c) File owner = file collaborators + delete and restrict access for the file

Notes: • Users must have the “Sync Files” permission to sync files. • Permissions for files shared with libraries depend on the library.

Control Access to records Record level access The permissions on a record are always evaluated according to a combination of object-level, field level and record level permissions


4 ways to control record level access – listed in the order of increasing access Sooooo…here I am again! Imagine you are a Sales rep and you have access to only your records. That’s OWD which is in the apex of the inverted pyramid. Now 2 more sales rep report to you and you need to see there data. That’s taken care by role hierarchy. Get it? Sharing rules ensure that you can service team data as well (assume that you need access to cases created by the service team – not in your branch of hierarchy) Manual sharing – yes – there is a boundary where automation cease to exist and manual work kicks in On Overview of force.com sharing Users and security

• Let admins or delegated admins via permission sets create users/ reset password • Enforce password policies and password expiration policy

User Authentication

• When using SSO • Delegated Authentication – With this approach, user logs to a platform, uses a

web service callout to authenticate to an external authorization authority. Once the authority approves, the user can proceed. Contact Salesforce.com to enable this feature.

• SAML assertion – request goes to SAML request provider, login pages that validates and returns a token, token password to platform which verifies the user.


Eg user logs into portal à SAML authentication à automatic login into salesforce avoiding the second login into force.com screen

Network based security ************* EXAM FOCUS ************ User logins à Checks for IP range --- if trusted IP – allowed to login --- if not trusted IP – system challenges by sending an email with link, if the user clicks on the link, allows thereby login access Profile login ranges User logins à Checks for IP range --- if trusted IP – allowed to login --- if not trusted IP – not allowed to login Profiles can also set time limits – time logins Phishing attacks – imposed by IP restrictions Session Security

• Can set the session timeout limit • Set secure connections (HTTPS- SSL) – enabled by default

Programmatic Security

• SOAP API or Metadata API can be used to programmatically access logic, data and metadata on Force.com

• Remote Site Settings • Security token append to IP addresses • OAuth 2.0 • Security Source code scanner

Platform Security framework

• System permissions – granted via profiles o Administrative permissions – Manage users, API only user, API enable, Author

APEX, Password never expires, Customize Application, Edit HTML templates o Reports – Customize and create reports, export reports, manage custom report o Data – Modify All data, view all data, edit read only fields, view encrypted data,

disable outbound messaging, weekly data export. • Component permissions

o Applications, tabs, record types, apex classes, vf pages, FLV • Record based sharing

o OWD o Sharing – manual, sharing rules, role hierarchy, territory hierarchy, apex


Locking down record access in salesforce Talks about balancing collaboration and security How do you stop confidential data from rolling up to the hierarchy – Set the grant access using hierarchies off for custom objects (if the data resides in these objects) with OWD = private For standard objects focus on ownership Look for profile settings like “View all data”, modify all data Sharing rules that grant additional access Encrypted field security There is a “Grant access using hierarchies” in a public group creation that can be setup to true or false based on requirement Behind the scenes of record ownership 3 important components that drive the ownership-based sharing architecture

• Owner field • Share table • Group membership

Sharing rule

• Has a source group • Target group • Checks for role hierarchy definition in both the groups – source and target • It creates a share record


Define External Objects Tables in external systems map to external objects in salesforce. Relies on external data source to connect with external system’s data. Maps to a data table on external system. External objects enable Salesforce users to search and interact with external data. Limit 100 objects per org Record Level Access – under the hood 2 types of access definitions are critical:

• Record level access (sharing) • Object level access – includes field level security

Salesforce recalculation of sharing happens because it tries to reduce the number of object joints to make to determine access at run time. Access Grants ************* EXAM FOCUS ************

• Explicit grants – Ownership, sharing rule, assignment rule, territory assignment, manual sharing, account/opportunity sharing, programmatic sharing

• Group membership grants – occurs when the user is a member of a group, queue, role, territory is having explicit grant.

• Inherited grant – when a manager gets access to a record cos of the subordinate then its called inherited grant

• Implicit grant – access to parent when they have access to child Sharing Rows

• Id of the record to grant access for • Id of the group/user to grant access to • Level of access • Row cause

If a user has multiple access grant then the most permissive access is granted when viewing the record Account teams ************* EXAM FOCUS ************ Provide additional access to account

• In Salesforce Classic, other users with edit access on the account can only add team members. In Lightning Experience, other users with edit access on the account can add and edit team members, but only changes to the Team Role field are saved.

• If a user on an account team has Read/Write access (Account Access, Contact Access, Opportunity Access, and Case Access) and is deactivated, the access will default to Read Only if the user is reactivated.


• Unless specified, removing a member of your account team does not remove that person from your opportunity teams. If a team member is on your default account team and you remove him or her from a specific account, those changes only affect that account.

• Clicking Add Default Team adds the default team of the opportunity owner, not of the user who clicks the button.

Create a custom list view in Salesforce classic List views are visible to your community users with Customer Community Plus, Partner Community, Lightning Platform Starter, and Lightning Platform Plus licenses, if the Visible to all users setting is enabled for views of objects in community user profiles. To make list views visible only to your Salesforce users, select Visible to certain groups of users. Then share the view with the All Internal Users group or a selected set of internal groups and roles. Share a Report or Dashboard Folder in Salesforce Classic When you create a folder, you’re its manager. Only you and others with administrative permissions can see it.

If a folder does not have Manager access, it’s public, and users with the View Reports in Public Folders permission can view it. Depending on their object access, these users can also run the report.

You can share a report or dashboard folder with up to 25 users, groups, or roles at one time. You can share a folder with up to 100 users, groups, or roles using the folder sharing REST API. Communities User Licenses http://salesforce.vidyard.com/watch/5kixavmXPC372dCZ37Z2dv 3 types of licenses


• Customer community licenses

o Ideal for customer portal. Peer 2 Peer. Knowledge base, asking other community members questions, creating case or 2

o Portal – login, report a missing credit card, update a card • Customer community plus

o Customer community – B2B, B2C which doesn’t involve sales, sharing capabilities, access to report and dashboards

• Partner community o Leads, opportunities, campaigns – partner collaboration

1. Enable the account as a partner account 2. Create a contact 3. Enable the contact as a partner user

Username uniqueness – for cc and cc+ unique within the org that the community belongs to. PC and EC (employee community) require unique usernames across all Salesforce orgs Sharing Sets in community ************* EXAM FOCUS ************ Grant portal or community users access to records that are associated with their accounts or contacts using sharing sets, based on their user profiles. For example, grant users access to all cases related to an account that’s identified on the users’ contact records.


The following objects can be used with sharing sets: § Account § Asset § Contact § Case § Custom Objects § Order § Person § Service Contract § User § Work Order

1. Select a value in the User drop-down list to determine the account or contact

lookup on the user. 2. Select a value in the Target Object field to determine the account or contact

lookup on the target object. For example, to grant access to all cases associated with an account identified on the user’s contact record, select Contact.Account and Account respectively. Sharing groups ************* EXAM FOCUS ************ Share groups allow you to share records owned by high-volume community users with internal and external users in your communities. Territory Management

• Territory Type - organize your territories by key characteristics important to your company

• Territory - organize groups of accounts and the Salesforce users who work with those accounts. Created based on territory type.

• Territory Model - represents a complete territory management system for your organization.

• Territory Hierarchy - shows a model's territory structure and serves as its main interaction point.

• Territory Model State - organization can only have one active territory model at a time • Territory Type Priority - Allows one to choose the correct Territory Type when

creating or editing Territories. Higher priority might imply that more territories of that type should be created etc.


************* EXAM FOCUS ************ Difference between 1.0 vs 2.0 https://help.salesforce.com/articleView?id=000212568&type=1 Territory Management Considerations

• Territory Management is not reversible. • You are now managing two hierarchies (Role and Territory) which means sharing is

more complex. Best practice is to flatten (or simplify) role hierarchy as much as possible. Make your role hierarchy your non-sales hierarchy, try to flatten the sales department branches, and then use territory hierarchy as your "sales" hierarchy.

• DO NOT make role hierarchy and territory hierarchy identical because it will cause unnecessary sharing recalculation.

• Some features such as Delegated Admin, My Teams filters, and Folder-based access are

only available for Role-hierarchy. Not for Territory Hierarchy! • Should you use teams? It is better to use territories rather than use teams when Territory

management is in place.

Programmatic Sharing – 25% Sharing a Record Using Apex

• “Object[Share]” for standard objects • “Object[__Share]” for custom objects • No share object for the detail in master as the OWD is “controlled by parent”

Creating Apex Managed Sharing Schema.CustomObject__Share.rowCause.SharingReason__c Know what are the possible AccessLevel and related exceptions that are thrown on the same. Apex Managed Sharing and Customer Community Plus Users Share objects, such as AccountShare and ContactShare are not available to these users. Consider using a trigger with the 'without sharing' keyword. Else use an inner class wtih same keyword to enable the DML operation to run successfully. Granting visibility via manual/apex shares written to the share objects is supported but the objects themselves aren't available to Customer Community Plus users.


Dynamic Data Sharing 1. Data changes, shared receivers are the same = use criteria based sharing 2. Data changes, users also change = Apex managed sharing

************* EXAM FOCUS ************ Protecting Force.com Custom Sharing Code 2 use cases:

1. Apex managed sharing: for custom objects, use apex sharing reasons to sustain share records over record owner changes

2. Programmatic sharing for standard objects – a. Write outbound messaging or Trigger or Shadow Object and recreate shares.

Without sharing To enforce the 'intent' of the configured security settings, not the implementation - object security and FLS, it is still important to enforce security boundaries so that these do not violate the 'intent' (eg: mistakenly exposing the task counter to a field user which is supposed for backend calculation purposes) ************* EXAM FOCUS ************ Enforcing Sharing Rules

• executeAnonymous and Chatter in apex ALWAYS executes using the full permissions of

the current user, unlike Apex in general which runs in system context which ignores current user's permissions, field-level security and sharing rules.

• with sharing on a class enforces sharing rules whenever the class is invoked (even if invoked from a class without sharing)

• without sharing on a class ignores sharing rules whenever the class is invoked (even if invoked from a class with sharing)

• Inner classes enforce or ignore sharing based on caller (same sharing context as the code that calls it)

• Inherited classes inherit the same sharing context as the parent. (eg: a class B that extends class A without sharing also has without sharing)

• If a class doesn’t specify with sharing or without sharing, it runs with the effect of the caller class. Here comes my fav statement – when the called class has no definition then it cares for the caller class to call out for the definition!

Using Apex Managed Sharing to Create Custom Record Sharing Logic Building sophisticated and dynamic sharing settings isn’t the only reason to use Apex managed sharing. You may also find advantage in the fact that share records created by Apex managed sharing behave differently than the other forms of record-level sharing: • Sharing records created by Apex managed sharing are maintained across record owner

changes. • The only users that can add, edit or delete sharing records created by Apex managed sharing

are users with the "Modify All Data" permission. • A record can be shared multiple times with a user or group using different Apex sharing

reasons. Examples of Apex Managed Sharing 1. Grant access to specific users (specified via lookup fields on record) upon insert 2. Grant access to group of users after record meets certain criteria Enforcing Object and FLS in Apex and VF

• In standard controllers  <apex:outputText value="{!contactName}" rendered="{!$ObjectType.Contact.fields.Name.Accessible}" />  <apex:commandButton action="{!CustomDelete}" rendered="{!$ObjectType.Contact.Deletable}" />

• In custom controllers o isAccessible, isCreateable, isUpdatable, isDeleteable on

Schema.DescribeSObjectResult o isCreateable, isAccessible, isUpdatable on Schema.DescribeFieldResult o Sometimes, the access level granted by a sharing rule could conflict with an

object-level or field-level permission.


Sharing Cheat Sheet The following cheat sheets is from another blogger which talks about the basics of sharing. Sharing Metadata Records • “Object[Share]” for standard objects • “Object[__Share]” for custom objects • Fields: access level, record ID, user or group ID • Share records are not created for OWDs, role hierarchies or the “View All” or “Modify All”

permissions Implicit Sharing • For Accounts, Contacts, Cases and Opportunities only. • A platform feature, cannot be disabled. • Access to a parent account—If you have access to a child contact, case or opportunity

record of an account, you have implicit Read Only access on that account. • Access to child entities—If you have access to a parent account, you may have access to the

associated contact, case or opportunity child entities. Access is configure per child object when creating a new role.

Organisation-Wide Defaults (OWD) • All standard objects use sharing access through hierarchies and this cannot be disabled • Public (Read or R/W) can be seen by all users (including portal) • Can’t be changed for contacts if person accounts are enabled

No Relationship

• All options are available Master Detail

• Child objects have their sharing access level and ownership dictated by their parent. This also stands for any grandchildren. The parents value for “Grant access through hierarchies” is also inherited.

• Child objects don’t have a share-record of their own and will be shared along with the master record.

• In fact, you cannot even define sharing rules from the object detail-page. Lookup

• Child objects can have their own sharing access level and ownership. Sharing access through hierarchies can also be disabled.

Manual Sharing • Removed when owner changes • Removed when access via OWD becomes at least as permissive as the share


• Private Contacts (those without an Account) cannot be shared manually Apex Managed Sharing • Can be used for Manual Sharing although it isn’t called Apex Managed Sharing in this

context • Using Apex to share Standard Objects is always considered Manual Sharing i.e. Apex

Managed Sharing is only really a feature for Custom Objects • Maintained across ownership changes • Requires “Modify All” permission

Recalculation

• Need to create a class that implements the Database.Batchable interface • The recalculation is run when the OWD for the object changes • The OWD for the object in question must not be the most permissive access level

Choosing the Right Share Type “Traditional” / Ownership-based Sharing Rules

• You want to share the records that a user, group, queue or role own with another user, group or role (includes portal users with roles).

Criteria-based Sharing Rules

• You want to share records based on values of a specific field or fields with another user, group or role (includes portal users with roles).

Apex Managed Sharing Rules

• Your sharing requirements are batshit cray-cray. Examples include: o Sharing multiple records at once o Sharing records on object A based on criteria being met on object B o Criteria-based sharing using a field not supported by “Criteria-based Sharing”

Manual Sharing Rules

• The record owner, or someone with modify all permission, wants to share an individual record with another user, group or role (includes portal users with roles)

Share Groups

• You want to share records owned by HVP users with internal users, groups or roles (includes portals users with roles)

Sharing Sets


• You want to “share” records with HVP users. These records need to fulfill the following criteria: o Objects has an organization-wide sharing setting different from Public Read/Write o Objects is available for Customer Portal o Custom object has a lookup field to account or contact

Portals High Volume Portals (Service Cloud Portals) • Include High Volume Customer Portal and Authenticated Website profiles • They have no roles and can’t participate in “regular” sharing rules • You can share their data with internal users through Share Groups • You can share object records where the object is a child record of the HVP user’s contact or

account. This is done with Sharing Sets. • They can also access records that are:

o Available for portal, and o (Public R/RW OWD, or o (Private OWD, and o They own the record))

• They can access a record if they have access to that record’s parent and the OWD is set to “Controlled by parent”

• Cases cannot be transferred from non-HVP to HVP users other portals

• Have a role hierarchy at most 3 levels deep and can participate in regular sharing o Person accounts only have a single role o Business accounts can have 1 – 3 roles.

Large Data Volumes • Defer sharing settings (enabled by logging a case) and group calculation on large data loads

and modifications If you’ve got any other items you think should be in this list, let me know in the comments. Peas oat.

sharing and visibility designer certification crib sheet › 2018 › 02 › ... · 2018-05-03 ·...

Documents