Salesforce - User Setup

Feature Licenses Overview

A feature license entitles a user to access an additional feature that is not included with his or her user license, such as Marketing or Work.com. Users can be assigned any number of feature licenses.

Permission Set Groups

A permission set group streamlines permissions assignment and management. Use a permission set group to bundle permission sets together based on user job functions

Permission Set Licenses

A permission set is a convenient way to assign users specific settings and permissions to use various tools and functions. Permission set licenses incrementally entitle users to access features that are not included in their user licenses. Users can be assigned any number of permission set licenses.

Usage-Based Entitlements

A usage-based entitlement is a limited resource that your organization can use on a periodic basis. For example, the allowed number of monthly logins to a Partner Community or the record limit for Data.com list users are usage-based entitlements.

Controlled by Parent

A user can perform an action (such as view, edit, or delete) on a contact based on whether he or she can perform that same action on the record associated with it.

User Licenses

A user license determines the baseline of features that the user can access. Every user must have exactly one user license. You assign user permissions for data access through a profile and optionally one or more permission sets.

User Licenses

A user license determines which features the user can access in Salesforce. For example, you can allow users access to standard Salesforce features and Chatter with the standard Salesforce license. But, if you want to grant a user access to only some features in Salesforce, you have a host of licenses to choose from. For example, if you have to grant a user access to Chatter without allowing them to see any data in Salesforce, you can give them a Chatter Free license.

Add Multiple Users

Add up to 10 users at a time.

Public Read Only

All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.

Public Read/Write

All users can view, edit, and report on all records.

Alias

An alias is a short name to identify the user on list pages, reports, or other places where their entire name doesn't fit. By default, the alias is the first letter of the user's first name and the first four letters of their last name.

Apex managed sharing

Apex managed sharing allows developers to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the "Modify All Data" permission can add or change the sharing on the custom object's record, and the sharing access is maintained across record owner changes.

Organization - Security

At the highest level, you can secure access to your organization by maintaining a list of authorized users, setting password policies, and limiting login access to certain hours and certain locations.

Field-Level Security

Field-level security—or field permissions—control whether a user can see, edit, and delete the value for a particular field on an object. They let you protect sensitive fields without having to hide the whole object from users. Field permissions are also controlled in permission sets and profiles.

Teams

For accounts, opportunities, and cases, record owners can use teams to allow other users access to their records. A team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the level of access each team member has to the record, so that some team members can have read-only access and others can have read/write access. The record owner can also specify a role for each team member, such as "Executive Sponsor." In account teams, team members also have access to any contacts, opportunities, and cases associated with an account.

Freeze or Unfreeze User Accounts

In some cases, you can't immediately deactivate an account, such as when a user is selected in a custom hierarchy field. To prevent users from logging in to your organization while you perform the steps to deactivate them, you can freeze user accounts.

Manual sharing

Manual sharing allows owners of particular records to share them with other users.

Objects - Security

Object-level security provides the simplest way to control which users have access to which data. By setting permissions on a particular type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records of that object. For example, you can use object permissions to ensure that interviewers can view positions and job applications but not edit or delete them.

Private

Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.

Organization-wide defaults

Organization-wide defaults specify the default level of access users have to each others' records. You use organization-wide sharing settings to lock down your data to the most restrictive level, and then use the other sharing tools to selectively give access to other users.

Profiles

Profiles determine what users can do in Salesforce. They come with a set of permissions which grant access to particular objects, fields, tabs, and records. Each user can have only one profile. Select profiles based on a user's job function (the Standard User profile is the best choice for most users). Don't give a user a profile with more access than the user needs to do their job. You can grant access to more items the user needs with a permission set.

Queues

Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue. Use queues to route lead, order, case, and custom object records to a group.

Manual sharing

Record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way.

Record-Level Security (Sharing)

Record-level security lets you give users access to some object records, but not others. Every record is owned by a user or a queue. The owner has full access to the record. In a hierarchy, users higher in the hierarchy always have the same access to users below them in the hierarchy. This access applies to records owned by users, as well as records shared with them.

Role hierarchies

Role hierarchies open up access to those higher in the hierarchy so they inherit access to all records owned by users below them in the hierarchy. Role hierarchies don't have to match your organization chart exactly. Instead, each role in the hierarchy represents a level of data access that a user or group of users needs.

Roles

Roles determine what users can see in Salesforce based on where they are located in the role hierarchy. Users at the top of the hierarchy can see all the data owned by users below them. Users at lower levels can't see data owned by users above them, or in other branches, unless sharing rules grant them access. Roles are optional but each user can have only one.

Sharing rules

Sharing rules enable you to make automatic exceptions to organization-wide defaults for particular groups of users, to give them access to records they don't own or can't normally see.

Sharing rules

Sharing rules let you make automatic exceptions to organization-wide sharing settings for particular sets of users, to give them access to records they don't own or can't normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records—they can't be stricter than your organization-wide default settings.

Username

The username must be formatted like an email address and must be unique across all Salesforce organizations. It can be the user's email address, so long as it is unique.

Records - Security

To control data with greater precision, you can allow particular users to view an object, but then restrict the individual object records they're allowed to see. For example, record-level access allows interviewers to see and edit their own reviews, without exposing the reviews of other interviewers. You can manage record-level access in the following ways.

Delegate Administrative Duties

Use delegated administration to assign limited admin privileges to users in your org who aren't administrators. For example, let's say you want the Customer Support team manager to manage users in the Support Manager role and all subordinate roles. Create a delegated admin for this purpose so that you can focus on other administration tasks.

Unlock Users

Users can be locked out of their org when they enter incorrect login credentials too many times. Unlock users to restore their access.

Restrict User Email Domains

You can define a whitelist to restrict the email domains allowed in a user's Email field.

Fields - Security

You can use field-level security to restrict access to certain fields, even for objects a user has access to. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.

Deactivate (Delete) Users

You can't delete a user, but you can deactivate an account so a user can no longer log in to Salesforce.

Object-Level Security

You specify object permissions in permission sets and profiles. Permission sets and profiles are collections of settings and permissions that determine what a user can do in the application. Profiles are typically defined by a user's job function (for example, system administrator or sales representative). A profile can be assigned to many users, but a user can be assigned to only one profile. You can use permission sets to grant additional permissions and access settings to users. It's easy to manage users' permissions and access with permission sets, because you can assign multiple permission sets to a single user.

user account

contains at least the following: Username Email Address User's First and Last Name License Profile Role (optional)

trust.salesforce.com

your instance's system performance over the last 24 hours

Limitations of Org wide sharing

* Service contracts are always Private. * User provisioning requests are always Private. * The ability to view or edit a document, report, or dashboard is based on a user's access to the folder in which it's stored. * Users can view forecasts only of users and territories below them in the forecast hierarchy, unless forecast sharing is enabled. * When a custom object is on the detail side of a master-detail relationship with a standard object, its organization-wide default is set to Controlled by Parent and it is not editable. * The organization-wide default settings can't be changed from private to public for a custom object if Apex code uses the sharing entries associated with that object.