User Authentification

Secure Your Users' Identity

• A user is anyone who logs in to Salesforce.
• Each user has a user account. The user account settings determine the features and records the user can access, including, at least, the following:
  • Username
  • Email Address
  • User’s First and Last Name
  • License
  • Profile
  • Role (optional)
• View and manage users via: Setup » Quick Find » “Users” » Users
  • From there, admins can log in as any user if that system permission is enabled or if the user has granted the admin login access.
• User key terms:
  • Username: must be formatted like an email address but can be different from the user’s email address.
    • Usernames must be unique across all Salesforce orgs.
    • Emails do not have to be unique across all Salesforce orgs.
  • User Licenses: allow users to be assigned varying levels of feature access. For example, if you want to grant a user access to Chatter without allowing them to see Salesforce data, use the Chatter Free license.
  • Profiles: determine what users can do in Salesforce. Come with a set of permissions granting access to particular objects, fields, tabs, and records. Each user can only have one profile. Standard User is best for most users, but users shouldn’t have a profile with more access than they need to do their job.
  • Roles: determine what users can see in Salesforce based on the role hierarchy. Users at the top of the hierarchy can see all the data owned by users below them. Optional, but each user can have only one. Available in Professional, Enterprise, Unlimited, Performance, and Developer editions of Salesforce.
  • Alias: short name to identify the user on list pages, reports, etc. By default, it is the first letter of the user’s first name, first four letters of their last name.
• SalesforceA is a mobile app that lets admins perform essential admin tasks like resetting passwords, freezing users, and viewing current system status.
  • To log in, need the Username, Password, and Correct Instance. The instance can vary from production, sandbox, or custom domain. The instance is set up by the environment, which can be changed by tapping the cog on iOS.
  • User accounts can be frozen from the mobile app.

Control What Your Users Can Access

• Salesforce provides a flexible, layered data security model that makes it easy to assign different data sets to different sets of users.
  • Permissions include whether users can view, create, edit, or delete any record or field in the app.
  • This access can be configured at the level of the organization, object, field, or individual record.

Levels of Access Overview

• Organization: limit who is a user.
• Object: simplest way to control which users have access to which data.
• Fields: field-level security is used to restrict access to certain fields, even on objects the user has access to. As an example, salary could be invisible on a position object to interviewers but visible to hiring managers and recruiters.
• Records: restrict the individual object records users can see, even if the user has access to the base object. As an example, users on a hiring committee might be able to see and edit their own reviews, without exposing the reviews of other interviewers.
  There are several ways to control record-level access:
  • Organization-wide defaults: specify the default level of access users have to each others' records. This should be the most restrictive level; the other tools can open up access.
  • Role hierarchies: open up access to those higher in the hierarchy so they inherit access to all records owned by users below them.
  • Sharing rules: make automatic exceptions to organization-wide defaults for particular groups of users. This is used to open up access, not restrict it.
  • Manual sharing: allows owners of particular records to share them with other users. This isn’t automated like the other methods above, but is useful in some situations, such as when a user is going on vacation and needs to give someone else access to their records for coverage.

Overview of Record-Level Security

• Following questions are useful to answer before configuring record access:
  • Should your users have open access to every record, or just a subset?
  • If its a subset, what rules should determine whether the user can access them?
• Two key concepts on the platform:
  • Permissions on a record are always evaluated based on a combination of object-, field-, and record-level permissions.
  • When object- and record-level permissions conflict, the most restrictive settings win.

Organization-Wide Sharing Defaults

• Arrive at the appropriate organization-wide defaults by answering the following. Note that a fourth level of access is also available: Controlled by Parent, whereby a user can perform an action (view, edit, delete) on a contact based on whether they can perform the same action on the record associated with it.
  1. Who is the most restricted user of this object?
  2. Is there ever going to be an instance of this object that this user shouldn’t be allowed to see?
     • If Yes, sharing model = Private - only record owner and those above them in the hierarchy can view, edit, and report on those records.
  3. Is there ever going to be an instance of this object that this user shouldn’t be allowed to edit?
     • If Yes, sharing model = Public Read-Only - all users can view and report but not edit. Only record owners and those above them in the hierarchy can edit those records.
     • If No, sharing model = Public Read/Write - all users can view, edit, and report on all records.
• Note that objects that are on the detail side of a master-detail relationships automatically inherit the sharing setting of its parent and cannot have organization-wide defaults set.

Set Organization-Wide Sharing Defaults

• Set up org-wide sharing defaults via: Setup » Quick Find » “Sharing Settings” » Sharing Settings. Click Edit in the org-wide defaults area.
  • Recall the questions outlined above to determine the right level of default access.
  • To allow employees at higher levels in the role hierarchy to access records automatically, select Grant Access Using Hierarchies.
    • If this is deselected, you restrict record access to only the record owner and users granted access by org-wide defaults. Some users can still access records they don’t own by default, such as:
      • users with the “View All” and “Modify All” object permissions and
      • users with the “View All Data” and “Modify All Data” system permissions.
• When updating the org-wide defaults, a sharing recalculation is run automatically that applies access changes to the records.