05 DEV421 DesigningAppsforMultipleUsers Slides

Designing Apps for
Multiple Users
Force.com
www.salesforce.com/training
Copyright 2010 salesforce.com, inc.
All rights reserved. Various trademarks held by their respective owners.

SE
U
AL
N
R
TE
IN

All rights reserved.
Printed in the U.S.A.
This document contains proprietary information of salesforce.com, inc., it is provided under a license
agreement containing restrictions on use, duplication and disclosure and is also protected by copyright
law. Permission is granted to customers of salesforce.com, inc. to use and modify this document for their
internal business purposes only. Resale of this document or its contents is prohibited.
The information in this document is subject to change without notice. Should you find any problems or
errors, please log a case from the Support link on the Salesforce home page. Salesforce.com, inc. does
not warrant that this document is error- free.
"Salesforce.com" and the "no software" logo are registered trademarks of salesforce.com, inc. Other
names used may be marks of their respective owners.
Copyright 2010 salesforce.com, inc. All rights reserved. 1 Designing Applications for Multiple Users
Safe Harbor Statement
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions.
If any such uncertainties materialize or if any of the assumptions prove incorrect, the results of
salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking
statements we make. All statements other than statements of historical fact could be deemed forward-
lookingg statements, including:
g anyypprojections
j of earnings,
g revenues, or other financial items; anyy statements
regarding strategies or plans of management for future operations; any statements concerning new, planned,
or upgraded services or developments; statements about current or future economic conditions; and any
statements of belief.
The risks and uncertainties referred to above include but are not limited to risks associated with our new
business model; our past operating losses; possible fluctuations in our operating results and rate of growth;
interruptions or delays in our Web hosting; breach of our security measures; the immature market in which
we operate; our relatively limited operating history; our ability to expand, retain, and motivate our employees
and manage our growth; risks associated with new releases es of our service; and risks associated with selling
to larger enterprise customers. Further information on potential factors that could affectct the financial results
LY
of salesforce.com, inc. are included in our registration statement (on Form S-1) and in other filings with the
S iti and
Securities d Exchange
E h C i i
Commission. Th
These d
documents t are available
il bl on th
the SEC Fili
Filings
ngs sec tion off th
section the
salesforce.com website.
Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
N
Any unreleased services or features referenced in this or other press releases
leases or public statements are not
O
currently available and may not be delivered on time or at all. Customers who purchase our services should
make the purchase decisions based upon features
ures that are currently available.
SE
Copyright 2010 salesforce.com, inc. 3
U
AL
N
Course Objectives
R
By the end of this course, you will be able to:

TE
Control access to data in Salesforce.

List the available Salesforce license types
types.
IN
List settings controlled by a profile.

Articulate the differences between a role and a profile.
Describe how to modify the user interface for different users.
Describe the special privileges of a record owner.
List elements of the sharing model and how they are used.
Course Agenda
Design Considerations: Accommodating

Multiple Users in Your App
Managing
g g Your Users Experience
p
Controlling Access to Records
Putting it All Together
LY
N
O
SE
U
AL
N
Assumptions
R
You have an understanding of basic application design.

TE
You are ready to learn!

IN
Module 1: Design
Considerations:
Accommodating g
Multiple Users in
Your App
Designing Apps for Multiple Users
LY
N
O
Various trademarks held by their respective owners.
SE
7
U
AL
N
Module Objectives
R
By the end of this module, you will be able to:

TE
List things to consider when designing an application for

p users.
multiple
multip
IN
List the primary actors in the Recruiting Application.
Module Agenda
Things to Consider
Business Requirements for the Recruiting App
LY
N
O
SE
U
AL
N
Things to Consider When Designing an App

R
Consider the actorswho will be using the app?

TE
What will these users expect to see and do?

What data is most important?
IN
What should these users be able to seeare there any data

restrictions?
How can we make the user experience more streamlined and efficient?
Which users should be able to customize the app?
Module Agenda
Things to Consider
Business Requirements for the Recruiting App
LY
N
O
SE
U
AL
N
Universal Containers Scenario

R
TE
Positi
Po
Positions
ti Candidates/Job
ndidat /J
/Job Apps Reviews
IN
R, C, E R, C, E R, C, E
Recruiter
Re uite
R, C*, E* R* R*, C*, E*
Hiring
g Mgr
g
R R* R**, C**, E**

