4. User Management

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 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.

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.

Organization

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.

5 things you can do in the Users list

Create one or more users; Reset passwords for selected users; View a user's detail page by clicking the name, alias, or username; Edit a user's details; Log in as any user if the system permission is enabled or if the user has granted you system administrator login access.

Usernames

Each user has both a username and an email address. 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.

Objects

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.

Private

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

4 Levels of Data Access

Organization; Objects; Fields; Records

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.

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. If you have an org with many users, you may find it easier to assign roles when adding users. However, you can set up a role hierarchy and assign roles to users at any time. Roles are only available in Professional, Enterprise, Unlimited, Performance, and Developer editions of Salesforce.

How to add users via desktop

Set up=>Users=>Users=>New User=>Enter info=>Select user license=>select profile=>Generate passwords and notify user via email=>save

Set Organization-Wide Sharing Defaults

Setup=>Security=>Sharing Settings=>Organization-Wide Defaults=>Edit=>select default access=>select Grant Access Using Hierarcies for custom objects

2 questions for record-level security

Should your users have open access to every record, or just a subset? and, If it's a subset, what rules should determine whether the user can access them?

Records

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.

User account contains at least these 6 types of info

Username, email address, user's first and last name, license, profile, and role (optional)

3 questions for organization-wide defaults

Who is the most restricted user of this object? and, Is there ever going to be an instance of this object that this user shouldn't be allowed to see? and, Is there ever going to be an instance of this object that this user shouldn't be allowed to edit?

Fields

You can use field-level security to restrict access to certain fields, even for objects a user has access to.

Manual sharing

allows owners of particular records to share them with other users. Although manual sharing isn't automated like organization-wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, for example, if a recruiter going on vacation needs to temporarily assign ownership of a job application to another employee.

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, like role hierarchies, are only used to give more users access to records—they can't be stricter than your organization-wide default settings.

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.

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.