Security and Access - Salesforce - ADM 201 15%

Public Group

A public group is a collection of individual users, other groups, individual roles, and/or roles with their subordinates that all have a function in common. Before creating a sharing rule, it's important to set up the appropriate public group. Using a public group when defining a sharing rule makes the rule easier to create and, more important, easier to understand later, especially if it's one of many sharing rules that you're trying to maintain in a large organization.

Sharing Records Manually

A record owner can share individual records with other users by using the Share button on the record. Record owners can easily remove the manual shares if the access is not needed anymore.

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.

Auditing features include: Setup Audit Trail

Administrators can also view a Setup Audit Trail, which logs when modifications are made to your organization's configuration.

Auditing features include: Record Modification Fields

All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information.

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.

What are three tools to control access to the organization?

At the highest level, you can secure access to the data in your organization by: -managing authorized users, -setting password policies, and by -limiting when and from where which users can log in.

Levels of Data Access: 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.

Restricting Login Access by IP Address

By default, Salesforce doesn't restrict the location for login access. You might want to restrict the allowed range of IP addresses to those inside your corporate firewall, so employees can't log in from other locations. You can specify an IP address range for the entire organization or for specific user profiles, but the behavior is very different for each option.

Restricting Login Access by Time

By default, Salesforce doesn't restrict the times for login access. For each profile, you can specify the hours when users can log in. For example, for employees who only need to access customer data during business hours, you can deny login access during evening hours and weekends.

Field-Level Security

In some cases, you may want users to have access to an object, but limit their access to individual fields in that object. Field-level security—or field permissions—control whether a user can see, edit, and delete the value for a particular field on an object. These are the settings that allow us to protect sensitive fields such as a candidate's social security number without having to hide the fact that the candidate object even exists.

Can organization-wide defaults grant users more access than they have through their object permission?

No, organization-wide defaults can never grant users more access than they have through their object permission.

Managing Object Permissions

Object-level security provides the simplest way to control data access. 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.

Levels of Data Access: 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. 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.

Page layouts control the visibility of fields on detail and edit pages. Can page layouts be used as a shortcut to limit user access to individual fields?

Page layouts only control the visibility of fields on detail and edit pages. Field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results. Indeed, in order to be absolutely sure that a user can't access a particular field, it's important to use the field-level security page for a given object to restrict access to the field. There are simply no other shortcuts that will provide the same level of protection for a particular field.

Permission Sets (object permissions)

Permissions are granted to users on any object record: Create, Read, Edit, and Delete. You can use permission sets to grant additional permissions and access settings to users. Users can have many permission sets. You can use permission sets to grant additional permissions, without changing anyone's profiles.

Profiles (object permissions)

Profiles determine the objects a user can access. Users can have only one profile. This means you can use profiles to grant the minimum permissions and settings that all users of a particular type need.

standard profiles

Read Only Standard User Marketing User Contract Manager System Administrator

Is there ever going to be an instance of this object that this user shouldn't be allowed to see? If the answer is YES, what sharing model should you use?

Sharing model = PRIVATE

Is there ever going to be an instance of this object that this user shouldn't be allowed to edit? If the answer is YES, what sharing model should you use?

Sharing model = PUBLIC READ-ONLY

Is there ever going to be an instance of this object that this user shouldn't be allowed to edit? If the answer is NO, what sharing model should you use?

Sharing model = PUBLIC READ/WRITE

Sharing rules

Sharing rules represent automatic exceptions to your organization-wide default settings. This enables you to make automatic exceptions to your organization-wide sharing settings for defined sets of users. Sharing rules can never be stricter than your organization-wide default settings. They simply allow greater access for particular users.

Which standard profile has the widest access to data and the greatest ability to configure and customize Salesforce?

The System Administrator

Levels of Data Access: 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. For example, record-level access allows an interviewer to see and edit her own reviews, without exposing the reviews of other interviewers. You can manage record-level access in these four ways.

Record-Level Security

To control data with greater precision, you can allow particular users to view an object, but then restrict the individual records they're allowed to see. Record access determines which individual records users can view and edit in each object they have access to in their profile.

How does role hierarchy determine the levels of access users have to your organization's data?

Users assigned to roles near the top of the hierarchy (normally the CEO, executives, and other management) get to access the data of all the users who fall directly below them in the hierarchy.

If you set the login IP range at the at the profile level:

Users outside the permitted range are always denied access.

If you set the login IP range at the organization level:

Users who log in outside the set range are shown a login challenge. If they complete the challenge question, typically by entering an activation code sent to their mobile device or email address, login access is granted. This method does not restrict access, entirely, for users outside of the set IP range. The set IP range is called the "trusted" IP range.

What special permissions does the System Administrator have?

View All Data Modify All Data

Auditing features include: Field History Tracking

You can also enable auditing for individual fields, which will automatically track any changes in the values of selected fields. Although auditing is available for all custom objects, only some standard objects allow field-level auditing.

What kind of access can you grant with sharing rules?

You can assign either Read-Only or Read/Write access.

Auditing features include: Login History

You can review a list of successful and failed login attempts to your organization for the past six months.

Criteria-based sharing rules...

