If you’ve ever been a Salesforce #AwesomeAdmin, you’ll find the Sharing and Visibility Designer exam to be one of the simpler ones. I’ve heard from a few developers lately that they, on the other hand, have found this to be one of the hardest in the architect pyramid. Well, with this blog post, I aim to take away some of the difficulty for you.

What Sharing and Visibility Means

The concept of Sharing and Visibility doesn’t just refer to permissions; in fact, there are a number of different features in Salesforce that contribute to data security. The architect certification aims to test your knowledge at a holistic level: given any scenario that they can throw at you, how would you achieve what the client wants?

As always, your best friend for this exam is the Resource Guide. Here is a breakdown of things you need to know to pass.

Sharing Architecture

Org-Wide Defaults (OWD)

These are applied per object (note that objects related via master-detail relationship will inherit the OWD from their parent). There are 3 types:

• Public Read Write: A free-for-all; everyone can see and change any record
• Public Read Only: Everyone can see and search for the record, but only the owner and those who are positioned above the owner in the role hierarchy can change it
• Private: Only the owner and those above them in the role hierarchy can find or change the record

The moment you have a requirement from somebody to keep a piece of data hidden away or uneditable for certain people, your OWDs need to be changed.

Role Hierarchy

• Typical clients will try to set this up using their organisational structure – and that’s fine as long as that structure also reflects how data should be shared. Obviously, if everything is Read/Write, that matters a lot less.
• Users are assigned a role when they’re first set up.
• Note that if you have any users who will own millions of records, it’s best practice to make sure that user has no role, to optimise performance.
• A typical role hierarchy could be:
  • CEO (Cheryl)
    • COO (Colin)
      • VP of Sales (Sarah)
        • Field Sales Manager
          • Field Sales Team Lead
            • Field Sales Rep
        • Inside Sales Manager (Simon)
          • Inside Sales Team Lead (Denise)
            • Inside Sales Rep (Martin)
        • Strategic Accounts Manager (David)
          • Strategic Accounts Team Lead
            • Strategic Accounts Rep
      • VP of Customer Service
        • Customer Service Manager
          • Customer Service Team Lead
            • Customer Service Agent

You get the picture. So if your OWD for Opportunities is Private, and the owner is Martin:

• Martin can see and edit his own opportunities
• Denise can see and edit her own opportunities, as well as Martin’s and any other Inside Sales Reps’ Opportunities
• Simon can see and edit his own opportunities, as well as Martin’s, Denise’s and any other Inside Sales Reps’ Opportunities
• Sarah can see and edit her own opportunities, as well as any Opportunity owned by any users beneath her – across field sales, inside sales and strategic accounts.
• Colin can see exactly the same as Sarah. He wouldn’t usually own any opportunities of his own.
• Cheryl has visibility across the entire organisation – as well as her own opportunities. Should Cheryl need to set up any opportunities of her own, they would only be visible and editable to her under this sharing model.

Check out my Ladies Be Architects study group and quiz on sharing architecture:

Sharing Grants

Let’s say that for this example, our CEO Cheryl’s opportunities need to be shared with the Strategic Accounts Manager, David, as well as the VP of Sales, Sarah.

There are a few ways you could share Cheryl’s opportunities with these individuals:

• Sharing rules:
  • Cheryl could have a blanket rule that says any opportunities she owns should automatically be shared with David and Sarah’s roles on a Read/Write basis.
  • Cheryl could also have a blanket rule that says any opportunities she manages with a Type of “Strategic” should automatically be shared with David and Sarah’s roles on a Read/Write basis

• Manual sharing:
  • Cheryl could just click “Sharing” and give Read/Write permission to David and Sarah. That’s useful on a case-by-case basis.

• Team sharing:
  • Adding David and Sarah to Cheryl’s default Account team would grant Read/Write access to Accounts owned by Cheryl, and their related opportunities (if that’s what’s needed)
  • Cheryl could also add David and Sarah to the Account team of any individual Accounts that she owns, thus granting access to the Account and related opportunities
  • Adding David and Sarah to the Sales Team of her opportunities on a case-by-case basis would grant Read/Write access
  • Note: the same can apply to Cases via Case Teams.