Interviewer
Legend: R=Read, C=Create, E=Edit * = where assigned **= only their own
Module Review
1. What things should you consider before building an

application?
g application?
2. Who are the actors in the recruiting pp
3. What are the objects that well need to track?
LY
N
O
SE
U
AL
N
Module 2:
R
Managing Your
TE
U Experience
Users Exp
IN
14
Module Objectives

List the different types and characteristics of licenses the
Force.com platform supports.
List the things a profile controls in the application.
List the aspects of the profile that control access to data.
List the permissions that give a System Administrator the
permissions he needs to manage the application.
State the type of profile that can be customized.
Create a profile.
LY
Create a record type to filter picklist values.
Create a record type and page layout to alter the user
N
experience.
Employ field-level security to lock down access to field data.
O
SE
U
AL
N
Module Agenda
R
Licenses
TE
Overview of Profiles
Profiles and Permissions
IN
Profiles and Access to Data

Profiles and the User Interface
License Types
Each user must have a user license.

Different types of user licenses allow different levels of access.
User License Type CRM Access Platform Access

Salesforce D D
Salesforce Platform D
Feature licenses determine whether users have access to additional

features like Mobile or Content.
LY
N
O
SE
U
AL
N
Module Agenda
R
Licenses
TE
IN

What is a Profile?
Defines a users permissions to perform different functions.

Determines how a user sees records to which s/he has access.
Every user has a profile (ONLY 1 profile)
profile).
We can group the things that profiles control into three categories:
Permissions, Access to Data, and User Interface
Permissions Access to Data User Interface
General User Field Level Security Page Layouts
Permissions
LY
Administrative Object CRUD Record Types
Typ
Permissions
Standard/Custom Login Hours and IP Tabs
N
Object CRUD Ranges
Applications
Applicati
O
SE
U
AL
N
What Do Profiles Control?

R
Tab settings determine which tabs users see when they log in.
TE
IN
Permissions determine what users can do to records to which they

have access.
What Do Profiles Control? (cont.)
Login Hours and Login IP Ranges

Sets the hours when users with a particular profile can use the system
Sets the IP addresses from which users with a particular profile can log in
LY
N
O
SE
U
AL
N
Additional Information About Profiles

R
Standard profiles are available.

TE
Permissions on standard profiles cannot be customized.

Developers can create custom profiles
profiles.
IN
When creating a new custom profile, developers need to select a

profile from which to copy over permissions and settings.
Each profile is associated with a license type.
Typically, organizations will have one profile for each actor.
Module Agenda
Licenses
LY
N
O
SE
U
AL
N
Profiles Have a Set of Permissions

R
Profiles control Administrative Permissions.

Permissions
TE
IN
Profiles control General User Permissions.
A Few Permissions to Note
LY
N
O
SE
U
AL
N
Object Permissions
R
Permissions determine what users can do to records to which they

TE
have access.
IN
Lacking the "Read" permission for an object means that users will not
be able to access it at all.
No access in the application or API
No access on reports
No access through search
Exercise 2-1: Creating Custom Profiles
Goal:
5 min.
Create a new profile for recruiters.
Scenario:
At Universal Containers, recruiters need to be able to create,
view, and modify any position, candidate, job application, or
review that is in the system.
To comply with state and federal public records laws, all
recruitment-related info must be saved for several years.
Consequently, recruiters should NOT have the ability to delete
LY
anyy records in the Recruiting
g Application.
pp
Tasks:
Create a custom recruiter profile to accomplish these
N
requirements.
O
Assign a user to this new profile. SE
U
AL
N
Exercise 2-2: Creati

Creating Custom Profiles
R
Goal:
TE
10 min.
Create new custom profiles.
Scenario:
IN
Hiring managers and interviewers have different needs and

different levels of access to the information that will be stored
in the Recruiting Application.
Tasks:
Create a new custom profile for hiring managers.
Create a new custom profiles for interviewers
interviewers.
Assign users to the new profiles.
Module Agenda
Licenses
LY
N
O
SE
U
AL
N
What is Field-Level Security?

R
Restricts users access to view and edit fields

TE
Overrides any less-restrictive fiel

field access settings in page layouts and
y
search layouts
IN
Controls which fields users can a

