User Setup and Login
User Setup
- User’s must be associated with a license and profile
- License => What security a user can be granted
- Profile => What the user can do with the records they have access to
- It is optional to assign a Role
- Role => What records the user can see
-
Assigning Licenses, Profiles and Roles to a User
- Usernames must be unique across ALL orgs (every company out there that uses SF)
- Records can be assigned to active users or queues only
- Localization Settings
- Locale
- Affects dates, times, numbers, names & addresses
- Language (See Organization Setup)
- Time Zone
- Impacts references to time in date/time fields and on the calendar
- Currency
- If multi-currency org, the user can select their currency and SF will convert currency.
- Chatter Profile
- The user’s “About” profile is searchable by other users
- This is accessed by clicking on your name and selecting “My Profile”
- Locale
My Domain
- My Domain is a way to customize the URL for your instance of Salesforce
- Instead of seeing the salesforce subdomain at the start of the URL (the “na35” in “https://na35.salesforce.com…”) you’ll see the My Domain name
- https://catsgalore.my.salesforce.com…
- (The domain changes from “salesforce.com” to “my.salesforce.com”)
- When My Domain is setup you have some control over how the login page looks
- You can add your own custom logo
- This is the little picture above the login area
- Image limitations .jpg, .png, .gif file up to 100kb and 250px wide by 125px tall
- You can change the background color of the login page
- You can change the content that is shown to the right of the login area
- You can add your own custom logo
- My Domain is different from the Force.com domain that is setup for Communities and the Force.com domain that is setup for Sites
- My Domain is for your instance of Salesforce
- There are two Force.com domains
- One for Communities
- One for Sites
- In order for Live Agent Chat to be enabled you must register a Force.com Sites domain
- Instead of seeing the salesforce subdomain at the start of the URL (the “na35” in “https://na35.salesforce.com…”) you’ll see the My Domain name
User Login & Login Security
- Each login is called a “Session”
- Logging in from different locations (eg home and work) means that web access is originating from different IP addresses. Salesforce can be setup to “trust” known IP addresses. If the IP address of the login is not in a trusted IP range, then additional security measures are used to make sure it’s okay to log in.
- 4 Login (Authentication) Methods
- Web Browser
- This is the method for users logging in from their computers (the user interface or UI)
- Web browser login does not require a security token
- (Note: Data Loader login will require a combined password + security token unless a checkbox is clicked to tell it the security token is not required)
- Web browser login may require computer activation which entails placing a cookie in the browser so Salesforce recognizes the computer
- This will happen if the user is logging in from an IP range that they have not used before and there is not a cookie in their browser
- Customer and Partner Portals do not require computer activation
- Two-Factor Authentication can be enabled
- This means that each time a user logs in they will need to use an authenticator app on their mobile device to verify their session
- What happens is when the user logs in, the authenticator app will prompt them to verify the session
- Verification can be either entering a code that the authenticator app provides into the login page, or simply clicking an “Approve” button on the mobile device
- API (eg. Data Loader)
- Does not require computer activation
- May require security token (when logging in outside of a trusted IP range)
- Single Sign On (SSO)
- This is a login to the company network which then grants access to all the company resources available to the user with no additional login
- “Social Sign-On” is an example of this where a user can access Salesforce after they have signed in through a third-party authentication provider such as LinkedIn or Facebook
- My Domain must be enabled before you can use the following:
- SSO
- Two-factor authentication
- Lightning components
- OAuth
- Allows external applications to ask the user for permission to access Salesforce data (eg. Chatter Desktop)
- Web Browser
- Login URLs
- Production – default: login.salesforce.com
- Production – with My Domain enabled: my.salesforce.com
- Sandbox – login.salesforce.com
- Login Hours
- Login Hours restrict login to specified hours
- Login hours are applied to a Profile (EE, UE, DE) so all the users assigned to that profile will have restricted login hours
- Login hours cannot be opened up with a permission set
- One way to use login hours is to prevent login during maintenance times
- Users who are logged in when their Login Hours end can continue to view their current page, but cannot take any further action
- Login IP Ranges
- An IP address identifies the host or network and physical location where the web access is originating
- By default users can login from any IP address
- Login IP Ranges restrict login to specific IP addresses
- Applies to a Profile (EE, UE, DE) so all the users assigned to that profile will have restricted login IP ranges
- Login IP range restrictions cannot be lifted with a permission set
- Trusted IP Ranges
- Trusted IP Ranges remove login restrictions from specified IP addresses so computer activation and security tokens are NOT required
- This applies org-wide but login IP range restrictions placed on the Profile level will override this setting and restrict the users of that profile to the specified IP ranges
- Computer Activation (Identity Confirmation)
- Computer activation is required when the identity of the login request cannot be confirmed
The user has not logged in from the IP range before(Spring ’16 – if a user logs in from an unrecognized device they will be prompted to verify the session, even if they have previously logged in from the same IP address)- The user does not have a cookie in their browser
- To identify the login is valid a 5-digit security code is sent to the user
- There are two methods that are used for sending the security code
- An Email is sent with the security code
- An SMS (Simple Message Service) text is sent with the security code
- If the user has a mobile number listed on their Profile SMS will be the default method (set at the org-wide Security Control > Session Settings level which can only be disabled by SF)
- The Sys Admin can re-enables email identify confirmation with an “Allow email-based identity confirmation” Permission Set
- If the user does not have a mobile number on file they will be prompted at login to provide one, or to check a box that they do not have one
- What happens if a phone is lost or inaccessible and a user needs a security code?
- There are three things that the Sys Admin can do to enable the user to quickly get their security code via email
- Add the IP address to the trusted IP range list
- Remove their mobile number from their Profile
- Assign the “Allow email-based identity confirmation” permission via a Permission Set
- What if you’re a solo admin and you need a security code?
- You must log a case with SF to have your mobile number removed from your Profile
- To avoid this scenario, assign the “Allow email-based identity confirmation” Permission Set
- With a successful login a cookie is placed in the browser and the IP address is recorded in that user’s IP address list. These notations will tell SF on subsequent logins that the computer is activated
- Activations can be viewed from Setup > Security Controls > Activations
- There are three things that the Sys Admin can do to enable the user to quickly get their security code via email
- Computer activation is required when the identity of the login request cannot be confirmed
- Security Token
- A security token is a 24-character alpha-numeric string that must be appended to the end of a password in certain circumstances in order for the login to authenticate
- Security tokens are required for login via API, unless the login is from a trusted network
- The security token changes when the password changes
- The user can also request a new security token at any time
- (In Classic View: My Settings > Reset My Security Token)
- Login Attempt Limit
- You can adjust the number of times a user can attempt to login before they are locked out for a period of time
- These two events count toward the login attempt limit:
- Each time a user is prompted to confirm their identity (eg, when a user clicks “Email me a verification code”)
- Each time the user incorrectly adds the security token or time-based token to their password to long via the API
- Two-Factor Authentication
- When a user logs in, Salesforce looks at the device to see if it is a known device, and if it’s not recognized, will require additional verification before granting the user access
- There are 4 ways Salesforce will verify the session (in this order)
- 1. Via push notification to the Salesforce Authenticator mobile app connected to the user’s account
• The user taps an “Approve” button on the app to verify the session (new feature Spring ’16) - 2. Via a Time-Based One-Time Password (code) that is generated by a mobile authenticator app, like Google Authenticator, connected to the user’s account
• The code changes periodically - 3. Via a verification code that is sent via text to the user’s mobile device
• If user’s do not have a verified mobile number they’re prompted to register one when they log into Salesforce. Registering a mobile number verifies it and enables this method when the user is challenged in the future
• The user has the option of telling Salesforce they do not want to register a mobile number, which will turn off the request for one that they see at login - 4. Via a code sent to the user’s email address
• This code expires after 24 hours
- 1. Via push notification to the Salesforce Authenticator mobile app connected to the user’s account
- Two-Factor Authentication can be enabled at two levels:
- For the entire org
- For individual Profiles (new feature Spring ’16)
- In the Session Settings section, look for “Session security level required at login”
- “None” is the default
- “High Assurance” enables Two-Factor Authentication for all users assigned to the Profile
- In the Session Settings section, look for “Session security level required at login”
- SMS Identity Confirmation
- This is when a user is not allowed to login until they enter a verification code that is sent to their mobile device
- SMS Identity Confirmation is used whenever a user attempts to login from an unknown IP address
- This feature is enabled by default for all Salesforce users, and settings can be adjusted if a user does not have a mobile phone
- Temporary Verification Code
- This was a new feature with the Summer ’16 Release
- If a user isn’t able to verify their login because they don’t have their mobile device with them, an Admin can generate a Temporary Verification Code that they can use to log in
- The Temporary Verification Code expires in 8 hours, or can be expired earlier than that by the Admin
- Once the Admin gets the code they must share it with the user right away because it becomes invisible to them as soon as they click away from the user’s record
- Registered User Identity Verification Methods
- There are four verification methods that users can register as ways their session can be verified
- Has Verified Mobile Number
- Has One-Time Password App
- Has Salesforce Authenticator
- Has Temporary Code
- There are four verification methods that users can register as ways their session can be verified
User Switcher
If a user has multiple usernames on the same or on different Salesforce orgs, the User Switcher (new with the Summer ’16 Release) allows the user to log into any of the orgs they have access to without having to open a new tab or window and log into that org separately. This feature works in Lightning Experience only.
Disclaimer: Always do your own due diligence! Although I tried my best to record accurate and understandable notes, actual Salesforce documentation should always take precedence over the information in this blog. 🙂
And here is my caveat to anyone who chooses to use them: always do your own due diligence! If something doesn’t sound/look/feel right, research it! Do not take my notes as the end-all and be-all of information about the platform and all the things that it can do!
Yet another reason that you should always do your own due diligence is that I was still pretty green when I worked through the ADM201 material. I was still learning Salesforce. But that statement would imply that one day you could possibly know everything there is to know about Salesforce. That’s laughable because Salesforce is always changing, so how could you possibly ever get to the end?! In a recent conversation I had with a 20+ year MVP veteran of Salesforce, he mentioned that just keeping up with the constant changes is a full-time job. So “buyer beware” that although I did my best to understand the material and translate it into an outline that makes sense to someone who is fairly new to the platform, I may not have understood the material correctly and as a consequence may not have translated it correctly.
Explorations Into Salesforce 