Security and Access is a very crucial part in Salesforce. We probably want to control which user can see what or which user role can view or modify the subordinates' records and so on. Fortunately, Salesforce has already provided us all the necessary tools to ensure data security always comes in the first place. Security and Access section takes the largest portion (20%) in Salesforce Advanced Administrator exam, so it would be wise to put more effort in this topic! Without further ado, let's get into it!

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

Record Access

control-access-sharing

  • Record access is based on concept of opening up record access from more restrictive to less restrictive.

  • Organization-wide default (OWD) opens up to access to records that user does not own.

  • Increase OWD default access takes effect immediately (ex: Public Read Only -> Public Read/Write).

  • Decrease default access takes some time to recalculate user access.

  • Sharing rules are used to expand record access for groups or users, not restricting access.

  • Individual records can be shared manually by using Sharing button (Classic only).

  • Some OWD sharing selection:

OWD Sharing Defaults Description
Public Read/Write/Transfer View, edit, and change ownership (Lead and Case only).
Public Read/Write View and edit other users' records.
Public Read Only View other users' records (not edit).
Private Records not shared with anyone except through hierarchy (if granted).
Controlled by Parent View and edit child records if granted access to parent record.
Price Book: Use All users can view price books, add price book and products to opportunities.
Price Book: View Only All users can view price books only (except manually granted access).
Price Book: No Access No visibility to price books and cannot add them to opportunities (except manual granted access).
Activity: Private View, edit and delete Activity (read access if granted access to parent record).
Activity: Controlled by Parent Determined by the access the user has on the record related to the Activity.
Public Full Access (Campaign) View, edit, transfer, delete and report on all Campaign records.
Controlled by Campaign (Campaign Member) View and edit Campaign Member records if granted Campaign access.
Controlled by Lead or Contact (Campaign Member) View and edit Campaign Member records if granted Lead or Contact access.
Private (User) View their own user record and those below them in role hierarchy.
Public Read Only (User) All users can see other users' detail pages, find users in lookups, list views, ownership changes, and search.

Object Access

  • Object permission (CRUD) controls what users can do with records they own.
  • Profile determines which objects a user can access and what actions they can take on those objects.
    object-permission
  • Profile also determines access to tabs and apps.
  • Different tab settings for objects:
    • 'Default On' - the tab for the object will be in the navigation bar if it is also included in the 'App'
    • 'Default Off' - it is available to add on the navigation bar by customizing tabs.
    • 'Tab Hidden' - the tab will neither be visible for the object nor in the App Launcher.

Field Access

  • Field-level security controls the visibility and editability of a field.
  • NOTE: Read-Only field-level security overrides the 'Edit' permission on object.
  • NOTE: field-level security overrides 'Modify All Data' and 'View All Data' permissions.

Miscellaneous

  • A contact record without account is called 'Private Contact'. It is visible to system admin and the owner only regardless of the company's sharing model.
  • 'Manual User Record Sharing' on Sharing Settings page can be used to enable or prevent users from sharing their own user records with others. (Classic only)
  • 'Standard Report Visibility' on Sharing Settings page allows users to view reports based on standard report types that can expose data of users to whom they don't have access to.
  • If the record access is Controlled by Parent, the user will be able to perform action on the child record if they have the access on the parent record.

Role Hierarchy Access

  • Role hierarchy grants access to records to users that have a role above the record owner.
  • Role hierarchy is not necessarily an organization hierarchy, but you can think of it as data access hierarchy.
  • NOTE: role hierarchy does not override object access. For example, if the user doesn't have 'Edit' in object, the user will still not able to edit the object.
  • Custom object can have role hierarchy based access disabled by unchecking 'Grant Access Using Hierarchies'.
  • By default, the Grant Access Using Hierarchies is checked when creating new custom objects. Also, you cannot uncheck the Grant Access Using Hierarchies on the standard objects.
  • Exact access to contact, opportunity and case records can be specified in Role Edit.
    role-edit

Manager Group Access

  • Manager groups can be enabled in Sharing Settings to share records up or down the management chain.
    sharing-settings-other-settings
  • Once enabled, users can share records with their managers or manager subordinate groups.
    sharing-settings-managers-subordinates-group

Sharing Rules

  • Sharing Rules allow record access to be granted to other users in the following:
    sharing-settings-share-with-groups-and-roles
    • Manager Subordinates Groups - include user and user's subordinates in hierarchy
    • Managers Groups - include user's direct manager in hierarchy (exclude user)
    • Public Groups
    • Roles
    • Roles and Internal Subordinates
    • Roles, Internal and Portal Subordinates
  • Records can shared based on record owner (including Queue) or criteria as well.
    sharing-settings-rule-type
  • Record access can be either Read Only or Read/Write.
  • NOTE: Profile or Permission Sets determines the base level access of object, while Sharing rules open up access to the records of the object.
  • Whenever a change is made on sharing rules, recalculation will take place. A recalculation will also occur when new user added or removed from a group, a territory changes, or user's role is changed.
  • Manual recalculation can be done by clicking Recalculate on Sharing Rules section in Sharing Settings page. (used when sharing rules are failed to work as expected)
  • Recalculation also causes Apex sharing and sharing rules associated with any related objects to be recalculated. Need more revision on this.

