Security Flashcards
What are the 3 levels of security controlling the Org Access?
- Restrict the login IP ranges in the Enhanced Profile User
- Set Trusted IP Ranges for your Organization
- Restrict Access by Time
Trusted IP Ranges vs
Login IP ranges
-
Trusted IP Range Is set at the Company level
- Users outside the range are sent a verification code
- Login IP ranges are restricted at the Profile level
- Users outside this range are denied access
What is Salesforce Identity?
It provides the capability to login to different app by using one single access.
Log into SF -→ SF Identity -→Gmail, DocuSign, Confluence…
Salesforce Identity
3 Protocols
- SAML Protocol: Used when user wats to navigate to multiple applications, but does not need to navigate to their URL. (Ex. Access “Adobe Sign” from the Salesforce App Launcher)
- Oauth 2.0 Protocol: Used when data needs to be shared between 2 applications
- OpenID Protocol: Used when an Identity is confirmed by another provider. Ex: Access Salesforce trailblazer using google account sign in
3 Salesforce secure User Authentication
- Multi-Factor Authentication (MFA) for users
- My Domain to customize the login Page
- Single Sign-on (SSO) - Allow the user to login to different apps with the same credentials
Where do you set the MFA for users?
- On the user’s profile
- By creating and assigning a permission set to specific users
Setup/Permission Sets/ click System Permissions / Select Multi-Factor Authentication for User Interface Logins
Manager Groups
Admin can enable Manager Groups to allow users to manually share records with their direct or indirect Managers or their direct/indirect subordinates. These Groups can also be used while configuring sharing rules
Is the “Grant Access using Hierarchy” option enabled on all objects?
- The “Grant Access using Hierarchy” option is enabled on all objects by default
- This option can only be disabled for custom objects
- This option is available in Orga-wide Default related list
- When disabled only the owner and user granted access receive access to the object’s record.
Role Hierarchies
- Gives access to users higher in the hierarchy
- Users have view, edit, and report access to data owned by users below them
- Users on the same role do not have view access to records owned by each other
- An account owner can be limited by his role to view, edit to the accounts’ related: Contacts, Opportunity and/or Cases
What are the 3 types of sharing rules?
- Owner-based: Opens up access to records owned by specific users
- Criteria-based: Opens up access to records on specific values on the record
- Guest user: this Criteria-based sharing rule provides record access to guest or unauthenticated users based on field values
Sharing rules considerations
- Org-wide default must be public read or Private to create Sharing rules
- Users in the upward hierarchy get the same access as their subordinates
- User licenses that do not support roles cannot be included in sharing rules
- Encrypted fields cannot be used in criteria-based sharing rules
What type of users can share a record manually?
- The record owner
- A user above the record owner in the hierarcy
- A user with full access on a record
- An Admin
Which records ‘ objects can be shared manually in SF Lightning?
- Account
- Opportunities
- Case
- Contacts
- Leads
- Custom object
Field-level security
Manages access of fields on:
- Page layouts,
- Reports,
- List views,
- Related list,
- API and
- Search Results
Field-level security
Considerations
- Settings available on Professional, enterprise, performance, unlimited, and developer edition
- Can be set for Multiple profiles from the field Accessibility in setup for each object
- It overrides the “Modify All Data” and “View All Data” Profile permission
- It overrides the page layout. (ex a required filed in Page layout, will be read-only if the field-level Security is set this way)
The different Factors that determine the filed access to a user
- Page Layouts: Make a field visible, required Editable, or read-only for specific record types and profiles
- Field-Level Security
- Permissions: Ex’ “Edit Read-only fields” overrides a “Read-only” set up in a page layout and field-level security
- Universally Required fields: will override a “Read-only” set up in a page layout and field-level security. Ex.: Account name is a universally required field.
- Lookup and system fields: Users must have Read access to these records or the “View all Lookup Record Name” permission to view this data
What type of user can be added to a group?
- Users in a particular role/territory or other groups
- Users below that specific role/territory can also be added to a group
Public Groups features
- Can be created by admin and delegated admin
- Used to set up sharing rules
- Manually share records with other users
- Share a CRM content library with a group of uses
- Assign action to a group in SF knowledge
- Synchronize contacts
Queues
- Used to prioritize, distribute and assign records to a group of users who share the same workloads
- Queues are available for leads, orders, contact requests, cases, knowledge article versions, service contracts, and custom objects
- Individual users, roles and roles subordinates, and Public Groups can be added to a queue
How can records be assigned to queues?
- Assignment Rules: Assign records automatically based on specific criteria
- Manually: Manually update the ownership of a record to a queue.
