I finally decided to take this Sharing and Visibility Designer exam after 7 months since my last Salesforce certification. Between Salesforce and other potential career paths, I decided to stick with Salesforce path. Though I have already acquired both administrator and developer certifications, I am aiming to get architect certification in my Salesforce career. I have thought of getting certified in AWS or in Linux as well, but that's not my current plan now. My current plan is to consolidate and further advance my skills and knowledge in Salesforce technology, so here we go!

Declarative Sharing section weighs 76% of total score in this exam, so please be well prepared for it! Without further ado, let's get started!

NOTE: This post is written in April 2020 and content might be changed/updated overtime. The content is inspired by focusonforce.com.

Guideline for Declarative Sharing

• Given a particular customer scenario, describe the appropriate use and limitations of relevant object and field level security settings needed to allow and limit users access to different types of information.
• Given a particular customer scenario, apply the relevant settings required for all the declarative platform security features that would ensure proper data access to relevant users.
• Given a scenario, demonstrate your ability to properly evaluate the use case for and implement teams to ensure the proper visibility and collaboration requirements are implemented.
• Demonstrate how views and folders can be segmented for different groups using out of box security features, such as groups or roles, in an effective manner while keeping in mind security considerations and how these differ from record level security considerations.
• Given a particular customer's organization hierarchy describe the impact of role hierarchy on record sharing.
• Given a scenario that involves external users, describe how the security and sharing setup can be utilized to properly enforce record visibility for different types of community users. Specifically: Internal, Customer Community, Customer Community Plus, Partner Community.
• Given a particular customer scenario, have awareness of how Enterprise Territory Management can (or cannot be applied) to resolve more complex security requirements.
• Given a customer's particular data storage and data residency requirements, have awareness of solution options in the marketplace that properly leverages declarative and programmatic security features of Salesforce.
• Given an Architect's design and configuration of the sharing and security model, describe the methods of validating the sharing and visibility.
• Given a scenario that involves files sharing, describe how files are shared and secured in Salesforce and what are the different options to storing file securely in Salesforce.

Type of Data Access

License Types

• Full Sharing Model Usage Users/Licenses
  • Most Standard Salesforce license types take full advantage of the sharing model components.
  • The license might not make a module accessible, or even some objects accessible. For example, the Free edition can't access any CRM objects.
  • However, the sharing entities, and functionality, still exists and is ready when and if the module ever does become active.
• High Volume Customer Portal (HVPU) License
  • HVPU license users (including Community and Service Cloud license users) do not utilize the sharing model.
  • HVPU licenses have their own sharing model that works by foreign key match between the portal user (holding the license) and the data on Account and Contact lookups.
  • HVPU license is only used for the Customer Portal and not the Partner Portal.
• Chatter Free License
  • The Chatter Free license doesn't follow the standard sharing model.
  • Chatter Free is a collaboration-only license with the following features: Chatter, Profile, People, Groups, Files, Chatter Desktop, and limited Salesforce app access.
  • The license doesn't have access to CRM records (standard or custom objects) and Content functionality, and therefore, there is no sharing.

Sharing Components

• Profiles and Permission Sets

  • Profiles and Permission Sets can be used to set object-level security (CRUD) and Field-Level Security (FLS).
  • Permission Set Group:
    • Permission Set Groups can be created to group permission sets together and assign to users.
      
      • Permission Sets in Group:
        
      • Muting Permission Set in Group:
        • Create Mute Permission Set Groups:
          
        • For example, you can disallow user to create Account object:
          
        • NOTE: only one mute permission set can be created in each Permission Set Group:
          
      • Combined Permissions:
        
        • NOTE: the section here is for views only, you cannot modify anything here.

• Record Ownership and Queues

  • Every record is either owned by user or queue.
  • Record's access is based on the Object Settings for the owner's profile.
  • Managers gain as much access as their subordinates:
    • If the subordinate has read-only access, so does the manager.
    • This access applies to records owned by users, as well as records shared with them.
  • Queues help you prioritize, distribute, and assign records to teams who share workloads.
  • Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue.

• Organization-Wide Defaults (OWD)

  • OWD specifies the default level of access.
  • Changes in OWD settings will result in sharing recalculation, resulting in long processing times if volume is heavy.
  • Grant Access Using Hierarchies is available for custom objects only.

