A forecast can look sound while the wrong people can edit its inputs or view sensitive deal details. FLS gives revenue teams a practical way to restrict individual fields without blocking the everyday work that keeps pipeline moving.
For a small SaaS team, this might mean limiting discount approval fields. For a larger team, it may also cover margin data, commission details, customer personal data, and integration identifiers containing sensitive information. The audit starts with business risk, then traces how each role receives access through assigned grants and related access paths.
Key takeaways
- Field-level security controls whether a user can view or edit a field. It does not replace object-level permissions, record sharing, or page layouts.
- Audit sensitive fields by business impact, not only by object. Opportunity Amount may be broadly visible, while Margin or Approved Discount needs narrower access.
- Prefer reusable permission sets and permission set groups for role-based grants. Keep profiles as a baseline where your org still relies on them.
- Test permissions with representative non-admin users in record pages, reports, list views, search, exports, APIs, and connected tools.
- Review access after role changes, new fields, integrations, compensation-plan changes, and major sales-process updates.
Salesforce field-level security: what it controls
FLS sets access for a field on standard objects or custom objects. Administrators can grant View, grant Edit, or withhold access; validation rules instead protect save behavior and data quality. Salesforce describes field permissions as the controls that determine whether users can view or edit each field on an object.
A hidden field should not appear simply because someone adds it back to a layout. However, you still need to test all data paths that matter to your business.
Object permissions decide the starting point
Object access governs whether someone has Read and Edit permissions, can create records, or can delete them. If an SDR lacks Read permission on Opportunity, granting visibility to Discount_Percent__c changes nothing.
Field-level security narrows what a user can do after object access exists, providing access control at the field level. An account executive might edit Opportunity records but only view a calculated Gross Margin field. Finance may view and edit the same field during an approval process.
Sharing and role hierarchy decide which records appear
Record-level sharing decides which Accounts, Contacts, Opportunities, or custom records a person can reach. Organization-wide defaults, sharing rules, teams, territories, manual sharing, and the role hierarchy all affect that scope.
FLS decides which fields appear on the records that the person can already access. A sales manager can inherit access to team opportunities through the role hierarchy, yet still lack access to Compensation Plan or Internal Margin fields.
Page layouts shape the screen, not the permission boundary
Page layouts control what a user sees on record detail and edit pages. They are useful for reducing clutter and showing fields at the right sales stage, but visibility settings are not the permission boundary.
Salesforce’s guidance on page layouts and field-level security notes that field security controls access across broader surfaces, including list views, reports, and search. If a field is merely removed from a layout, a user may still find it elsewhere when FLS permits it.
A page layout can simplify a rep’s screen. The control determines whether that rep has access to the value at all.
Start with a sensitive revenue-field inventory
Don’t audit every field with equal urgency. Begin your field-level security audit with fields that can expose customer data, change revenue outcomes, or affect financial decisions. Then add other fields in waves.
Use API names as well as labels. Labels change during process redesigns, while API names help admins, developers, and integration owners identify the same field.
Group fields by business risk
Revenue teams commonly need different access to fields containing sensitive information:
- Pricing and approvals, such as List Price, Discount Percent, Approved Discount, Cost, Gross Margin, and deal-desk notes.
- Forecast and compensation data, such as Forecast Category, quota attainment, commission rate, payout status, and manager adjustments.
- Customer personal data, such as personal email, mobile phone, address, date of birth, or identity fields. These fields require tighter audience definitions for data security.
- Technical fields, such as external IDs, integration status, sync errors, source-system timestamps, and middleware payload references.
An Opportunity Amount is often necessary for sellers and managers. A margin calculation, compensation adjustment, or bank-related field usually has a smaller audience. Write down the intended audience before inspecting current permissions.
Map access to real work, not job titles
Job titles are inconsistent. One company’s account executive negotiates discounts, while another submits a request to Deal Desk. An implementation manager may need product entitlements but never pricing logic.
Define each role by its required actions. For example, marketing operations may view campaign attribution and lead-source fields but shouldn’t edit Opportunity pricing. Customer success may view contracted products and renewal dates while lacking access to prospect compensation data.
Run a repeatable field-permission audit
A consistent field-level security audit prevents temporary exceptions from becoming permanent access. Start with the roles that touch active revenue records, then include contractors, managers, finance partners, and integration users.
Build a role-to-field evidence sheet
Create one row for each sensitive field and role combination. Capture the object, field API name, data owner, business reason, expected access, current access, field permissions, permission source, reviewer, and review date.
Next, list every user and the user profiles, permission sets, and groups assigned to them. Permission set groups are useful when several access bundles make up one operating role, such as Sales - AE - Base plus Sales - AE - Approved Pricing.
Salesforce supports field permissions through profiles and assigned access bundles. Its current permission-set field-security setup supports assigning access through those bundles when your org has enabled the available option.
Compare intended access with effective access
Review the user’s profile first, then assigned permission sets and groups. Assigned sets can add field access beyond the profile baseline.
Evaluate effective access across profiles, assigned sets, and groups, never from the profile alone.
Also review the object’s permissions. Field editability requires object permissions, record-level access to the record, and the field’s edit setting. Conversely, a user with edit access to the record may have read access only, leaving the sensitive field read-only. Document validation rules separately when they affect whether a save succeeds; they don’t grant field access.
For each mismatch, record one of three outcomes: approved business need, access to remove, or decision pending from the field owner.
Look for common revenue-team exceptions
Pay special attention to temporary coverage assignments, former managers, contractors, outsourced operations staff, and users who changed roles. Those accounts often keep access from a previous job.
Integration users need their own review. Document each connected app, middleware service, sync account, and API user that reads or writes restricted fields. Grant each integration only the field access it needs. An integration may require an external ID without needing compensation data or internal deal notes.
Use an access-review matrix before changing permissions
This sample matrix gives reviewers a shared baseline for field-level security. Adapt it to your objects, sales motion, and licensing model, then use the Expected access column to guide permission sets.
| Role | Sensitive field example | Expected access | Typical business reason |
|---|---|---|---|
| SDR | Lead score and source | View | Prioritize assigned outreach |
| Account executive | Approved Discount | View or Edit after approval design | Price within defined authority |
| Sales manager | Forecast Category | View and Edit | Inspect and update team forecast |
| Marketing operations | Opportunity Margin | No access | Margin does not support campaign operations |
| Customer success manager | Renewal Date | View and Edit | Manage renewal plan and risk |
| Finance or Deal Desk | Gross Margin and commission fields | View or Edit | Validate pricing and payout decisions |
| Integration user | External CRM ID | View or Edit | Maintain approved data sync |
Apply the principle of least privilege: grant only the access each role needs to complete its assigned work. Under the principle of least privilege, broad editing rights require an owner, a business reason, and a review date.
Remediate gaps without breaking revenue work
Fix the highest-risk field-level security gaps first, especially fields involving customer personal data, pricing approvals, margins, forecasts, and compensation. Make changes in a sandbox when your release process supports it, then move them through your normal deployment path.
Use permission sets for targeted grants
Permission sets make access easier to explain and remove because they can match a specific job function or temporary responsibility. Use clear names such as RevOps - Forecast Admin or Sales - AE - Pricing Approver.
Avoid Super Admin access as a shortcut for routine work. Also avoid creating a new one-off set for every person. If a permission set needs a long explanation, split it into a base role set and a narrow add-on with a documented owner.
Profiles can still carry field permissions and provide baseline permissions in many established orgs. For targeted access, use reusable sets rather than one-off grants to individual users. Salesforce provides a profile-based FLS configuration path through Object Manager, Fields & Relationships, and the selected field’s security settings.
Remove access in the right layer
Remove a grant from the profile, permission set, or permission set group that created it. Don’t only remove the field from a page layout. That leaves access intact in other Salesforce surfaces because the underlying FLS grant remains the real access control boundary.
When you create a new custom field, assign field access and review validation rules as part of the build checklist. Document its owner, purpose, and access decision to support data governance. Salesforce UI labels and available options can vary by edition, license, release, and enabled features, so confirm the current controls in your org before publishing changes.
Field history tracking records selected field changes when configured, while validation rules help enforce valid saves and support data integrity. These controls address separate problems and don’t replace FLS.
Validate changes across every relevant path
An administrator’s view isn’t proof that a revenue role has the right effective access under field-level security. System Administrator access can hide a permission problem because it’s far broader than a rep’s real access.
Test with representative users
Use a test user or a user with the same profile and assigned permission sets as the affected role. Before testing field behavior, confirm the user has the expected object permissions. Check a record the user should access and one they should not access through sharing.
Then test the expected experience:
- Open a record detail page and edit page.
- Create or update a record where the field should be editable, and confirm applicable validation rules behave as expected.
- Run a report and open a list view that could expose the field.
- Search for records using the field where search behavior matters.
- Test connected apps, exports, API processes, and automation with their actual credentials.
Salesforce notes that search protection has limits for high-field-count objects. Review protected field behavior in search if your object has more than 100 searchable custom fields.
Confirm business outcomes after release
Ask a sales rep, manager, marketer, and RevOps owner to validate the workflow they perform each day. Capture blocked essential work, unexpected field exposure, report differences, automation failures, and data integrity issues. Where configured, use field history tracking as supporting evidence for related record changes.
Hiding a field alone doesn’t erase values that were exported earlier, copied into a warehouse, synced to another platform, or exposed by an overly broad integration account. Review connected apps, export practices, data-retention policies, and permissions in downstream systems separately as part of data security.
Frequently asked questions
What is the difference between FLS and record layouts?
Field-level security controls whether a user can view or edit a field. Record layouts control whether a field appears on a record page for a given layout assignment. Use layouts for usability and FLS for enforcement.
Should we use profiles or permission sets for access?
Use targeted sets and groups for role-specific grants where possible. They make these grants easier to assign and remove. Profiles remain relevant because they can contain baseline access settings, particularly in older org designs.
Does FLS restrict fields in reports and list views?
Field permissions affect availability across Salesforce surfaces, including reports and list views. Still, validate each role’s live experience after a change, especially when custom reports, managed packages, search, integrations, or external reporting tools are involved.
How often should revenue teams audit field permissions?
Run a focused review after new sensitive fields, role changes, integrations, acquisitions, compensation changes, or sales-process redesigns. A deeper scheduled review each quarter is a practical baseline for most revenue teams.
Make field access a living revenue control
A Salesforce field-level security audit connects sensitive fields to real responsibilities, then tests the access users receive across relevant systems.
The goal is not to hide every field. It is to give each person the right level of access for the work they own. Pricing, forecasts, customer data, and internal financial details require deliberate access control guided by the principle of least privilege.