You can share records owned by certain users or meeting certain criteria.

Levels of Data Access: Fields

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.

Deactivated and frozen users

You can't delete a user, but you can deactivate an account so a user can no longer log in. Sometimes 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. Deactivated and frozen users lose access to any records that were manually shared with them, or records that were shared with them as team members. However, you can still transfer their data to other users and view their names on the Users page.

A profile is...

a collection of settings and permissions that determine which data and features in the platform users have access to. Settings determine what users can see, for example, apps, tabs, fields, and record types. Permissions determine what users can do, for example, create or edit records of a certain type, run reports, and customize the app.

A permission set is...

a collection of settings and permissions that give users access to various tools and functions. Permission sets extend users' functional access without changing their profiles. Use permission sets to grant additional permissions to specific users, on top of their existing profile permissions, without having to modify existing profiles, create new profiles, or grant an administrator profile where it's not necessary.

Sharing rules work best when they're defined for...

a particular group of users that you can determine or predict in advance, rather than a set of users that frequently changes.

The enhanced profile user interface provides...

a streamlined experience, making it easy to navigate, search, and modify settings for a profile. Permissions and settings are organized into pages under app and system categories, which reflect the rights users need to administer and use app and system resources.

Role hierarchies

allow you to ensure a manager will always have access to the same records as his or her subordinates. Each role in the hierarchy represents a level of data access that a user or group of users needs.

Manage record-level access using 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.

Manual sharing

allows record owners to give read and edit permissions to users who might not have access to the record any other way.

A profile can be assigned to many users...

but a user can be assigned to only one profile at a time.

To allow users to log in at any time...

click Clear all times.

The easiest way to create a profile is to...

clone an existing profile that's similar to the one you want to create, and then modify it.

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.

Manage record-level access using 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 additional users access to records—they can't be stricter than your organization-wide default settings.

Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the role hierarchy, unless...

in the Organization-Wide Defaults related list, if the Grant Access Using Hierarchies option is disabled for a custom object. If that is disabled, only the record owner and users granted access by the organization-wide defaults receive access to the object's records. By default, the Grant Access Using Hierarchies option is enabled for all objects, and it can only be changed for custom objects.

Manage record-level access using 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 should represent a level of data access that a user or group of users needs.

Salesforce has two profile interfaces:

original and enhanced.

Apex managed sharing allows developers to...

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

To prohibit users from using the system on a specific day...

set the start and end times to the same value.

In environments where the organization-wide sharing setting for an object is Private or Public Read Only, an administrator can grant users additional access to records by...

setting up a role hierarchy or defining sharing rules. However, sharing rules can only be used to grant additional access—they cannot be used to restrict access to records beyond what was originally specified with the organization-wide sharing defaults.

You can further expand access, to additional groups of users, using...

sharing rules.

Manage record-level access using 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 record-level security and sharing tools to selectively give access to other users.

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 record-level security tools to grant access to selected users, as required.

Each record owner can manually share individual records with other users by using...

the Share button on the record.

If the user has any permission sets assigned, these also set...

the baseline permissions in conjunction with the profile.

When object- versus record-level permissions conflict...

the most restrictive settings win.

You can configure access at four levels:

the organization, objects, fields, or individual records.

Access to records a user does not own are set first by...

the organization-wide defaults.

A user's baseline permissions on any object are determined by...

the profile.

If the organization-wide defaults are anything less than Public Read/Write, you can open access back up to certain roles using...

the role hierarchy.

The object is on the detail side of a master-detail relationship, automatically inherits...

the sharing setting of its parent.

If users are logged in when their login hours end...

they can continue to view their current page, but they can't take any further action.

There are two ways of setting object permissions:

using either profiles or permission sets.

You can never edit the object permissions on a standard profile. However...

you can clone any existing profile, and use that as the basis for a new profile, adjusting the apps and system settings as needed.

The role hierarchy enables these behaviors:

-A manager will always have access to the same data as his or her employees, regardless of the org-wide default settings. -Users who tend to need access to the same types of records can be grouped together.

You can define field-level permission in one of two ways:

-For multiple fields on a single permission set or profile -For a single field on all profiles

Before configuring record access, it's useful to answer the following questions:

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

To manually grant access to a record, you must be one of the following users:

-The record owner -A user in a role above the owner in the hierarchy (if your organization's sharing settings control access through hierarchies) -Any user granted "Full Access" to the record -An administrator

Profiles control:

-The standard and custom objects the user can view, create, edit, and delete -The object fields the user can view and edit The specific functions that users can perform, like viewing the Setup menu and customizing applications The tabs the user can view in the app The standard and custom apps the user can access The Apex classes a user can execute The Visualforce pages a user can execute The page layouts a user sees The record types available to the user The hours during which the user can log in to the app The IP addresses from which the user can log in to the app The password policies, such as password length, complexity, and expiration time

To determine the organization-wide defaults you need for your app, you need to answer the following questions for each object:

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

Although you can configure the security and sharing model entirely using the user interface, it is implemented at the API level. That means...

...any permissions you specify for objects, records, and fields apply even if you query or update the data via API calls. This ensures the security of your data is protected, regardless of how it is accessed.