• Role Hierarchy

  • Role Hierarchy represents a level of data access that a user or group of users needs.
  • Role Hierarchy ensures that managers always have access to the same data as their employees.
  • Default limit is 500 roles, but can be increased by contacting Salesforce.
  • Best practices:
    • keep the number of non-portal roles to 25,000
    • keep the number of portal roles to 100,000
    • keep the role hierarchy to no more than 10 levels of branches in the hierarchy

• Public Groups

  • Public Group (not Chatter group) is a collection of individual users, roles, territories, and so on, that all have a function in common.
  • Public groups can consist of:
    • Users
    • Customer Portal Users
    • Partner Users
    • Roles
    • Roles and Internal Subordinates
    • Roles, Internal and Portal Subordinates
    • Portal Roles
    • Portal Roles and Subordinates
    • Territories
    • Territories and Subordinates
    • Other public groups (nesting)
  • Groups can be nested (Group A nested into Group B), however don't nest more than 5 levels.
  • Nesting has an impact on group maintenance and performance due to group membership calculation.
  • Group membership alone doesn't provide data access, you need to use other sharing tools to give the group the necessary access.
  • Best practices:
    • keep the total number of public groups to 100,000

• Ownership-based Sharing Rules

  • Ownership-based Sharing Rules allow for exceptions to Organization-wide Default settings and the Role Hierarchy that give additional users access to records they don't own.
  • Ownership-based Sharing Rules are based on the record owner only.
  • Contact ownership-based sharing rules don't apply to private contacts.
  • Best practices:
    • keep the number of ownership-based sharing rules per object to 1,000

• Criteria-based Sharing Rules

  • Criteria-based Sharing Rules provide access to records based on the record's field values (criteria).
  • If the criteria are met (one or many field values), then a share record is created for the rule.
  • Best practices:
    • keep the number of criteria-sharing rules per object to 50

• Manual Sharing

  • Manual Sharing can be used to give permissions to users who would not have access to the record any other way.
  • Manual sharing is removed when:
    • the record owner changes
    • when the sharing access granted doesn't grant additional access beyond the object's organization-wide sharing default access level (also applies to manual shares created programmatically)
  • Manual share records are defined as share records with the row cause set to "Manual Sharing".
  • All share records (standard and custom objects) with a row cause set to Manual Sharing can be edited and deleted by the Share Button on the object's page layout (even if the share record was created programmatically).

• Teams

  • Team is a group of users that work together on an account, sales opportunity, or case.
  • Record owners can build a team for each record that they own.
  • Record owners can add team members and specifies the access level each team member has to the record.
  • Only owners, people higher in the hierarchy, and administrators can add team members and provide more access to the member.
  • A team member with Read/Write access can add another member who already has access to the record with which the team is associated. The team member can't provide them additional access.
  • Creating a team member in the app creates two records: a team record and an associated share record.
  • If you create team members programmatically, you have to manage both the team record and associated share record.
  • There is only one team per record (Account, Opportunity or Case).
  • If multiple teams are needed, you can consider Territory Management or Programmatic Sharing.
  • The team object is not a first-class object. You can't create custom fields, validations rules, or triggers for teams.

• Territory Hierarchy

  • Territory Hierarchy is a single dimensional, additional hierarchy which can be structured by business units or any kind of segmentation in a hierarchical structure.
  • When territory management is enabled you must manage both the role hierarchy and territory hierarchy.
  • Territories exist only on Account, Opportunity and master/detail children of Accounts and Opportunities.
  • Sharing rules using that territory as the source will be recalculated when the assignment rules for a territory are changed.
  • Any ownership-based sharing rules that use the territory as the source will be recalculated when the membership of a territory changes.
  • Best practices:
    • keep the territory hierarchy to no more than 10 levels of branches in the hierarchy

• Account Territory Sharing Rules

  • Account Territory Sharing Rules become available only when the original territory management feature has been enabled for an organization.
  • Account Territory Sharing Rules provide access to Account records that have been stamped with the Territory defined in the rule.

