Salesforce Security for Dutch RevOps Teams

Salesforce Security for Dutch RevOps Teams

As Salesforce grows, the complexity of access often increases without anyone noticing.

New teams are granted permissions.
Integrations are added.
Automation remains active.

Something that rarely happens: an old entry is deleted.

As a result, over time it becomes unclear who can see what.

Security issues rarely stem from the platform itself, but rather from configuration choices that have never been reviewed.

Why Salesforce Security Is Weakening

Security starts strong but weakens due to growth.

Common causes: 

•  New roles without clearing old permissions
• Temporary access that becomes permanent
• Integrations with overly broad permissions
• Automation that bypasses visibility

In CPQ-driven environments, the risk increases because pricing and contract data are more sensitive.

The shared responsibility model

Salesforce secures the platform.
You manage the configuration.

Most risks arise from:

• Sharing rules that are too broad
• Reusing profiles
• Integration users with full access
• Flows and triggers in SystemContext

This is not only a technical issue, but also a compliance issue.

1. Identity and login security

A solid foundation starts with identity management.

Important:

• Multi-factor authentication
• Monitoring of login history
• Verification of setup changes

Security measures must be tailored to actual usage.

Being too strict leads to workarounds.
Too lax leads to data breaches.

2. Permissiondesign

Over-permissioning is a common problem.

A stable model:

• Profiles with minimal permissions
• Permission Sets for additional access
• Automatic review upon role change
• Periodic review of rights

Without management, things tend to get out of hand.

3. Record and field security

Sensitive data should be restricted.

Key principles:

• Restrictive Organization-Wide Defaults
• Sharing only when necessary
• Field-level restriction

Examples of sensitive data:

• Pricing Information
• Revenue figures
• Personal data
• Contract Terms

How to Analyze Security

Security issues are rarely immediately apparent.

Analyze:

• Role structure, profiles, and permission sets
• Access by user and by role
• Integration Usage and API Permissions
• Automation and system context

Measure first. Understand later.

Integrations and automation

Integrations pose a significant risk if they are not properly configured.

Best practices:

• Use separate integration users
• Restrict permissions to required fields
• Document access and usage

For automation:

• Please follow the sharing guidelines whenever possible
• Use systemcontext only when necessary
• Record exceptions

Restore security without disruption

Removing permissions suddenly can cause problems.

Use a phased approach:

• Define desired access by role
• Adjust permissions gradually
• Test using realistic scenarios
• Monitor impact

Security within RevOps architecture

Security is an integral part of your revenue generation process.

It's touching:

• Sales
• Finance
• Operations

When the access is incorrect:

• The emergence of shadow processes
• Is data being exported?
• Are you losing control?

Good architecture ensures consistent access at every stage of the lifecycle.

Practical guidelines

Keep security manageable:

• Design access based on data ownership
• Conduct periodic security reviews
• Document configuration and decisions
• Anticipate increasing complexity
• Test using real-world user scenarios

In summary

Security compromised by a combination of access and configuration issues.

Without analysis, risks remain hidden.
With a structured approach, access remains manageable.

Effective security isn't about more rules, but about a clear architecture and controlled access.

Colin Hammer

Colin Hamer is a Software Engineer at CaseNine. He is responsible for various Salesforce projects at clients.