Manual Sharing (Classic Only)

  • Manually sharing records with other users by clicking 'Sharing' button on the object.
  • NOTE: 'Sharing' button will only appear if OWD setting for that object is Private or Public Read Only.
  • Records can be shared with the following:
    • Users
    • Roles
    • Roles and Subordinates
    • Public Groups
    • Manager Groups
    • Manager Subordinate Groups
  • To manually share a record, the user must be the owner of the record, above the owner in the role hierarchy, a user with 'full' access, or an administrator.
  • Manual sharing access levels can be set to Read/Write or Read Only.
  • If set to Read Only, the user cannot add associated records nor edit or add attachments or notes.
  • 'Manual User Record Sharing' in Sharing Settings page can be unchecked to disable manual sharing.

Enterprise Territory Management

  • Enterprise Territory Management (ETM) is a declarative capability that defines sales or service territories, and assign the sales and service reps to the territories allocated to them.

  • Multiple territory structures can be created and previewed before activating one.

  • ETM on high level:

    1. Enable Enterprise Territory Management in Setup.
    2. Set up Territory Types (grouping and prioritizing purposes).
    3. Create a Territory Model.
    4. Build the Territory Hierarchy.
    5. Define Territory Assignment Rules.
    6. After previewing the model, run rules and activate territory.
    7. (Optional) Assign users to territories or permission to users.

  • Territory management is not restricted to geographical territory definitions only, it can be defined on any parameters.

  • Enterprise Territory Management 2.0 is an improved version of earlier Original Territory Management (retiring Summer 20') feature in Salesforce.

  • Nterprise Territory Management can be disabled by navigating to Setup > Territory Settings:
    territory-settings-disable-etm

  • Territory management is not available in Salesforce Group and Professional editions (available in both Classic and Lightning)

  • Something about ETM:

    • Accounts are organized into territories.
    • Users are granted access to the accounts and related records in the territories they are assigned to.
    • Users can be assigned to multiple territories.
    • Accounts can be automatically assigned to a territory using assignment rules based on zip code, state, industry code and etc.
    • Accounts can also be added to territories manually.
    • Territory access levels allow greater access to accounts such as 'View and Edit'.
    • Opportunities can be assigned to territories to share them with users assigned to territories.
    • My territories' opportunities can be selected to view the all the opportunities assigned to the users' territories in report.

Territories

  • Territories allow the organization of Salesforce accounts and users who work on those accounts.
  • Create Territory requires Territory Types.
  • Territory can be created in Territory Hierarchy or inside Territory (create child territory).
  • A Territory record shows assigned users (manage users), manually assigned accounts (add accounts), inherited assignment rules, assignment rules assigned to this territory and child territories.
    territory-page
  • It is possible to assign an account to more than one territory.
  • Users in a territory have at least 'View' access to accounts, permission such as 'View and Edit' or 'View, Edit, Transfer and Delete' can be assigned to users as well.
    territories-access-level

Territory Types

territory-types-create

  • Territory Types are created to organize territories by key characteristics, and each territory has a territory type.
  • NOTE: Territory type has no impact on record visibility or assignments at all, it is just merely to aid the administration and organization of territories.
  • Territory Type Priority is used to indicate the order of priority (no effect to overall access priority).

Territory Model

territory-model

  • Territory model represents a complete territory management system for a company.
  • Territory model contains territory hierarchy which contains one or multiple territories and each territory can assign users, accounts, and assignment rules.
  • Territory model can be in Cloning, Planning, Active, or Archieved state.
  • Up to 4 territory models can be created per org, but only 1 can be active model.
  • The territory model needs to be Activated to finalize its user and account assignments.
  • The Archived state of territory model does not provide account access to users, but it lets an administrator view hierarchy and rule assignment.
  • Only an Active model can be Archieved and archived models cannot be reactivated.
  • Cloning a territory model copies territories, assignment rules, assigned users, and manually assigned accounts from original model.
    territory-model-cloning
  • When cloning, the state will be Cloning and the Clone Source will be checked.
  • Assignment rules can be run on a territory model that is in Planning state to preview and assess the effect of the model (not effect on actual record access).

Territory Hierarchy

territory-hierarchy

  • Territory Hierarchy is a graphical representation of the entire territory structure within a Territory Model.
  • Territory Hierarchy is built on a parent-child relationship between territories.
  • Assignment rules can be specifically run at each child territory level to enforce any changes that occurred to users / accounts in the region.
  • Territory assignment rules can be run at Territory Model level by clicking 'Run Assignment Rules'.
  • Territory hierarchy can be viewed in a tree view or sorted list view.

Assignment Rules

  • Assignment Rules are used to assign accounts to territories. You can check Applies the rule to xxx territory and its descendants to apply the assignment rule to child territories as well.
    territory-assignment-rules-create

  • User can manually assign accounts to territory.
    territory-assignment-rules-manually-create
    territory-assignment-rules-manually-assign

  • One account can be assigned to multiple territories. You can view 'Assigned Territories' related list on the Account page.
    account-related-list-assigned-territories

  • You can also manually add multiple Territories from the 'Assigned Territories' related list:
    account-related-list-assign-multiple-territories

  • Users that are added manually to the Territory can be viewed on Account related list 'Users in Assigned Territories':
    account-related-list-user-assigned-territories-1

  • Child territories can optionally inherit assignment rules from parent territory.
    territory-assignment-rules-apply-to-child-territories

  • User will need both 'Manage Territories' permission and 'View All' access permission to accounts to use assignment rules.

  • Users would only be able to define assignment rules based on account fields that they have access to via Field-Level Security settings.

  • Account page layout properties allows exposing 'Evaluate this account against territory rules on save' checkbox field on Account Edit Layout. 'Default' checkbox field can be made visible and selected by default from 'Layout Properties'.
    account-page-layout-evaluate-against-territory-rules-on-save

  • A checkbox is displayed on the footer before save.
    evaluate-this-account-against-territory-rules-on-save

  • Account can be checked 'Exclude from territory assignment rules' to exclude from territory assignment rules.
    territory-account-exclude

Opportunities & Territory Management

  • An opportunity territory can be set manually or through assignment rules or Apex class.

  • A user with full access to the opportunity's account record can assign the opportunity to any territory from the active model.

  • A user without full access to the opportunity's account can assign a territory that is also assigned to the opportunity's account.

  • Opportunities can be assigned automatically by enabling "Enable Filter-based Opportunity Territory Assignment" in Territory Settings.

  • Once you have done that, you will see a button 'Run Opportunity Filter' on the Territory Models page and you can run the filters from there. (will not apply to existing Territory Model)
    territory-opportunity-territory-filter-run

  • You can also specify Apex class to run a job when opportunities are created, assigning them to the appropriate territory based on the code logic.
    territory-assignment-rules-opportunity

  • Your Apex class must implement TerritoryMgmt.OpportunityTerritory2AssignmentFilter interface and have a parameterless constructor.
    territory-opportunity-territory-filter-apex-class

  • NOTE: an opportunity object has field labeled 'Exclude from the territory assignment filter logic' which is used to explicitly exclude an opportunity from filter-based territory assignment job.

  • Territory object can be added through lookup in Opportunity too (only one territory per opportunity).
    territory-opportunity

Forecasting with Territory

  • Collaborative forecasting can forecast opportunity revenue by territory.

  • Territory forecasts can be used by sales rep to see an opportuntiy revenue forecast rollup based on the territories assigned to each opportunity.

  • Opportunity revenue forecasts can be viewed for the territories that users are assigned to.

  • The opportunities that are included in territory forecasts can be viewed regardless of whether the opportunity owner is assigned to the territory.

  • It is possible to drill down to child territories' forecasts and also to an individual rep's forecasts for a territory if the territory doesn't have a forecast manager.

  • Territory forecasts are based on the territory hierarchy not user role hierarchy.

  • Territory forecasts can be added by selecting 'Opportunity Revenue by Territory' forecast type in Forecast Settings.

  • NOTE: a Forecast Manager in territory must also be an assigned user in the territory.

  • If a Forecast Manager is not assigned to a territory, the territory forecast will be based on the individual users assigned to the territory.

Original Territory Management

  • Similar to ETM, it is an account sharing system that grants access to accounts based on criteria such as postal code, industry, revenue and etc.
  • A user can be assigned to multiple territories in the territory hierarchy.
  • Forecast is only available with Customizable Forecasts.
  • Access to opportunities and cases with the accounts in territory can be controlled regardless of who owns the records.
  • Territory hierarchy becomes forecast hierarchy when the original territory management is enabled.
  • Users can have a different forecast for each territory to which they are assigned.

Permission Sets

  • Permission sets grant specific access and permissions in user profile beyond Profile settings.
  • Adding additional permissions such as object access, field access, tabs, apps and etc.

Custom Profiles

  • Custom profiles can be created by cloning an existing profile such as standard profile.
  • NOTE: there are some restrictions on what can be changed on standard profile, hence we might need to create custom profile to fully customize it.

Delegated Administration

  • Delegated Adminstration allows group of users to act as 'Delegated Adminstrators'.
    delegated-administration-create

  • Delegated administrators can do the following:

    • Enable Group for Login Access - Login as user
    • User Administration - Create and edit users, reset passwords, unlock users
    • Assign Profiles - Assign users to certain profiles
    • Assign Permission Sets - Assign permission sets to users
    • Assign Public Groups - assign users to public groups
    • Custom Object Administration - manage custom objects (see restrictions below)
    • Miscellaneous - Create default Opportunity teams, set Quotas and etc.
      delegated-administration-functions

  • NOTE: while a delegated adminstrator can customize nearly every aspect of a custom object such as creating tabs, modifying page layouts, adding picklist value to a field and so on, however, it cannot create or modify relationships on the object, change OWD sharing setting for the object.

Post was published on , last updated on .

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