Sharing and record access can be a tricky concept in Salesforce, and with Apex Managed Sharing as an option, it becomes even more complex and options are nearly limitless. So when and why would a system admin or developer leverage this functionality? There are cases where the flexibility of the platform’s declarative options are simply not flexible enough to meet business requirements, and this occurs in a variety of ways:
Logic needs to look across multiple objects for “criteria-based” sharing
Logic needs to look at record owner, and then use a complex approach to sharing the record
Business leverages ad hoc teams, and these drive record access on custom objects
Entitlements are managed externally to Salesforce, and Salesforce must inherit these changes
These use cases are hard or impossible to solve with the declarative based options below, which is why we leverage Apex Managed Sharing. Always try to leverage declarative functionality where possible, and if a business requirement is not concrete, try to understand the nature of the request. During the August meeting of the Financial Services User Group, I offered a strategy of using the Five Whys technique for iterative understanding the root cause of a requirement or problem:
Declarative sharing rules (i.e. criteria-based, ownership-based)
Role Hierarchy
Standard “teams”: Account Teams, Sales Teams, Case Teams
User Sharing / Manual Sharing: a user manually extends other users or groups should have access
Profiles & Permission Sets extending object-level access: View All, Modify All
A Use Case for Wealth Management Firms
Financial accounts often are managed by a team of wealth management professionals, and in some cases only specific team members should have access to a financial account. Firms can approach these as either preset teams, or ad hoc team assignments based on availability and specialization of employees. Let’s dive further into the ad hoc team approach, as this is a pattern often seen in medium-sized wealth management firms.
Above we have two clients, Bob Smith and Sally Dole. Bob is related to a single financial account (1234), and Sally is related to two financial accounts (1234 and 5678). Each of these accounts has a service team of employees (as shown in the table below), and we see there’s an overlap in the teams for Wealth Advisor 2 and Assistant 3. The firm has a mandate that only employees on the service team are able to view the financial account records. How can we leverage Apex Managed Sharing to solve this problem?
Account 1234 | Account 5678 |
|
|
Within our data model, we have a joiner object that facilitates the many-to-many relationship that a user can have to financial accounts, and these “Account Service Team” records are represented as the smaller boxes in the diagram above. From this object, we know a user ID and a financial account ID, which are all we need in an Apex trigger to share this object with users.
Our trigger will create a record in the Financial Account sharing object (known by its API name of Financial_Account__Share) whenever an Account Service Team record is created. This record will specify a record ID, a user or group ID, and an access level. Based on our example, Wealth Advisor 2 and Assistant 3 will have two records in this sharing table, whereas other users only will have access to one of the financial accounts.
While this is a rudimentary example, Apex Managed Sharing can be far more complex (or simple), depending on requirements for users. It’s important to understand that Apex Managed Sharing is best used as a complement to the declarative functionality in Salesforce, and not to rewrite Salesforce’s record access model. For more information on how Salesforce shares records, check out the “Record-Level Access: Under the Hood” white paper from Salesforce Developers that talks about the nitty gritty details.
Do you have questions about Apex Managed Sharing, or how this approach is leveraged for wealth management firms? If so, please drop a comment below or reach out to us directly on our contact us page.