Salesforce Data Security: Field-Level Security, Profiles, and Shield Basics

Every Salesforce admin eventually faces the same question: who should see what? Get it wrong and sensitive salary data lands in front of the wrong team, or a well-meaning user edits a field they should only read. Get it right and security becomes invisible — people simply see what they need, nothing more.

Start with the principle of least privilege

The rule is simple: give each user the minimum access they need to do their job, and nothing extra. That sounds strict, but it is actually liberating. When access is tight and deliberate, you stop firefighting permission problems and start trusting your data.

Profiles are the foundation. Each user has one profile, and it controls the baseline: which objects they can see, create, edit, or delete, and which fields are visible. Think of a profile as the job description for access. Sales reps get one baseline, support agents another, managers a third.

Field-level security does the fine work

Object access is coarse. Field-level security is where the real control lives. A support agent may need to see a case, but not the customer's payment details stored on it. A sales rep may need to see an opportunity amount, but not the discount approval notes.

Set field visibility per profile: visible, read-only, or hidden. Review it whenever you add a new sensitive field — the default is often more open than you expect. One practical habit: whenever you create a field that holds personal, financial, or HR data, immediately check its field-level security before you move on. That thirty-second habit prevents most accidental exposures.

This pairs naturally with getting the basics right elsewhere in your org. If your required-field strategy is shaky, users will find workarounds that undermine security too — see our guide on how to make fields required in Salesforce.

Permission sets fill the gaps

Profiles are one-per-user, so they cannot cover every exception. That is what permission sets are for: small, targeted grants layered on top of a profile. A sales rep who occasionally approves discounts gets a permission set for that, not a whole new profile.

Keep permission sets small and named for what they do — "Approve Discounts up to 10%" beats "Extra Access 3". And where access should be temporary, use expiration dates so it removes itself. Our walkthrough on permission sets with an expiration date shows exactly how to set that up.

What about Shield?

Salesforce Shield adds three enterprise-grade layers: Platform Encryption, Event Monitoring, and Field Audit Trail. Most small teams do not need Shield on day one. But know when it matters: if you handle regulated data, need to prove who viewed a record, or must retain a long audit history, Shield is the conversation to have with your Salesforce partner.

Event Monitoring, in particular, answers the question every security review asks: who accessed what, and when? Without it, you are guessing.

A quick security checklist

1. Audit profiles once a quarter — remove access people no longer need.
2. Check field-level security on every new sensitive field.
3. Name permission sets clearly and expire temporary access.
4. Turn on login history and setup audit trail reviews.
5. Test as a real user: log in as a sales rep profile and try to see what you should not.

Security in Salesforce is not a one-time project. It is a habit of small, deliberate decisions. Start with least privilege, use field-level security for the fine work, and let permission sets handle the exceptions — your future self, facing an audit, will be grateful.

---

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.