• Programmatic Sharing

  • Programmatic Sharing (formally Apex Managed Sharing) allows you to use code (Apex or other) to build sophisticated and dynamic sharing settings when a data access requirement cannot be met by any other means.
  • If you create a share record programmatically, and the out-of-box row cause (manual share) is used, then you can maintain this share record with the Share button in the app.
  • The share record is subject to all rules with the manual share row cause such as deletion upon owner transfer.

• Implicit Sharing

  • Implicit Sharing is automatic. You can neither turn it off, nor turn it on—it is native to the application.
  • Parent Implicit Sharing provides access to parent records (for Account only) when a user has access to children Opportunities, Cases, or Contacts for that account.
  • Child Implicit Sharing provides access to an Account’s child records to the account owner.
    • It is defined at the owner's role in the role hierarchy.
    • It is only applicable to Contact, Opportunity and Case objects with access of View, Edit or No Access.
  • Implicit sharing doesn't apply to custom objects.

• Other sharing settings:
  

  • User Visibility Settings:
    • Portal User Visibility - portal users in the same customer or partner portal account can see each other, regardless of OWD. If Community User Visibility is also selected, users from the same community can see each other as well.
    • Community User Visibility - community users in the same community can see each other, regardless of OWD. If Portal Use Visibility is also selected, portal users can see other portal users from the same account as well.
  • Other Settings
    • Standard Report Visibility - users can view reports based on standard report types that may expose data of users to whom they don't have access, regardless of OWD.
    • Manual User Record Sharing - users can share their own user record
    • Manager Groups - users can share records with their managers and manager subordinates groups
    • Use person role for first user in community account - assign person roles to new community users in accounts without existing users. This setting also applies to High Volume Customer Portal userswho upgrade to Customer Community Plus or Partner Community licenses. If this setting is disabled, portal roles are created for new users.
    • Grant community users access to related cases - users with Customer Community Plus licenses can view and edit cases which they are listed as the contact
    • Secure guest user record access - secure the access that guest users have to your org's data. Guest users' org-wide defaults are set to Private for all objects, and this access level cannot be changed. You can create guest user sharing rules, but you can't add guest users to groups or queues or manually share records with them.

Object and Field Level Security Settings

• Object-Level Security
  • specify in Profiles or Permission Sets to grant CRUD permissions to users on object
  • Transfer Record permission needed to transfer all objects
  • Transfer Lead permission needed to transfer Lead
  • Transfer Case permission needed to transfer Case
• Field-Level Security (FLS)
  • specify in Profiles or Permission Sets to let users view or edit specific standard or custom fields on objects
• Profiles
  • defines users access data and objects and what they can do within an app
  • each user can have only one and only one profile set
  • standard profiles cannot be modified
• Permission Sets
  • extends users' permissions without changing profile settings
• User Profile permission descriptions

Declarative Platform Security Features

• Organization-Wide Default Settings (OWD)
  • specify the default access level for an object's records in an org

Object	Default Internal Access
Lead	Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer
Account and Contract	Private, Public Read Only, Public Read/Write
Order	Controlled by Parent, Private, Public Read Only, Public Read/Write
Contact	Controlled by Parent, Private, Public Read Only, Public Read/Write
Asset	Controlled by Parent, Private, Public Read Only, Public Read/Write
Opportunity	Private, Public Read Only, Public Read/Write
Case	Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer
Campaign	Private, Public Read Only, Public Read/Write, Public Full Access
Campaign Member	Controlled by Lead or Contact, Controlled by Campaign
User	Private, Public Read Only
Activity	Controlled by Parent, Private
Calendar	Hide Details, Hide Details and Add Events, Show Details, Show Details and Add Events
Price book	No Access, View Only, Use
Other	Private, Public Read Only, Public Read/Write

• Role Hierarchy
  • specify which users should have access to data owned by or shared with their subordinates
  • standard objects are Grant Access Using Hierarchies by default
  • the user role can have implicit access to the associated child records, ex: account owner's role can determine the level of access to Case and Opportunity
    