access in related lists, list views,
reports, Force.com Connect Offline, email and mail merge templates,
custom links, and when synchronizing data or importing personal data
Exercise 2-3: Restricting Access Using Field-Level
Security
Goal:
5 min.
Use field-level security to restrict access to compensation
information.
Scenario:
Universal Containers (UC) wants to completely lock down edit
access to compensation information for hiring managers
through all ways a user could access the Recruiting
application.
Task:
LY
Use field-level security to make the Min Pay and Max Pay
fields on the Position object read-only for hiring managers.
N
O
SE
U
AL
Exercise 2-4: Restricti

Restricting Access Using Field-Level
N
Security
R
Goal:
TE
5 min.
Use field-level security to restrict users access to fields.
Scenario:
IN
Universal Containers wants to ensure that interviewers have

sufficient information to conduct interviews, but needs to limit
what they see and edit on positions and candidates.
Tasks:
Set field-level security for positions: remove the ability for
interviewers to see anyy compensation
p information.
Set field-level security for candidates: remove the ability to
view all fields EXCEPT FOR THE candidates First Name and
Last Name.
Module Agenda
Licenses
LY
N
O
SE
U
AL
N
Record Types
R
Record types are used to tailor user interaction experience to specific

TE
business needs.
Note: Record ttypes
yp only y affect the wayy that data is displayed
p y in the
IN
UI. It is not a form of sub-classing.

Record types can determine page layouts,
layout in conjunction with profiles.
Technical Record Type Non-technical Record Type
Hiring Manager Page Layout A Page Layout B
Recruiter Page Layout C Page Layout C
Or limit picklist options.
Record Types (cont.)
Record types can be set by users.

Existing records: [Change] link next to Record Type field
New records: Initial step before new record edit window
Ability to set default record type
LY
The record types
yp available in the p
picklist
icklist are determined b
byy the user
profile.
Edit Profile | Record Type Settings
N
O
SE
U
AL
N
Exercise 2-5: Creating Record Types

R
Goal:
TE
10 min.
Create a custom record type tthat limits the picklist choices
available to hiring managers.
IN
Scenario:
Technical hiring managers can open new positions, but they
should only open positions in IT and Engineering departments.
When creating a technical position, hiring managers should
have access only to the IT and Engineering values. When
creating a non-technical position, hiring managers should have
access to the other department values. Recruiters should be
p
able to see and use all department values.
Tasks:
Create a Technical Position record type.
Repeat the process, creating a Non-technical Position record
type.
What Does a Page Layout Control?
How detail and edit pages

are organized
Page
g section
customizations
Which fields, related lists,
and Custom Links a user
sees
Field propertiesvisible,
read-only and required
LY
N t M
Note: t bli h
May establish
unique layouts for
different business
N
scenarios
O
SE
U
AL
N
Exercise 2-6: Creat

Creating Page Layouts
R
Goal:
TE
15 min.
Create a new page layout to reflect differences between
technical and non-technical positions.
IN
Scenario:
When creating new positions, technical hiring managers need
to specify technical criteria desired for their candidates, such
as programming language or operating system. Recruiters
need to be able to create all kinds of positions.
Tasks:
Create fields for Operating
p g Systems
y and Programming
g g
Languages.
Create a new page layout for technical positions. On the new
page layout, show the Operating System and Programming
Language fields in a separate section.
Exercise 2-7: Creating Page Layouts and Record
Types
Goal:
10 min.
Create page layouts and record types for approved positions.
Scenario:
Universal Containers would like to implement an approval
process for each position. This process will route positions to
the approvers specified on the position. Once the position has
been approved, the approvers no longer need to be listed on
the position.
Tasks:
LY
Create new page layouts for approved technical positions and
approved non-technical positions.
N
Create new record types for approved technical positions and
O
approved non-technical positions.
SE
U
AL
N
Module Review
R
1. What are the different types of licenses that are available?

TE
2. What do profiles control?

3. What are the permissions that allow a System Administrator
3
IN
to manage the application?

Administrators can customize the
4. True or False: System Admi
permissions of both standard and custom profiles.
5. True or False: When creating a new profile, its possible to
copy over settings from an existing profile.
6. If y
you remove access to an app pp from a pprofile, will users in
that profile still be able to see the tabs included in that
application?
Module Review (cont.)
7. If you hide a tab from a profile, will users in that profile be