• Apex sharing:
  • This is the sort of thing you’d want to do when you’ve exhausted all other options and the use case just doesn’t fit the above. Get a developer to write some fancy Apex.
  • Each object in the database also has a “share” table. Using Apex, a developer can add entries to a Share table and thus grant access.
    • Example: a Project record with numerous objects related to it via Lookup. You want to share all related records with the owner – use an Apex sharing rule.

Account Territories

Territory hierarchies are ways you can allocate an account to multiple territories, based on the structure of your sales strategy. Learn more about this in the Ladies Be Architects study group slides. You will need to

• Understand what the right use cases are for Territory Management
• Understand the trade-offs if you choose to implement it
• Have some practical experience of setting it up (even if you just mock it up in a trailhead playground, it helps)

Ladies Be Architects’ first study group session took a look at Enterprise Territory Management in detail:

Sharing architecture is easily referred to in this handy pyramid that Salesforce provides in its Guide to Sharing Architecture:

Security

Controlling access to Files

Become familiar with the following concepts:

• the File Owner
• a File Collaborator
• File Viewer

…and the ways you can share files with these individuals.

Why Salesforce has record owners

There is a great article in the Resource Guide that will help you understand how and why Salesforce went against tradition and opted for an ownership model when it developed its platform. It also goes into great detail about how this works under the bonnet – I’d highly recommend studying this.

Custom Permissions

Custom permissions are pretty cool ways to restrict user permissions within a set use case. For example, according to the help guide, “…you can define access checks in Apex that make a button on a Visualforce page available only if a user has the appropriate custom permission.”. Just another handy tool when you’re designing applications.

Controlling Access to Reports and Dashboards

Know your folder access levels. For a bonus, understand that you can protect these further using two-factor authentication. Did you know you can force people to enter an authorisation code to view reports? Neither did I. It tends to come up in the Identity and Access Management exam, but is additionally useful for this one too.

External Objects

If you’re not familiar with Salesforce Connect, it’s time to get familiar. Study the guide, but remember these principles:

• External objects are treated like custom objects in the API
• External objects are a way to expose tables from an external database within Salesforce.
  • You can add your own fields, but these fields are only populated inside Salesforce.
  • You can’t send this extra data back to its source; you’ll need to integrate via the API to do that.
  • They’re clever enough to link via an external ID.
    • For example, if you’re exposing Orders from SAP in an external object and the order has a customer ID number you already keep in Salesforce, you can create an indirect lookup to link that Order record to an Account in Salesforce. Fancy!

Implicit Sharing

Know what gets shared automatically and how. Difficult and lengthy to explain here, but this article will explain the types of implicit sharing listed here:

• Parent
• Child
• Boss
• Portal
• Community
• Community Parent

Sharing Between Internal and External Users

• Sharing records
  • Owned by high-volume community users (who don’t have roles) to internal and external users – share groups are your friends!
  • To high-volume community users (who don’t have roles) – sharing sets for the win! (“A sharing set grants high-volume users access to any record associated with an account or contact that matches the user’s account or contact.”)

Encryption

I’d highly recommend studying

• best practices encrypting custom fields
• the differences between platform encryption and classic encrypted fields
• the Apex Crypto class

Handling Large Data Volumes

If you’ve already passed the Data Architecture and Management certification exam, this should be easier than you’d expect. Here’s where the crossovers are:

• Reducing the risk of lock contention
• The impact of ownership skew and how it can be avoided
• Group membership sharing
  • setting up sensible public groups to optimise performance
  • avoiding too many records in the object’s share table by adding people to groups and sharing with the group
    • As a rule, I tend to go
      • Person —> belongs to a Role
      • Role or Role and Subordinates —> belongs to a public group
      • Territory —> belongs to a public group
      • Group —> belongs to a queue…..

but you can use other groups and individual users too. The principle is to try to share with the topmost level in your group architecture, but the article provided by Salesforce explains it much better than I can.

Overall, I found this to be an enjoyable exam which I look forward to studying again when I take my CTA certification! If you want to see all of this being demonstrated, I recently recorded a Ladies Be Architects study group on this very topic. Give it a watch when you can:

I wish you all the very best of luck with your exam; tweet me @gemziebeth if you’d like to discuss or recommend any additions!