• Sharing Rules
  • share records by record owner
    • share from: Manager Subordinates Groups, Managers Groups, Public Groups, Roles, Roles and Internal Subordinates, Roles, Internal, and Portal Subordinates, Portal Roles, Portal Roles and Subordinates, Territories, Territories and Subordinates
    • share with: Manager Subordinates Groups, Managers Groups, Public Groups, Roles, Roles and Internal Subordinates, Roles, Internal, and Portal Subordinates, Portal Roles, Portal Roles and Subordinates, Territories, Territories and Subordinates
  • share records based on criteria
    • share with: Manager Subordinates Groups, Managers Groups, Public Groups, Roles, Roles and Internal Subordinates, Roles, Internal, and Portal Subordinates, Portal Roles, Portal Roles and Subordinates, Territories, Territories and Subordinates
  • share records based on criteria (Guest user access)
    • share with: Site Guest User
• Manual Sharing
  • manually share record with another user
  • access is removed when the record owner is changed
• Implicit Sharing
  • shares permissions between accounts and child records
    • ex: user can view account given that he/she is the case owner, opportunity owner or contact owner
  • shares permissions with portal users
  • manually share the Opportunity record will also gain Read access to Account, the reason will be "Associated record owner or sharing"
• Data Encryption
  • Classic Encryption v.s Platform Encryption:

Feature	Classic Encryption	Platform Encryption
Pricing	Included in base user license	Additional cost
Encryption at rest	✅	✅
Native solution (no hardware/software required)	✅	✅
Encryption algorithm	128-bit AES	256-bit AES
HSM-based key derivation	❌	✅
Manage encryption keys permission	❌	✅
Generate, export, import and destroy keys	✅	✅
PCI-DSS L1 compliance	✅	✅
Masking	✅	❌
Mask types and characters	✅	❌
View encrypted data permission required	✅	❌
Encrypted standard fields	❌	✅
Encrypted attachments, files and contents	❌	✅
Encrypted custom fields	175 characters field type	✅
Encrypt existing fields	❌	✅
Search (UI, partial search, lookups, certain SOQL)	❌	✅
API access	✅	✅
Available in Workflow Rules and Field Updates	❌	✅
Available in Approval Process Entry Criteria and Step Criteria	❌	✅

• External Data Source
• Custom Permission
  • Custom permissions let you define access checks that can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings.
  • Query Custom Permission: Boolean hasCustomPermission = FeatureManagement.checkPermission('Test_Custom_Permission');
  • View Custom Permissions in Setup > Custom Permissions:
    
  • Create Custom Permission:
    
  • Select Custom Permission in Permission Sets:
    

Account, Opportunity and Case Teams

• Account Team

  • allows a group of users to access and work together on an account record
  • Team Roles:
    • Team Roles are a set of picklist values for Account Team members and Opportunity Team members
      
    • Replace Team Roles:
      
  • options available on Account Team Related List: Add Default Team, Add Team Members, Team Member Access, Remove All Members
    • Add Team Members:
      
      • NOTE: if you add members that are already existed in the team, the previous team member settings will be overwritten by the current one
    • view the Team Member Access after adding the team member:
      
      • NOTE: the Account, Opportunity and Case accesses are not determined by the team member access that we set, but rather the access to this record in general
    • Remove All Members will remove all the Account team members
    • create Default Opportunity Team by navigating to Settings > Advanced User Details > Default Account Team
      
  • you can set Automatically add my default account team to accounts that I create or accounts that are transferred to me
  • you can set Update account teams with these members when adding new team member and Update the account teams of my existing accounts when editing specific team member
  • Mass Reassign Account Teams:
    1. Choose to add, remove or reassign a team member
       
    2. Search for Accounts
       
    3. Select Accounts
       
    4. Add an account team member (if choose add team member)
       
    5. Remove an account team member (if choose remove team member)
       
    6. Replace or change the role of an existing account team member (if choose reassign team member)
       

• Opportunity Team

  • allows multiple sales users to work together on an opportunity record
  • Team Roles are a set of picklist values for Account Team members and Opportunity Team members
  • options available: Add Default Team, Add Account Team, Add Opportunity Team Members, Team Member Access, Remove All Members
    • NOTE: 'Add Account Team' button is only available if there is Account Team on the Account
  • create Default Opportunity Team by navigating to Settings > Advanced User Details > Default Opportunity Team
    
  • Team Selling can be enabled to turn on Opportunity Team in Setup > Opportunity Team Settings.
    • NOTE: if disabled this feature, existing opportunity teams are removed from all opportunities and users' default opportunity teams are deleted as well.
  • you can set Automatically add my default opportunity team to opportunties that I create or open opportunities that are transferred to me
  • you can set Update open opportunity teams with these members on create and Update opportunity teams of my existing open opportunties on edit