able to see records for that object?
8. If y yp for an object,
you have two record types j do yyou need to
have two page layouts for that object?
9. If a user doesnt have access to a specific record type, will
they be able to see the records that have that record type?
10. True or False: A field hidden by field-level security is still
visible through the API.
11. When should you use field-level security? Record types?
LY
P
Page l t ?
layouts?
N
O
SE
U
AL
N
Module 3:
R
Controlling Access
TE
to Records
IN
42
Module Objectives

List the features that affect access to data at the record level.
List the organization-wide default (OWD) settings
settings.
List and define the sharing levels.
Set organization-wide defaults.
Create a role.
Create a public group.
Create a sharing rule.
LY
Manually share records.
N
O
SE
U
AL
N
Module Agenda
R
Overview of Record Access

TE
Record Ownership
Organization
Organization-Wide Defaults
IN
Roles and Groups of Users

Sharing
Record Access
The sharing model determines access to specific records.

Who has access?
What level of access?
Why they have access?
Access to records is dependent on object CRUD.
LY
N
O
SE
U
AL
N
Levels of Record Access

R
Full Access privileges:

TE
View
Full Access
Edit
IN
Transfer Ownership
Transfer ownership
Delete
Delete
Share Read/Write
Share
Edit
Read/Write privileges: Read
View Only
Edit View
Read-only privileges:
View
Ways to Obtain Access to a Record
Full Access: Read/Write or Read-Only

Owner field Access:
User Organization-wide default
Queue member Above user (who has read/write or

read-only access) in role hierarchy
Above user (who has ownership) in
role hierarchy Manually sharing
Profile permission: Modify All Data Sharing rules
Object permission: Modify All Apex sharing

Profile permission: View All Data
LY
Object permission: View All
N
O
SE
U
AL
N
Lets compareProfiles & the Sharing Model

R
Profiles Sharing Model

TE
Controls access to objects Controls access to records (e.g.,

((Candidates,
Candidates, Positions, etc.
etc.)) one candidate, Joe Schmoe,
IN
Controls access to fields one position, Black Box Tester)

(Candidate Name, Min Pay,
Skills Required, etc.)
So, a users 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 fields that user can view and edit.
Module Agenda

Record Ownership
Sharing
LY
N
O
SE
U
AL
N
Record Ownership
R
TE
IN
Most Records have an associated Owner.

Exception: Child records in a master-detail relationship inherit access
rights from parent record.
Types of Owners:
Users
Queues
Record owners have Full Access.
Custom Object Queues
Queues allow groups of users to manage a shared workload more

effectively.
Aqqueue is a location where records can be routed to await p
processing
g
by a group member.
Records remain in the queue until a user accepts them for processing
or they are transferred to another queue.
Developers can specify the set of objects that are supported by each
queue, as well as the set of users that are allowed to retrieve records
from the queue.
LY
A b off a queue has
Any member h ththe same access tto allll record
d iin th
records thee
queue that an owner would have.
N
O
SE
U
AL
N
Exercise 3-1: Creating Custom Object Queues

R
Goal:
TE
5 min.
Create a custom queue for the Recruiting department to hold
p
position and candidate records.
IN
Scenario:
Universal Containers wants to use the queue feature to
manage the pool of recruiters working with open positions and
candidates.
Task:
Create a q
queue for p
positions and candidates.
Module Agenda

Record Ownership
Sharing
LY
N
O
SE
U
AL
N
What are Organization-Wide Defaults (OWD)?

R
Organization-wide defaults are a secu

security setting that defines the
TE
baseline level of access to data records that you do not own.

They
y are the onl
onlyy wayy to restrict access to data in the sharing
g model.
IN
They can be defined for the custom as well as several standard

objects.
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
j
object?
2. Is there ever going to be an instance
of this object that this user shouldnt
be allowed to see?
3. Is there ever going to be an instance
of this object that this user shouldnt
be allowed to edit?
LY
N
O
SE
U
AL
N
Organization-Wide Defaults Considerations

R
Child records in master-detail relationships inherit their organization-

TE
wide defaults from their parents.

Child records in looku
lookupp relationships
p have independent
p organization-
g
IN
wide defaults from their parents.

