2. 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
Hierarchy
Groups Sharing
?
3. 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
4. Different Goals
1. Secure Functions
What is my job role?
Owner – Create, Read, Edit, Delete
Need to know only – Read
Everyone else – None
2. Secure Data
Can I share this record?
Confidential objects– Private
Informational – Public Read
Collaborative – Public Write
Override through sharing rules
Mine Yours
5. Different Tools
1. Secure Functions
Secure with:
1. Secure Data
Secure with:
Profiles Permission
Sets
Org-Wide
Defaults
Roles Role
Hierarchy
Groups Sharing
Mine Yours
6. What can I do in the App for the data that I can see?
Job #1 - Secure Functions
Create Read & Edit Delete
“CRED”
7. 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
8. Recruiter, Hiring Manager, Interviewer, Everyone else
Make a plan for each Job Role
Permissions for Interviewers
9. 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
10. Only one Profile per User
Set at Org level
If a Profile matches your app’s Job Role, use it!
Secure Functions with Profiles
11. 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
12. 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
13. 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
14. 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.
15. 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
16. Groups are any collection of:
Other groups
Roles
Roles and subordinates
Users
When Job Roles ≠ SF Roles
Groups
18. Need to View or Modify all data
Set this up in the Profile or Permission Set
Data Administrators
Profiles Permission
Sets
19. 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
Hierarchy
Groups Sharing
20. 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
22. Design
1. Get Data Model (Objects and Fields) for App
2. Determine Job Roles
3. Go through Data Model for each Job Role
1. App and Tab visibility
2. Create, Read, Edit, Delete, View All, Modify All for each
Custom Object
3. Read/Write, Read only, Hidden for each field
4. Record sharing requirements
4. Get info on org Profiles, Roles, and Role Hierarchy
Cookbook to Secure an App
23. Implementation
1. Secure Functions
1. If Profile matches Job Role, set up security on Profile
2. Else create Permission Set for each Job Role
1. App access, tab visibility, object CREDVaMa, field HRW
2. Secure Data
1. Setup View All / Modify All for admins on Profile or
Permission Set
2. Set Org-Wide Default to Private/Read/Read-Write, Hierarchy
3. For each Job Role, create needed Sharing Rules
(see Common Use Cases for examples)
1. Create Groups as needed
2. Split existing Roles as needed
4. Train on manual sharing as needed
Cookbook to Secure an App
24. 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
25. Object Name Who creates? Who else needs to see?
Object 1 Job role Role/Role and subordinates/Group/User
Object 2
…
Sharing
Create access is like having a bunch of blank forms. Not everyone gets the blank forms. Read & Edit – picture this as a pane of glass that will go over the top of the form. Blue paint is going to block the fields you don’t have access to. Clear glass is like having read access. For edit, we have a hole in the glass and a pencil. Delete access is being given the key to remove the glass, take out the paper form, and throw it away. In securing functions, we have only defined the rules of what data I can create, read, edit, and delete. Do I have a pad of forms, what does my pane of glass look like, and do I get a garbage can? Just because I have these things doesn’t mean I get to look at all completed forms. But when I do get a hold of a record, my “CRED” will dictate what I can do with that record.
This picture is a Data Model of a simple app. You can see your Data Model by going to Setup > Build > Schema Builder, and then selecting all of your objects. Each box is an object, each row in the box is a field. You will secure each object using CRED. In this example, I want Interviewers to be able to read Positions, Job Applications, Candidates; edit Reviews; and not see anything else. You can also override field level security, for example, to hide sensitive data such as social security numbers, and min and max pay.
http://www.salesforce.com/us/developer/docs/fundamentals/Content/adg_securing_permset_interview_try_it.htmYou need to figure out your job roles, then ask what access to objects and fields should each job role will require.
Don’t try to use “Tab Hidden” for security. Only CRED will keep someone out. Tab Hidden just changes how to access, not ability to access.
Setup > Manager Users > ProfilesThis page shows the settings you will need to set for each job role that has a matching Profile.Best practice: limit the number of profiles. Should be big groups of users, not so many you can’t understand them, less than the number of boxes on an org chart, combine where possible. Rule of thumb: if there is a reorg or a new group using the app, you can create new profiles, otherwise if you don’t have a matching profile, use a permission set instead.
Setup > Manager Users > Permission SetsWhen creating a Permission Set, use the Description field to remind yourself why. You may not remember later once you have many apps!To assign a Permission Set to a user, go to Setup > Manage Users > Users. Click User then Edit Assignments
Setup > Security Controls > Sharing SettingsIf one person can’t read it, have to use Private. For most data, you will need to use Private.Public Read/Write – Idea generation, collaborationPublic Read Only – Job postingsPrivate – Reviews
Role hierarchy – gives access to record. CRED ability is based on profile/permission set.If Role Hierarchy doesn’t need access to your object, turn this off! Drives significant overhead (when doing maintenance on Users and Roles) if you have lots of users or records. For more details, see: http://www.salesforce.com/docs/en/cce/record_access_uth/salesforce_record_access_under_the_hood.pdfhttp://www.salesforce.com/docs/en/cce/draes/draes.pdf - Designing Record Access for Enterprise Scale
Setup > Security Controls > Sharing SettingsSet up Org-Wide Default as Private or Public Read Only, and then override through sharing rules. If you set up as Public Read Write, you cannot take away access through a sharing rule. That’s why they are called “sharing rules” not “access rules”. You can only share more, not take away access. You have lots of choices on how to pick people to share with. Try to get the job done with the least number of rules to reduce overhead.(Will show typical UseCases in a few slides)
Setup > Security Controls > Sharing SettingsNo user should own more than 10,000 records if using role hierarchy in Org-Wide Defaults. Will cause problems when that person changes jobs or roles.
When you don’t have a Salesforce Role in the Role Hierarchy to match your Job Role, and you have an easy way to identify the users, create a group. A group also makes sense when you need to share with multiple roles so you only need to maintain one sharing rule.
Groups like “interviewers” may change constantly. You don’t want to get daily emails to add and remove people from a group. Let people assign access as needed with the Sharing button.Note:Changing your sharing model (for example, by changing the record owner)deletes any manual shares
This is the only way sharing is done through Profiles and Permission Sets. Outside of data admins, Profiles and Permission Sets just give you CRED abilities.
If a user owns 10,000+ records:• Turn off hierarchies for that object if not needed• Place user in a separate role at the top of the hierarchy if possible• Not move them out of that top-level role• Keep them out of public groups that could be used as the source for sharing rules
Please provide feedback on use of these Job Aids!
Meet separately with each Job Role and fill out this worksheet (one sheet per role)
After access for all Job Roles is determined, meet with all Job Roles and confirm CRED abilities as a group. Then fill in this worksheet with sharing rules for each Object. Keep in mind Public Read-Write and Public Read Only are options.