• Case Team

  • allows a group of people to work together on a case record
  • Case Team Roles determine the level of access to a case (unlike team roles for account and opportunity, no access level granted)
    
  • predefined case team can be setup for user, contact and customer portal user with respected member role
    
  • options available: Add Member, Add Team
  • Add Member (User or Contact):
    
  • Add Team:
    
  • NOTE: it will display the team's name, unlike Account Team or Opportunity Team which only adds the users into team after clicking the button
    
  • NOTE: Case is a special object which allows you to filter by case teams as well as queue owned cases
    

List Views and Folders

• List View

  • List View Visibility
    • Only I can see this list view
    • All users can see this list view (including Partner and Customer Portal User)
    • Share list view with groups of users
      • share with Roles, Public Groups, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates, Territories, and Territories and Subordinates
      • if none is selected, the list view is private
        
  • Manage Public List Views Permission
    • allow users to create, edit, and delete public list views
    • allow users to see all list views

• Report and Dashboard Folders

  • share with Users, Roles, Public Groups, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates, Territories, and Territories and Subordinates with access level of View, Edit and Manage permission
    
  • Manage Reports in Public Folders Permission
    • required permissions:
      • View Reports in Public Folders
      • Create Report Folders
      • Edit My Reports
  • Manage Dashboards in Public Folders Permission
    • required permissions:
      • View Dashboards in Public Folders
      • Edit My Dashboards
      • Create Dashboard Folders
  • View Reports in Public Folder Permission
  • View Dashboards in Public Folder Permission
  • NOTE: a report folder that does not have Manage access is public

Role Hierarchy on Record Sharing

• Roles
  • share records with the users in particular roles
• Roles and Subordinates
  • share records with the users in particular roles and its subordinate roles
• Grant Access Using Hierarchies
  • share records with the users up the role hierarchy
• Public Groups
  • share with Users, Roles, Public Groups, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates
  • check Grant Access Using Hierarchies to allow record shared with users in public group to be shared with the users up the role hierarchy
    

Record Visibility for Community

• 3 types of Community Licenses:
  • Partner Community (highest license tier, good for B2B sales, grant access to Salesforce object, ex: Lead, Opportunity, Campaign)
  • Customer Community Plus (access to reports and dashboards as well)
  • Customer Community
• External Sharing Settings
  • external Organization-Wide Defaults (OWD) can be specified
  • NOTE: the permission must be more restrictive or same as default internal access level
• Sharing Sets
  • grants community or portal users access to records that are associated with their accounts or contacts
    
  • grant access to records via access mapping in a sharing set, ex: share Case object where the Case's contact is same as user (contact)
    
  • NOTE: make sure the OWD for the object is set to Private
• Share Groups
  • share records owned by high-volume community users with internal and external users
    
  • share with Users, Roles, Public Groups, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates
    
• Roles and Advancing Sharing
  • roles can be used for Partner Community and Customer Community Plus licenses
  • Sharing Rules grant additional record access
    
• Super User Access
  • access can be granted to partners to let them access more records regardless of sharing settings
  • partner users can access data owned by other partners users who have same role or role below them (applies to Lead, Case, Opportunity and custom objects only)
  • Enable Partner Super User Access can be enabled in Communities Settings
  • you need to assign super user access to individual users, ex: click Enable Super User Access on the contact to grant the super user access
  • Customize Application permission is required to set this

Territory Management

• Territory Model
  • a new model is always created in Planning state
  • Territory Model can be in Cloning, Planning, Active, or Archieved state
• Territory Type
  • used to organize territories by key characteristics
  • each territory has a Territory Type
  • NOTE: Territory Type does not appear on Territory Model hierarchies
• Territory Assignment
  • Filter-based Opportunity Territory Assignment assigns territories to Opportunity automatically based on the filter logic defined in Apex class
  • Manually assigns a territory to Opportunity by setting Territory field
  • NOTE: users who do not have full access can assign only a territory that is also assigned to the opportunity's account
  • Assigned Territories related list can be added to Account page layout to see which territory is assigned to the Account record
  • Users in Assigned Territories related list can be added Account page layout to view all users assigned to the territory that is assigned to the Account record
