Building Applications with Force.com and VisualForce(Dev401)( 八):Designing Applications for Multiple Users: Controling Access to Records.

Module Objectives
1.List feature that affect access to data at the record level.
2.List the organization wide default(OWD) settings.
3.List and define the sharing levels.
4.Set Organization wide defaults.
5.Create a role.
6.Create a public group.
7.Create a sharing rule.
8.Manually share records.

Module Agenda
1.Overview of Record Access
2.Record Ownership
3.Organization Wide Defaults
4.Roles and "Groups" of Users
5.Sharing

Record Access
1.The sharing model determines access to specific records
- Who has access?
- What level of access?
- Why they have access?
2.Access to records is dependent on object CRUD.

Levels of Record Access
1.Full Access privileges:
- View
- Edit
- Transfer ownership
- Delete

- Share

 

Ways to Obtain Access to a Record
1.Full Access:
- Owner Field
. User
.Queue member
- Above user(who has ownership)in role hierarchy
- Profile permission:"Modify All Data"
2.Read/Write or Read Only access:
- Organization Wide Default
- Above user(who has read/write or read only access) in role hierarchy
- Manually sharing 
- Sharing rules
- Apex sharing
- Profile permission: "View All Data"

Let's compare...Profiles & the Sharing Model
Profiles
1.Controls access to objects(Candidates, Positions,etc.)
2.Cotrols access to fields(Candidate Name, Min pay, Skill required,etc.)
Sharing Model
1.Controls access to records(ex:one candidate,Joe Schmoe,one position,Black Box tester)
So, a User'profile might specify that a user can see candidates, but the sharing model determines which candidates that user can see.
The sharing model might determine that a user can see Joe Schmoe, But the profile specifies which field that user can view and edit.

Record Ownership
1.Most Records have an associated Owner
-Exception:child records in a master-detail relationship inherit access rights from parent record
2.Types of Owners
- Users
- Queues 
- Record owners have Full Access

Universal Containers Scenario
1.At Universal Containers, Al employees are allowed to view open potions.
2.There will never be any position that an employee is not permitted to see.
3.Hiring managers should be able to update and view all fields only for positions where they are the hiring manager.
4.Recruiters should be able to view and update all positions that they own.
5.Interviews should only be able to view candidates and job applications to which they have been assigned.
6.Interviews should be able to create and edit their own reviews, but they shouldn't be able to read reviews of others.
7.Universal Containers needs to set organization wide defaults for the objects in its Recruiting Application to satisfy these requirements.

What are Organization Wide Defaults (OWD)?
1.Organization Wide defaults are a security setting that defines the baseline level of access to data records that you do not own.
2.They are the only way to restrict access to data in the sharing model.
3.They can be defined for the custom as well as several standard objects.
4.Access levels:
- Public Read/Write(all users can see and edit every record)
- Public Read Only (all users can see every record)
- Private (users can only see records that they own)

Determining How to Set OWD for an object
Questions to ask:
1.Who is the most restricted user of this object?
2.Is there ever going to be an instance of this object that his user shouldn't be allowed to see?
3.Is there ever going to be an instance of this object that this user shouldn't be allowed to edit?

Organization Wide defaults considerations
1.Child records in master-detail relationships inherit their organization wide defaults from their parents.
2.Child records in look-up relations have independent organization wide defaults from their parents.
3.Changing organization wide defaults can produce unintended consequence consider your business requirements carefully before setting your organization wide defaults.
4.Change organization wide defaults can potentially delete manual sharing if that sharing is no longer needed,
 - For example, change from Private to Public Read/Write.

Review
1.True or False:Child records in master detail relationships have their own organization wide defaults.
False
2.What is the most restrictive level of access that can be set on organization wide defaults?
Private.
3.True of False:Organization wide defaults can be set for both standard and custom objects.
True.
4.IF even one person in your organization is not allowed to see position data, whant must you OWD be?
Private.

Universal Containers Scenario
1. Universal Containers' role hierarchy:

What are Roles and Role Hierarchy?
1.A Role:
- Controls the level of visibility that users have to an organization's data.
- A user may be associated to one role.
2 The Role Hierarchy:
- Controls data visibility.
- Controls record roll up for reporting
- Users usually inherit the special privileges of data owned
- Not necessarily the company's organization chart.

Role Hierarchy Considerations
1.With Standard Objects, access to records rolls up through the Role Hierarchy.
2.With Custom Objects, developers choose whether or not access should roll up through the role hierarchy.
- Determined by the Grand Access using Hierarchies setting on organization wide defaults.

Knowledge Check
Assuming organization wide defaults are set to Private and Grand Access Using Hierarchies is checked:
1.What can Cynthia Capobianco see?
2.Can Andrew Golbberg see records owned by Amy Lojack?can he edit them?
3.Can Megan Smith edit records owned by mario Ruiz?

Public Groups
1.Public groups are a way of grouping together users for access.
- Can be used in s sharing rule.
- Can be used to give access to folders.
2.Every organization has a default public group:Entire Organization
3.Public Groups can be mad up of any conbination of 
- Users
- Roles
- Roles and Subordinates
- Public Groups
4.When public group are and up of roles or roles and subordinates, when a user is added or removed from the role,public group membership is updated.

Universal Containers Scenario
1.Megan Smith's team cannot see any reviews owned by Andrew Goldberg's Team
2.Ben Stuart cannot see reviews written by QA or Product Management
3.Melissa Lee cannot see records for candidates she needs to interview

Sharing Rules and Manual Sharing
1.Sharing Rules:
- Automatic exceptions to organization wide defaults for particular groups of users.
- used to open access to records.
- Never permitted to be more strict than organization wide default settings.
2.Manaul Sharing:
- used to open up access to records on a one-off basic when it is too difficult to come up with a consistent set of users who need access.
- Granted by owners, anyone above owners in the role hierarchy, and system Administrators.

Apex Sharing Reasons
1.Click the Sharing button on a record displays the various reasons that a user might have access to a record. Example of sharing reasons include:
- Administrator
- Owner
- Custom Object Sharing Rule
2.Establishing Apex sharing reasons allows developers to define the reason that a user or group of users might have access to a record.