Changing organization-wide defaults can produce unintended
consequences; consider your business requirements carefully before
setting your organization-wide defaults.
Changing organization-wide defaults can potentially delete manual
sharing if that sharing is no longer needed,
For example
example, changing from Private to Public Read/Write
Read/Write.
Exercise 3-2: Setting Organization-Wide Defaults
Goal:
5 min.
Use organization-wide defaults (OWD) to restrict edit
p
permissions for p
position data.
Scenario:
At Universal Containers, standard users (who are not
recruiters), hiring managers, or interviewers are only allowed to
view position data. There will never be any position that a
standard user is not permitted to see.
Standard users are not ever allowed to edit any position
LY
d
records.
Tasks:
N
Change the organization-wide default setting for Positions.
O
SE
U
AL
N
Exercise 3-3: Setting Organization-Wide Defaults

R
Goal:
TE
5 min.
Establish appropriate organization-wide defaults for
Applications,
Candidates, Job A pp and Reviews.
IN
Scenario:
Interviewers are only permitted to see candidate and job
application records to which theyve been assigned as
interviewers.
Interviewers should only be permitted to view, create, and
modify their own reviews.
Tasks:
Update organization-wide defaults for Candidates and Job
Applications.
Review
1. True or False: Child records in master-detail relationships

have their own organization-wide defaults.
2. What is the most restrictive level of access that can be set on
organization-wide defaults?
3. True or False: Organization-wide defaults can be set for both
standard and custom objects
4. If even one person in your organization is not allowed to see
position data, what MUST your OWD be?
LY
N
O
SE
U
AL
N
Module Agenda
R

TE
Record Ownership
Organization Wide Defaults
IN

Sharing
Universal Containers role hierarchy:
LY
N
O
SE
U
AL
N
What are Roles and Role Hierarchy?

R
A Role:
TE
Controls the level of visibility tthat users have to an organization's data

A user may be associated to one role
IN
The Role Hierarchy:

Controls data visibility
Controls record roll up for reporting
Users *usually* inherit the special privileges of data owned by or
shared with users below them in the hierarchy
Not
N necessarily
il the
h companys
organization
i i chart
h
Role Hierarchy Considerations
With Standard Objects, access to records rolls up through the Role

Hierarchy.
With Custom Objects,
j developers
p choose whether or not access should
roll up through the role hierarchy.
Determined by the Grant Access Using Hierarchies setting on
organization-wide defaults.
LY
N
O
SE
U
AL
N
Knowledge Check
R
TE
IN
Assuming organization-wide defaults are set to Private and Grant Access

U i Hi
Using Hierarchies
hi iis checked:
h k d
1. What can Cynthia Capobianco see?
2. Can Andrew Goldberg see records owned by Amy Lojack? Can he edit
them?
3. Can Megan Smith edit records owned by Mario Ruiz?
Exercise 3-4: Implementing a Role Hierarchy
Goal:
5 min.
Complete the role hierarchy by adding a role for product
g
managers.
Scenario:
Universal Containers has added a new role called Product
Manager and would like the hierarchy to reflect the addition.
Tasks:
Add a new Product Manager role.
LY
Assign users to the new role
role.
Log in as a Product Manager and as the Director of Product
N
Management to test the changes to the hierarchy.
O
SE
U
AL
N
Public Groups
R
Public groups are a way of grouping together users for access.

TE
Can be used in a sharing rule

Can be used to give access to folders
IN
Every organization has a default public group that includes all users, or
if portals or sites are used, includes all internal users.
Public Groups (cont.)
Public Groups can be made up of any combination of:

Users.
Roles.
Roles
Roles and Subordinates.
Public Groups.
Public group membership is updated when public groups
are made up of roles or roles and subordinates, or when
a user is added or removed from the role.
LY
N
O
SE
U
AL
N
Exercise 3-5: Creating a Public Group

R
Goal:
TE
5 min.
Create a new public group including all interviewers.
Scenario:
IN
Universal Containers would like to create a public group that

includes all interviewers so that it can easily share records and
documents with them.
Tasks:
Create a public group called All Interviewers.
Module Agenda

Record Ownership
Organization Wide Defaults
Sharing
LY
N
O
SE
U
AL
N

R
TE
IN
Megan Smiths team cannot see any reviews owned by Andrew Goldbergs
team.
Ben Stuart cannot see reviews written by QA or Product Management.
Melissa Lee cannot see records for candidates she needs to interview.
Sharing Rules and Manual Sharing
Sharing Rules:
Automatic exceptions to organization-wide defaults for particular
groups
g p of users
Used to open up access to records
Never permitted to be more strict than organization-wide default
settings
Manual Sharing:
Used to open up access to a specific record
LY
owners anyone above owners in the role hierarchy
Granted by owners, hierarchy, and
System Administrators
N
O
SE
U
AL
N
Exercise 3-6: Implem

