Security · Module 05
Profiles & Permissions
Lock Data Down by Role, Not by Trust
Some data is sensitive — like how much a deal is worth. Your Finance team should see it. An SDR (Sales Development Rep, someone who just qualifies new leads) shouldn't. The simple two-layer system that controls who sees what, so it's a quick settings change — not an awkward conversation.
About & Business Case #
Why fine-grained permissions matter #
"Our Finance team needs to see contract values on every Opportunity (that's our word for a deal in progress), so they can report revenue correctly. Our SDRs — who just qualify leads — absolutely should not see that number. I don't want to rely on people just 'not looking.'"
You can't keep sensitive data private just by asking people politely not to look. That doesn't scale to hundreds of users, and it won't hold up if anyone ever audits your data. The system itself has to enforce who sees what — the same way, every single place that data could show up.
What this means for you
Sensitive fields stay hidden everywhere — on record pages, in reports, and anywhere else the data could appear. Changing who sees what is just a settings change. You don't need a developer to do it.
Implementation #
Anatomy of the two-tier model #
Think of a Profile like a job badge at a building. It decides which doors you're allowed to open. Every user must have exactly one Profile, and it sets their baseline access — the access level they start with. A Permission Set is like a temporary keycard add-on: it can unlock a few extra doors for one person, but it can never take a door away that their badge already opens.
| Layer | Controls | Can it take away access the other layer grants? |
|---|---|---|
| Profile | Which objects (record types, like Lead or Opportunity) and fields a user can create, view, edit, or delete; which apps and tabs they can see; system-level settings | N/A — this is the baseline everything else builds on |
| Permission Set | Extra access added on top, for specific users | No — it can only add access, never remove what the Profile already grants |
A few important Profile settings ("flags") to know:
| Flag | Effect |
|---|---|
isSystemAdmin | Gives full access to everything — skips every other permission check |
canViewAllData / canModifyAllData | Lets someone see or edit every record in the org, no matter who owns it |
canCustomizeApplication | Lets someone manage objects, fields, layouts, and apps |
marketingAccess | Marketing Access: campaigns, templates, segments, and email and messaging settings |
The ADMIN role is special
A user's ADMIN role is different from their Profile. Someone with the ADMIN role skips profile checks completely — it doesn't matter what their assigned Profile says, they can do anything. This is useful for the people who run the whole platform, but hand it out carefully and sparingly.
1 Hide a sensitive field from one profile #
contract_value__c (or any sensitive custom field), and uncheck "Can Read" for this profile.Try a Permission Set
Create a Permission Set that grants Delete on Opportunity, and attach it only to your team lead. Notice how it adds that one extra ability without needing a whole second profile.
How to Use #
Day-to-day: everyone #
Day-to-day: admins #
What to try next
Continue to the Sharing Rules & OWD trail — Profiles control what a user can do with a record type in general; Sharing Rules control which specific records they can see.
Quiz #
Test what you learned #
canViewSetupisSystemAdminmarketingAccess