Modern Salesforce Security Strategy: Balancing Profiles and Permission Sets
🔗 Inspired by this insightful video
If you’re responsible for managing user access in Salesforce, you know the struggle: too many custom profiles, inconsistent permissions, and a tangled web of access that’s hard to maintain or scale.
While the long-term vision is to move to permission sets and permission set groups, there’s still a practical need to manage profiles—especially for baseline access like login, app visibility, and UI features that can only be controlled at the profile level.
Here’s a smart approach to streamline your security model—without creating chaos.
🔧 Step 1: Simplify and Standardize Profiles
Instead of having dozens of unique profiles per role or department, consolidate your org to three generic profiles:
- Admin Profile – Only for system administrators with full access.
- Baseline Profile – A stripped-down profile with only login access, default app, and minimal object CRUD. No advanced permissions.
- Integration Profile – Read-only or API-focused permissions used for system or integration users.
🧹 Clean Up Tip: Remove any features from the profile that can be controlled via permission sets. For example:
- Tab Visibility → remove from profile, handle with permission sets
- Object Permissions → remove from profile, handle with permission sets
- Record Types → remove from profile, assign via permission sets
🧱 Step 2: Create Permission Sets for Granular Control
Once you’ve offloaded the non-essential stuff from profiles, begin building layered permission sets.
🔹 Baseline Access PS
A generic permission set for basic Salesforce access (tabs, navigation, chatter access, utility bar, etc.).
🔹 Department Access PS
Create one per department or function. For example:
- Sales PS → Access to Leads, Opportunities, Accounts
- Service PS → Access to Cases, Knowledge, Omni-Channel
- Finance PS → Read access to Opportunities, edit access to Billing objects
🔹 Feature-Based PS
Break down further into fine-grained features:
- Edit Contacts PS
- Create Campaigns PS
- Run Reports PS
🧱 Step 3: Combine Using Permission Set Groups
With permission set groups, you can now create role-specific bundles. For example:
Sales Rep PSG =
☑️ Baseline Access
☑️ Sales Department Access
☑️ Feature: Run Reports
☑️ Feature: Edit Contacts
Customer Support PSG =
☑️ Baseline Access
☑️ Service Department Access
☑️ Feature: Close Case
☑️ Feature: Knowledge Article Contributor
🚫 Step 4: Use Muting Permissions to Fine-Tune
Sometimes a permission set group grants more than what a user in a specific team should have. Instead of creating a whole new PSG, use muting.
🔍 Example:
Your Customer Support PSG includes the “Delete Case” permission via a generic permission set. But your Tier 1 agents should not be able to delete.
✅ Create a Muted Permission Set within the PSG to disable Delete on Case — this keeps the structure clean while preventing privilege escalation.
✅ Final Thoughts
This layered approach—generic profiles + modular permission sets + PSGs + muting—is scalable, auditable, and future-proof. It lets you assign access based on real-world business needs rather than static job titles or legacy structures.
If you’re looking to clean up your org’s access model, I highly recommend watching the full YouTube video. It’s packed with practical examples and best practices.
Have you implemented a permission set-first model in your org? What challenges did you run into, and how did you overcome them?
Let’s discuss 👇
Ignyteforce Inc. 