Implementing Sharing Rules
R
Goal:
TE
10 min.
Allow recruiters, recruiting managers, and the VP of Human
recruiting
Resources to view all elements of the recruitin gpprocess.
IN
Scenario:
Recruiters and their management should be able to read and
update every position, candidate, job application, and review
record in the application.
Tasks:
Create sharingg rules to g
give recruiters access to p
positions,
candidates, job applications, and reviews.
Exercise 3-7: Implementing Manual Sharing
Goal:
5 min.
Add manual sharing for various users to grant access on
records where theyy are invested in the information.
Scenario:
Establish manual sharing at Universal Containers to
accomplish the remaining access levels:
Grant hiring managers read and update access on positions
and candidates where they are the hiring manager.
LY
Grant interviewers read access on jjob application
pplication and
candidate records for people they are interviewing.
Tasks:
N
Update manual sharing on a position record.
O
SE
U
AL
N
Apex Sharing Reasons

R
Clicking the Sharing button on a record displays the various reasons

TE
that a user might have access to a record. Examples of sharing

reasons include:
IN
Administrator
Owner
Custom Object Sharing Rule
Establishing Apex sharing reasons allows developers to define the
reason that a user or group of users might have access to a record.
Apex Sharing Reasons (cont.)
The Apex sharing reasons describe why users can access a record.
Examples might be:
Open
p Position ((users have access to a p
position record because that
position is currently open).
Hiring Manager (users might have access to a position because they
are the hiring manager on that position).
Apex sharing reasons are defined for custom objects only.
Apex sharing reasons are defined object by object.
LY
So, p
positions might
ght have different reasons than candidates.
N
O
SE
U
AL
N
Exercise 3-8: Creati

Creating Apex Sharing Reasons
R
Goal:
TE
5 min.
Define the reasons that a record may be shared.
Scenario:
IN
Universal Containers wants to add new Apex sharing reasons

to show the reasons why a record may be shared.
Tasks:
Create new Apex sharing reasons.
Add sharing on a position record to see the new sharing
reasons.
reasons
Sharing Records
Simple
Sharing Manual
Rules Sharing
LY
Automated Flexible
N
Apex
Sharing
O
SE
U
AL
N
Controlling Data Review

R
Permissions
TE
View All Data

Record Ownership
IN
Read-Only
Read/Write
Roles
Above the owner?
Sharing
Sharing Rules
Manual Sharing
Module Review
1. List all of the reasons that a user might be able to see a

particular record.
p
2. What is the difference between a role and a profile?
3. True or False: Sharing rules are used to restrict access to
records.
4. If a developer wanted to set up his organization so that
managers always see records owned by their subordinates,
what feature should that manager use?
5. If a user needed to give access to just one record, what
LY
f t
feature h ld th
should thatt user choose?
h ?
N
O
SE
U
AL
N
R
Module 4: Putting
TE
it All Together
IN
80
Module Objectives

Apply profiles, organization-wide defaults, role hierarchy, and
g to g
sharing govern access to data.
Apply organization-wide defaults, public groups, and manual
sharing to create conditional access to data.
Analyze suitability of field-level security, page layouts, and
record types to satisfy business requirements.
LY
N
O
SE
U
AL
N
Module Agenda
R
Limiting Data Access

TE
Which Tool to Use?

IN
Exercise 4-1: Establishing Data Access
Goal:
20 min. Create a process by which position access is determined by the status of a position.
Scenario:
Universal
U i Containers
lC t i has d
h determined
t i d that
th t open positions
iti should
h ld be
b visible
i ibl tto allll
users, but closed positions should be visible to recruiters (and their management),
hiring managers, and approvers only. Only recruiters and their managers should be
able to add sharing to a position.
Tasks:
Answer the following questions, then update sharing accordingly:
What should the organization-wide default for positions be?
Who should own positions?
LY
Should Grant
Grant Access Using Hierarchies
Hierarchies be checked?
How will recruiters get access to closed positions? Open positions?
How will all users get access to open positions?
N
How will hiring managers get access to closed positions? Open positions?
O
How will approvers get access to closed positions? Open positions?
SE
U
AL
N
Exercise 4-2: Restri

Restricting Data Access
R
Goal:
TE
20 min.
Ensure that the salary for any position is visible only to the
hiring
recruiter, the hirin g manager,
g and the hiring g managers
g boss.
IN
Scenario:
Universal Containers has decided that salary information for
any position should be visible only to the recruiter, the hiring
manager for that position, and the hiring managers boss. The
recruiter should control the salary data.
Tasks:
Determine how to store this information to meet the visibility
requirements outlined above.
Module Agenda
Limiting Data Access

Which Tool to Use?
LY
N
O
SE
U
AL
N
Which Tool to Use?

R
While filling out positions, the hiri

hiring manager wants to fill out the job
TE
description at the top of the page.

responsibilities and job descripti
The recruiter needs to see the name of the hirin
hiringg manager
g and the
IN
status of the position first.

Which tool would you use?
Which Tool to Use? (cont.)
When creating new technical positions, hiring managers should always

have to fill out which certifications are required.
When creating g non-technical p
positions, such as p
positions in sales and
finance, there is no need to see or populate the certification fields.
LY
N
O
SE
U
AL
N
Which Tool to Use? (cont.)

R
Interviewers should NEVER see a candidates Social Security Number.

TE

IN
Module Review
1. Which feature sets the baseline level of access for an object?

2. If a developer wanted interviewers to see positions, but never
see the Grade listed on a p
position, which tool would the
developer use?
3. If a developer wanted to share records with a group of users
who were not all in the same role, how could the developer
do it without creating multiple sharing rules?
4. True or False: System Administrators can see every record in
Salesforce?
LY
N
O
SE
U
AL
N
R
TE
IN

05 DEV421 DesigningAppsforMultipleUsers Slides

Uploaded by

Copyright:

Available Formats

You might also like

05 DEV421 DesigningAppsforMultipleUsers Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 DEV421 DesigningAppsforMultipleUsers Slides

Uploaded by

Copyright:

Available Formats

Designing Apps for

All rights reserved. Various trademarks held by their respective owners.

Copyright 2010 salesforce.com, inc.

Printed in the U.S.A.

By the end of this course, you will be able to:

Control access to data in Salesforce.

List settings controlled by a profile.

Copyright 2010 salesforce.com, inc. 4

Design Considerations: Accommodating

You have an understanding of basic application design.

You are ready to learn!

Copyright 2010 salesforce.com, inc. 6

Designing Apps for Multiple Users

By the end of this module, you will be able to:

List things to consider when designing an application for

List the primary actors in the Recruiting Application.

Copyright 2010 salesforce.com, inc. 8

Things to Consider When Designing an App

Consider the actorswho will be using the app?

What will these users expect to see and do?

What should these users be able to seeare there any data

Copyright 2010 salesforce.com, inc. 10

Universal Containers Scenario

R, C*, E* R* R*, C*, E*

R R* R**, C**, E**

Copyright 2010 salesforce.com, inc. 12

1. What things should you consider before building an

Designing Apps for Multiple Users

By the end of this module, you will be able to:

Profiles and Access to Data

Copyright 2010 salesforce.com, inc. 16

Each user must have a user license.

User License Type CRM Access Platform Access

Feature licenses determine whether users have access to additional

Profiles and Access to Data

Copyright 2010 salesforce.com, inc. 18

Defines a users permissions to perform different functions.

What Do Profiles Control?

Permissions determine what users can do to records to which they

Copyright 2010 salesforce.com, inc. 20

Login Hours and Login IP Ranges

Additional Information About Profiles

Standard profiles are available.

Permissions on standard profiles cannot be customized.

When creating a new custom profile, developers need to select a

Copyright 2010 salesforce.com, inc. 22

Profiles Have a Set of Permissions

Profiles control Administrative Permissions.

Profiles control General User Permissions.

Copyright 2010 salesforce.com, inc. 24

Permissions determine what users can do to records to which they

Copyright 2010 salesforce.com, inc. 26

Exercise 2-2: Creati

Hiring managers and interviewers have different needs and

Copyright 2010 salesforce.com, inc. 28

What is Field-Level Security?

Restricts users access to view and edit fields

Overrides any less-restrictive fiel

Controls which fields users can a

R, C, E R* R, C, E*

R R* R, C, E**