• Manage Territories permission is required to play around with territory models.
• Find out more about Territory Management here.

Data Storage and Data Residency

• Encryption
  • Classic Encryption
    • encrypted custom fields are text fields that contains letters, numbers or symbols but are encrypted with 128-bit keys and use the AES algorithm
    • View Encrypted Data permission needed to view the encrypted field
    • stores encrypted data up to 175 characters
  • Shield Platform Encryption
    • gives your data a whole new layer of security while preserving critical platform functionality
    • enables you to encrypt sensitive data at rest, and not just when transmitted over a network, so your company can confidently comply with privacy policies, regulatory requirements, and contractual obligations for handling private data
    • secures your key material at every stage of the encryption process
    • lets you encrypt a wide variety of standard fields and custom fields (ex: long textarea field), files and attachments stored in Salesforce, Salesforce search indexes, and more
    • NOTE: Shield Platform Encryption cannot encrypt data in transit
  • Apex Crypto Class
    • allows protection of data at rest and in transit from unauthorized parties
    • provides algorithms for creating digests, MACs, signatures and AES encrpytion
    • when using crypto functions to implement AES encryption, keys must be generated randomly and stored securely in a Protected Custom Setting or Protected Custom Metadata Type
• Protecting Applications
  • Protected Custom Metadata Type
    • just like public custom metadata type, except it is suitable to store authentication or confidential data
    • usually used in managed package
    • do not use outside of a managed package, use Named Credential or encrypted custom field to store confidential material
    • can be updated via the Metadata API
    • can be read (but not updated) at runtime via SOQL code within an apex class in the same namespace
  • Protected Custom Setting
    • unlike custom metadata types, custom settings can be updated at runtime in your Apex class, but cannot be updated via the Metadata API
  • Named Credential
    • stores authentication data for external services called from your apex code, such as authentication tokens
    • Customize Application permission needed to view named credentials
    • NOTE: you do not need to defined for the site in Remote Site Settings because the URL is defined in Named Credential already
• Data Residency Options (DRO)
  • protects data fields before transmitting them from local database to Salesforce
  • use either Encryption or Tokenization, then decrypt the sensitive data before it can be viewed by users
    • Encryption - the organization maintains local control of the keys that DRO uses to encrypt and decrypt data
    • Search-Enabed Encryption - the DRO uses local key to encrypt and decrypt data but the search functionality is maintained
    • Tokenization - the DRO tokenizes sensitive data and lets users search and sort within tokenized data
• Proxy Service
  • 3rd party proxy service may be used by organization to access sensitve on-premise data from Salesforce

Sharing and Visibility Validation

• Login As
  • administrator can login as the user to check record visibility
