Field & Object Security: Profiles, Permission Sets & FLS

Field and object security controls what users can do with data: which objects they can access, which fields they can see, and what CRUD operations they can perform. While the sharing model controls which records a user can see, field and object security controls what they can do with those records.

Figure 1. Record access and object/field access are evaluated independently and both must grant access for a user to see data. A user who can see a record via sharing can still be blocked from specific fields by FLS. These two layers do not overlap and must both be designed explicitly.

Profiles

A Profile is the baseline permission assignment for a user. Every user must have exactly one.

What Profiles Control

Category	Permissions
Object permissions	Create, Read, Edit, Delete, View All, Modify All
Field-level security	Visible, Read Only, Hidden per field per object
Tab visibility	Default On, Default Off, Hidden
App visibility	Which Lightning apps are visible
Record types	Which record types are available + default
Page layouts	Which page layout to display per record type
Login hours	When the user can log in
Login IP ranges	Where the user can log in from
System permissions	API Enabled, Author Apex, Manage Users, etc.
Apex class access	Which Apex classes are executable
Visualforce page access	Which VF pages are accessible
Connected App access	Which Connected Apps are available

The Minimum Access Profile Pattern

CTA Best Practice: Minimum Access Profile

The recommended pattern for enterprise Salesforce is to create a Minimum Access Profile (or use the built-in “Minimum Access - Salesforce” profile) that grants almost nothing, then layer permissions using Permission Sets. This mirrors the principle of starting with Private OWD for sharing.

Why minimum access profiles work better:

Traditional Approach	Minimum Access + Permission Sets
Multiple profiles (one per role)	One or few base profiles
Hard to audit; permissions scattered across profiles	Easy to audit; each Permission Set has a clear purpose
Profile cloning creates drift	Permission Sets are reusable building blocks
Changing a profile affects all assigned users	Permission Sets can be assigned selectively
Cannot assign multiple profiles	Can stack multiple Permission Sets
1,500 profile limit (Enterprise Edition); 2,000 (Unlimited Edition)	1,000 Permission Sets + groups

Standard vs Custom Profiles

Feature	Standard Profiles	Custom Profiles
Object permissions	Cannot reduce below standard	Fully configurable
FLS	Can restrict (since Spring ‘23)	Fully configurable
System permissions	Fixed	Configurable
Deletable	No	Yes (if no users assigned)
Editable	Limited	Full
Recommendation	Avoid for real implementations	Always use custom profiles

Standard Profile Trap

Standard profiles (like “Standard User”) have built-in permissions that cannot be removed. For example, Read access to Accounts on the Standard User profile is permanent. This makes standard profiles unsuitable for minimum access architectures. Always create custom profiles.

Permission Sets

Permission Sets add permissions on top of the Profile baseline. They are the primary mechanism for granting granular access in modern Salesforce.

Permission Set Design Principles

1. One concern per Permission Set. “Sales: Create Quotes” not “Sales User Everything.”
2. Name descriptively. Include the functional area and the permission being granted.
3. Never duplicate Profile permissions. Permission Sets are additive.
4. Group logically. Use Permission Set Groups to bundle related sets.
5. Document the purpose. Every Permission Set should have a clear description.

Permission Set Categories

Category	Example	Granularity
Function-based	”Sales: Create Opportunities”	Fine, one business function
Feature-based	”Einstein Analytics User”	Medium, access to a platform feature
Role-based	”Regional Manager Permissions”	Broad; use Permission Set Groups instead
Integration-based	”API: Order Sync Service”	Fine, specific integration needs
Temporary	”Q4 Promotion Campaign Access”	Time-limited (use session-based or assignment expiration)

Permission Set Assignment

Method	Use Case	Automation
Manual assignment	Ad hoc, small scale	None; admin assigns via Setup
Assignment via group	Role-based bulk assignment	Assign Permission Set Group to users
Flow-based assignment	Dynamic, event-driven	Flow assigns/removes based on criteria
Apex-based assignment	Integration-driven	Code assigns during user provisioning
Permission Set Assignment Expiration	Temporary access	Auto-expires after specified date

Permission Set Groups

Permission Set Groups bundle multiple Permission Sets into a single assignable unit. They represent a “role” in the permission model.

Permission Set Group Architecture

Figure 2. Permission Set Groups bundle atomic permission sets into a single assignable unit representing a business role. The muting permission set removes the Delete Opportunity permission within this group without modifying the underlying “Read/Write Opportunities” permission set, preserving its reusability in other groups.

Muting Permission Sets

Muting Permission Sets remove specific permissions from a Permission Set Group without modifying the underlying Permission Sets. This is what makes Permission Sets truly reusable.

Example: The “Write Opportunities” Permission Set grants Create, Read, Edit, Delete on Opportunities. The Sales Manager group needs everything except Delete. Rather than creating a separate Permission Set, a Muting Permission Set blocks Delete.

