Salesforce Sharing and Security

 Profiles 

-Object and field security

-Org permissions

-One per user

Permission Set :

Permission sets has offered the ability to grant nearly all the same permissions as the profile, 

but usually are limited to one or two specific use cases, or one or two specific permissions per permission set.

-> Good for one off permissions

-> Multiple Per user

why Still Use Profiles?

1.Default record types are always assigned at the profile level.

2.Page layout assignments are also assigned at the profile level.

Permission set groups :

-> can contain multiple permission sets

-> Based on job function

-> Can included muted permissions

Record Access :

1.Organization-wide defaults (OWD)

Different access levels 

-> Controlled by Parent

-> Private

-> Public Read Only

-> Public Read/Write

External Sharing Model

-> Similar to internal sharing model

-> Access must be more restrictive or equal

2.Roles and role hierarchy

-> Vertical sharing

-> Vertical sharing with users above in hierarchy.

3.Sharing rules

-> Horizontal sharing with users (Bulk)

-> Based on ownership or criteria

-> Can share with role, role and subordinates,or group.

4.Manual Sharing 

-> Horizontal sharing (Single record)

-> Flexible sharing (Single Record) : Share records you own with specific users.

-> Sharing button on records : Unavailable if OWD are Public Read/Write.

Public Groups and Queues :

Public Groups :

Can segment group of users that need the same access;Can specify Grant Access using Hierarchies to share with hierarchy of group users.

Queues :

Can assign records to teams that share a workload:any queue member can take ownership of record owned by the queue.

Restriction rules:

Restriction rules function as the opposite of sharing rules, and it will remove access to records, but they will be applied after all other sharing has taken place.

5.Team sharing

People have consistent teams they work on records with 

-> Account

-> Opportunity

-> Case

-> Enabled by admin with roles added.

-> Team members specified by users.

-> Account,Opportunity and Case teams.

Account Team :

Salesforce Admin can enable Account Teams and create roles.

Users can specify their own account teams that they want to work with and assign roles.

Users can automatically add team to new accounts.

Team members get access to account.

-> Read

-> Read/Write

Team members can inherit access to child contacts and opportunities.

Opportunity Team :

Works similar to Account Teams.

Admin will enable for org and create roles.

Users can specify their own Opportunity teams.

Users will ger Read or Read/Write access to opportunities.

Team members are granted Read access to parent account.

Case Teams:

Case teams work similar to account and opportunity teams with some slight tweaks.

Admin will enable for org and create roles that determine access.

Note : But in the case of case teams, it's the roles that will actually determine what access a user will get. 

Team members can get Read or Read/Write access to case or be added as private members with no access.

Predefined Case Teams:

Admins can predefine case teams so that you can quickly add people who you frequently work with.

Predefined case teams are going to work similar to the account and opportunity teams except they have to be configured by the Salesforce administrator.

6.Enterprise Territory management

-> Specific use cases

-> Additional layer of security and sharing.

-> Configure Users 

Assign users to one or more territories.

-> Configure Accounts 

Assign account records to one or more territories.

-> Ahow it works 

Access determined by territories.

-> Additional Objects 

Configure opportunity,case and Contact access.

-> Define access 

Configure default access and territory specific access.

Enterprise Territory Management Access 

-> Available default access levels dependent on OWD.

-> Accounts (View,View/Edit,View/Edit/Transfer/Delete)

->Opportunities (No access,View,View/Edit)

->Contacts and Cases (No access,View,View/Edit)

-> Can set territory specific access when creating new territories.

Territory Hierarchy :

can create territory hierarchies by setting territories as parents to other territories.

Access Inheritance :

Child territory's access level is inherited by parent territories above it.

Note :

->Assign access based on territory

->Can create territory hierarchy

->Child territory's access is inherited by parent.

Salesforce Org Security Features :

1.Multi-factor Authentication(MFA)

Enforce security when logging in with MFA.

-> Profile level

Configure each profile's Session Security Level Required at Login to High Assurance.

-> Org level

In Setup, configure Session Security Levels in Session Settings to add Multi-factor Authentication to the High Assurance Column.

2.Trusted IP Ranges 

Defined at the org level : user will need to provide a security code received via email or text if outside the range.

-> Trusted Ips at org level.

3.Login IP Ranges

Defined at the profile level:user will be denied access if outside the range.

-> Login Ips at profile level.

4.Login Hours 

Defined at the profile level:user will be denied access if outside the range.

-> Login hours at Profile level.

Delegated Administration :

-> Assign limited adim permissions to users who aren't admins.

-> Create and edit users in roles and subordinate roles.

-> Add and remove profiles and permission sets.

-> Login as Users

-> Manage custom objects

Note : Grant admin permissions to non-admins