• Sharing Button (Salesforce Classic only)
  • manually share a record with Users, Roles, Public Groups, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates, Managers Groups, Manager Subordinates Groups, Territories, and Territories and Subordinates
    
  • view all the sharing (view by sharing reasons):
    
  • you can click "Expand List" button to expand the sharing list (view by users):
    
  • click "Why?" on the action to view the reason for record access (view by user's sharing reasons):
    
• Sharing Table
  • stores the data that supports explicit and implicit grants related to the object's records
  • navigate to Setup > Sharing Settings to view Object Sharing Table
• Sharing Rows
  • provides information about the record, user or group to whom it grants access, level of access, and row cause
  • example of AccountShare (standard object):
    
  • example of Sales_Order__Share (custom object):
    
• Group Maintenance Table
  • stores data supporting group membership and inherited access grants
  • ex: if the Object Sharing table grants Bob explicit access to the Acme account record, Salesforce checks the Group Maintenance tables to see which users inherit record access from Bob and grants users access to the Acme record. These grants are established in advance when you create or change the group (or role, or territory) membership information
  • Object Sharing Table stores access grants to individuals and groups, Group Maintenance Table stores the list of users or groups that belong to each group, indicating group membership
• Field Accessibility
  • Field Accessibility in Setup can be used to quickly determine which page layouts, record types and user profiles include those fields
    

File Share and Security

• File Sharing Visibilities

Name	Description
Private	File is not shared with anyone. Like private report folder, file in private library can only be accessed by file owner. A file can specifically set "Make Private" to be private for all.
Privately Shared	File has been shared with specific people, groups, or via link, can find and view this file. File is privately shared when people other than you but not all can find and view this file.
Your Company	All users can find and view this file. File is shared to Chatter feed, user profile, object record, public group and etc.

• File Permissions

Action	File Owner	File Collaborator	File Viewer
View/Preview	✅	✅	✅
Download	✅	✅	✅
Share	✅	✅	✅
Attach a File to Post	✅	✅	✅
Upload New Version	✅	✅	❌
Edit Details	✅	✅	❌
Change Permission	✅	✅	❌
Make File Private	✅	❌	❌
Restrict Access	✅	❌	❌
Delete	✅	❌	❌

• File Uploads
  • Upload files to library in Files home
    • files can be uploaded to a particular library
    • the uploaded files inherit the sharing settings of the library
    • you can add Users or Public Groups with access of Viewer, Author or Library Administrator
      
    • you can also manually add access permission (Viewer only) directly on the file in the library
      
    • NOTE: if the file is added in the library, public link cannot be created (might be a bug though, upload via Upload Files button can have public link but not adding in library)
    • NOTE: also, the access permission is Viewer only, Collaborator is not displayed
  • Upload files in Files home
    • files can be shared with Users or Public Groups with access of Viewer or Collaborator
      
  • Upload files in Chatter Feeds
    • files can be shared by attaching it to a Chatter post or comment
    • files can be attached in Chatter Feed, Groups, User profiles, and records
    • a maximum of 10 files can be upload at once
      
    • files are uploaded to the Chatter post
      
    • files that is attached to a post in the Chatter Feed is automatically shared with all users of the company
  • Upload files on records
    • add files
    • upload files by clicking the button or drop the file onto the button area
      
• Public Link Sharing
  • you can make the file accessible by internal or external users by creating public link
    
  • after link is created, you can copy the link and share with others
    
• File Upload and Download Security
  • you can set the file upload and download behavior
  • navigate to Setup > File Upload and Download Security
  • Download behavior: Download, Execute in Browser, Hybrid
    • Download - recommended, file is always downloaded
    • Execute in Browser - file is displayed and executed automatically when accessed in a browser or through an HTTP request. Due to security risks, some files aren't available to execute in the browser.
    • Hybrid - attachment and document records are execute in the browser, Salesforce Files are downloaded.
  • Don't allow HTML uploads as attachments or document records - prevent users from uploading files as attachments to records or as document records when the file types pose a security risk. Salesforce Files are not affected by this setting, even if their file type may pose a security risk.
    
• Miscellaneous
  • A private file is not shared with anyone besides the owner. Only the file owner and users with Modify All Data permission can find and view the file. If no one other than the owner can access the file, the file should be uploaded to a private library.
  • Prevent others from sharing and unsharing can be set on the ContentVersion page layout:
    
    • Freeze Sharing Off
    • Freeze Sharing On
  • Prevent others from sharing and unsharing can also be set on file sharing layout:
    
  • File Privacy on Records can be set to make sure users other than the file owner cannot share or unshare the file
    
    • Visible to Anyone with Record Access
    • Private on Records
  • Unselect Select Files from Salesforce from Profile to prevent users from attaching Salesforce Files to post, records and objects
  • Set file access to Set by Record for files attached to records can be set in Setup > Salesforce Files > General Settings so that the files that are attached to records can inherit the sharing settings of the record
    • users with Read/Write access to a record will get Collaborator access to files attached to the record
    • users with Read Only access will get Viewer access to the files
    • if the checkbox is not set, all files attached to records are default to Viewer access
      
  • Asset Files
    • Asset Files are packageable versions of Salesforce files that are used for branding and design purposes in your org or communities
    • Asset files can be used for headers and logo images
    • You don’t need to create asset files for regular, collaborative use of Salesforce Files
  • Regenerate Previews
    • if content or a file doesn’t have a preview or the preview quality is poor, try to regenerate the preview
      

---

Well, that's all about it! See you in next post!

Post was published on 12 Apr 2020, last updated on 20 May 2020.

Like the content? Support the author by paypal.me!