Without Muting	With Muting
Create “Write Opps No Delete” Permission Set	Reuse “Write Opps” Permission Set
Duplicate Permission Sets for slight variations	One muting set per group removes specific permissions
Permission Set sprawl	Clean, composable architecture

Muting Permission Set Limitations

Muting Permission Sets can only mute permissions within their own Permission Set Group. They cannot mute permissions granted by the user’s Profile or by individually assigned Permission Sets. This reinforces the minimum access profile pattern: if the Profile grants a permission, muting cannot override it.

How Record Access and Object/Field Access Combine

A user must pass BOTH the record-level check AND the object/field-level check to access data. These two layers are evaluated independently, and both must grant access.

Figure 3. Data access requires passing three independent gates in sequence: the sharing model gate, the object CRUD gate, and the FLS gate. Passing two of three is not enough. Each gate can independently deny access or strip fields regardless of what the other gates allow.

CTA Board Framing

When presenting security architecture, explicitly separate the two layers: “For record visibility, I use Private OWD with criteria-based sharing rules. For object and field access, I use a Minimum Access Profile with Permission Set Groups. These are independent: a user who can see a record via sharing still cannot see fields their FLS hides.”

Object Permissions (CRUD)

Object permissions control Create, Read, Edit, Delete (CRUD) plus two elevated permissions: View All and Modify All.

CRUD + View All / Modify All

Permission	What It Does	Requires
Create	Insert new records	Read
Read	View records (subject to sharing)	Nothing
Edit	Update existing records	Read
Delete	Delete records	Read + Edit
View All	See ALL records regardless of sharing model	Read
Modify All	Edit/Delete ALL records + transfer ownership regardless of sharing	Read + Edit + Delete

View All / Modify All vs System Admin

Capability	View All	Modify All	System Admin
See all records (bypass sharing)	Yes	Yes	Yes
Edit all records	No	Yes	Yes
Delete all records	No	Yes	Yes
Transfer record ownership	No	Yes	Yes
Change sharing settings	No	No	Yes
Manage object metadata	No	No	Yes

View All / Modify All Bypass Sharing

View All and Modify All bypass the entire sharing model: OWD, role hierarchy, sharing rules, teams, everything. Use these permissions sparingly and only when genuinely needed (e.g., data stewards, compliance officers, integration users). The CTA board will question any architecture that leans heavily on View All / Modify All.

Field-Level Security (FLS)

FLS controls which fields users can see and edit on an object, independent of object-level permissions.

FLS Settings

Setting	User Can See	User Can Edit
Visible + Editable	Yes	Yes
Visible + Read Only	Yes	No
Hidden	No	No

FLS vs Page Layouts

This distinction is one the CTA board specifically tests:

Aspect	Field-Level Security	Page Layout
What it controls	Data access (API + UI)	UI presentation only
Security enforcement	Yes, enforced at API level	No, only affects page display
Can user see via API?	Only if FLS grants access	Always (if FLS allows)
Can user see in reports?	Only if FLS grants access	Yes (if FLS allows)
Assigned via	Profile or Permission Set	Profile + Record Type combination
True security boundary?	YES	NO

Page Layouts Are Not Security

Removing a field from a page layout does NOT prevent users from accessing that field. They can still see it via reports, list views, API queries, and any custom UI. Only FLS controls true field-level access. The CTA board specifically tests for this mistake.

FLS Best Practices

1. Default to hidden. Only make fields visible when there is a business need.
2. Use Permission Sets for FLS. Do not manage FLS on profiles (minimum access pattern).
3. Audit FLS regularly. Field visibility creeps over time.
4. Remember API access. FLS applies to API calls too; integrations need field access.
5. Test with different users. Verify FLS enforcement in reports, list views, and API.

Tab Visibility

Tab visibility controls whether an object’s tab appears in the app navigation.

Setting	Behavior
Default On	Tab is visible by default
Default Off	Tab is available but hidden by default; user can add it
Tab Hidden	Tab is not available to the user at all

Tab Visibility vs Object Access

Hiding a tab does NOT prevent access to the object’s records. Users can still access records via related lists, search, reports, and direct URLs. Tab visibility is a UI convenience, not a security control.

The Modern Permission Model

The recommended architecture for enterprise Salesforce combines all these elements:

Figure 4. The Minimum Access Profile plus Permission Set Group model enables permission reuse across roles: “PS: Read Accounts” and “PS: Run Reports” are shared by Sales Rep, Sales Manager, and Service Agent without duplication. Muting permission sets handle exceptions without creating role-specific permission set variants.

Related Topics

• Sharing Model: record-level access works alongside object/field access
• Programmatic Security: enforcing FLS and CRUD in Apex code
• Portal Security: external user permission model
• Decision Guides: Profile vs Permission Set decision tree
• Security Best Practices: permission model anti-patterns

Sources

• Salesforce Help: Profiles
• Salesforce Help: Permission Sets
• Salesforce Help: Permission Set Groups
• Salesforce Help: Field-Level Security
• Salesforce Help: Muting Permission Sets
• Salesforce Architects: Permission Set Group Architecture