Force.com Application Security

Making sense of Profiles, Permission Sets, Org-Wide Defaults, Roles, Role Hierarchy,

Groups, and Sharing Rules

Force.com Platform Fundamentals walks through all the security options

Lots of options leads to lots of confusion!

How do I secure my App?

Profiles

Permission Sets

Org-Wide Defaults

Roles Role Hierarch

y

Groups

Sharing

?

Security Simplified – 2 Jobs

1. Secure Functions

Objects/fields

What can I do in the app

for data I can see?Create, Read, Edit, Delete

2. Secure Data

Records

Which data can I see?

All, mine, my group, etc.

Mine Yours

Different Goals

1. Secure Functions

What is my job role?Owner – Create, Read, Edit, Delete

Need to know only – ReadEveryone else – None

2. Secure Data

Can I share this record?

Confidential objects– PrivateInformational – Public ReadCollaborative – Public Write

Override through sharing rules

Mine Yours

Different Tools

1. Secure Functions

Secure with:

1. Secure Data

Secure with:

Profiles

Permission Sets

Org-Wide Defaults

Roles Role Hierarch

y

Groups

Sharing

Mine Yours

What can I do in the App for the data that I can see?

Job #1 - Secure Functions

Create Read & Edit

Delete

“CRED”

What objects and fields should a user (by job role) be able to Create, Read, Edit, and Delete ?

What’s your App CRED?

Profiles

Permission Sets

Recruiter, Hiring Manager, Interviewer, Everyone else

Make a plan for each Job Role

Permissions for Interviewers

Default On = on my tab bar by default Default Off = I can add to my tab bar Tab Hidden = I can’t get to records directly

Won’t prevent access. Only CRED will. Can access records indirectly

through links, chatter, related records

Tab Settings

Users can change defaults

Only one Profile per User Set at Org level If a Profile matches your app’s Job Role, use

it!

Secure Functions with Profiles

If you don’t have a matching Profile, create a Permission Set (as many as you want)

Screens layout slightly different, but same settings

Assign Permission Sets to Users

Secure with Permission Sets

Permission Sets

3 models for securing records: Public Read/Write Public Read Only Private

Go into Org-Wide Defaults and set objects to the most restrictive setting needed

Job #2 – Secure Data

Org-Wide Defaults

Mine Yours

Each record has an Owner Person who created the record Can be reassigned

Grant Access Using Hierarchies option Give access to Owner and up in Role Hierarchy… …but also need App CRED in a Profile or

Permission Set

What Your Boss Sees

Org-Wide Defaults

Sharing Rules Roles Roles and Subordinates Public Groups

Overriding the Org-Wide Defaults

Sharing

Either Read Only or Read/Write.Cannot take away access in a rule, only add access.

Role Hierarchy

Looks like an org chart… …but doesn’t have to be

You’re going to have lots of apps. Make this match the org chart!

Think about how you’re going to maintain…

Roles

Groups are any collection of: Other groups Roles Roles and subordinates Users

When Job Roles ≠ SF Roles

Groups

Manual sharing Create a sharing

rule for the specific record

When nothing fits…

Sharing

Need to View or Modify all data Set this up in the Profile or Permission Set

Data Administrators

Profiles

Permission Sets

Security needed

Method used

All users the same

Public Read/Write or Public Read Only org-wide default

Me & my boss Private + Grant Access Using Hierarchies org-wide default

Me & my co-workers

Private + share with role sharing rule

Me & my peers Private + share with group sharing rule

Ad hoc Private + manual sharing

Data Administrator

Profile or Permission set with View All or Modify All

Common Use Cases

Profiles

Permission Sets

Org-Wide Defaults

RolesRole Hierarch

y

Groups

Sharing

No user should own more than 10,000 records if using role hierarchy

Changing owner removes manual sharing, can cause sharing rules to no longer apply

Changing a user’s role can change who can access records

Changing Role Hierarchy causes sharing to be recalculated and can take a while… do off-peak

Change hierarchy from bottom up Keep it simple! Can you explain sharing for

your app?

Best Practices and Warnings

Appendix: Job Aids

Design1. Get Data Model (Objects and Fields) for App2. Determine Job Roles3. Go through Data Model for each Job Role

1. App and Tab visibility2. Create, Read, Edit, Delete, View All, Modify All

for each Custom Object3. Read/Write, Read only, Hidden for each field4. Record sharing requirements

4. Get info on org Profiles, Roles, and Role Hierarchy

Cookbook to Secure an App

Implementation1. Secure Functions

1. If Profile matches Job Role, set up security on Profile2. Else create Permission Set for each Job Role

1. App access, tab visibility, object CREDVaMa, field HRW

2. Secure Data1. Setup View All / Modify All for admins on Profile or

Permission Set2. Set Org-Wide Default to Private/Read/Read-Write, Hierarchy3. For each Job Role, create needed Sharing Rules

(see Common Use Cases for examples)1. Create Groups as needed2. Split existing Roles as needed

4. Train on manual sharing as needed

Cookbook to Secure an App

Object Name

Tab Settings

CREDVaMa Fields (HRW)

Object 1 On/Off/ Hidden

Create/Read/Edit/ Delete/View All/ Modify All

Hide/Read/ Write by field

Object 2

…

Access needed for Job Role

Object Name

Who creates?

Who else needs to see?

Object 1 Job role Role/Role and subordinates/Group/User

Object 2

…

Sharing