Security Trade-offs

Every security decision involves trade-offs. The CTA board does not just want to hear what you recommend — they want to hear what you considered and rejected, and why. This page catalogs the most important security trade-offs that arise in CTA scenarios.

Restrictive vs Open OWD

The fundamental tension: how locked down should the default record access be?

Dimension	Restrictive (Private OWD)	Open (Public Read/Write OWD)
Security	Maximum — users only see what is explicitly shared	Minimum — all users see all records
Complexity	Higher — sharing rules, teams, or Apex sharing needed to grant access	Lower — no sharing configuration needed
Performance	Share table rows created for every record; sharing recalculation on rule changes	No share table overhead; fastest queries
Scalability	Share tables grow with record volume; recalculation time increases	No scalability concern from sharing
Audit	Clear audit trail of who has access and why	No access controls to audit
Flexibility	Can open access selectively as needs change	Cannot restrict without changing OWD (breaking change)
LDV impact	At 10M+ records, share tables can become a bottleneck	No share table impact

CTA Positioning

Start with the restrictive approach and present the trade-offs honestly. “I’ve set Account OWD to Private because the scenario has partner users who should not see each other’s accounts. The trade-off is that I need four sharing rules to grant cross-team visibility for internal users, which adds sharing recalculation overhead. Given the record volumes described (2M accounts), this is acceptable.”

When Restrictive OWD Becomes Problematic

flowchart TD
    Private["Private OWD"] --> Q1{"Record volume?"}
    Q1 -->|"< 1M records"| OK1["Sharing overhead\nis manageable"]
    Q1 -->|"1M - 10M records"| Caution["Monitor sharing\nrecalculation time"]
    Q1 -->|"> 10M records"| Q2{"How many\nsharing rules?"}
    Q2 -->|"< 20"| Monitor["Acceptable with\nmonitoring"]
    Q2 -->|"20-50"| Redesign["Consider role hierarchy\nredesign to reduce rules"]
    Q2 -->|"> 50"| Rethink["Rethink architecture:\n- Flatten hierarchy\n- Territory management\n- Apex managed sharing\n- Consider data archival"]

    style OK1 fill:#2e7d32,color:#fff
    style Caution fill:#e65100,color:#fff
    style Rethink fill:#c62828,color:#fff

Security vs Usability

The more secure a system is, the more friction users experience. Finding the right balance is an architectural skill.

Security Measure	Usability Impact	Mitigation
MFA on every login	Additional step; lost devices block access	Salesforce Authenticator push notification reduces friction; backup codes for lost devices
Private OWD + sharing rules	Users cannot see records they expect to see; “why can’t I see this?” support tickets	Clear communication; well-designed sharing rules; sharing reason field on shared records
FLS hiding fields	Users confused by missing data; reports appear incomplete	Document which user types see which fields; provide appropriate list views and reports
Session timeout (short)	Users logged out frequently; work may be lost	Balance timeout length with security requirements; auto-save functionality
IP restrictions	Remote workers blocked; VPN required	Use IP relaxation for Connected Apps; Named Credentials for integrations
Platform Encryption	Search limitations; report filter restrictions; slower typeahead	Communicate limitations upfront; redesign reports; use deterministic where search is needed
SSO (no direct login)	If IdP is down, users cannot access Salesforce	Configure breakglass admin accounts that bypass SSO; monitor IdP availability

Sharing Model Complexity vs Performance

flowchart LR
    subgraph "Simple Model"
        S1["2-3 level hierarchy"]
        S2["5-10 sharing rules"]
        S3["Fast recalculation"]
        S4["Easy to audit"]
    end

    subgraph "Complex Model"
        C1["8+ level hierarchy"]
        C2["50+ sharing rules"]
        C3["Hours for recalculation"]
        C4["Impossible to audit"]
    end

    S1 -.->|"Adding requirements"| C1
    S2 -.->|"Adding requirements"| C2

    style S1 fill:#2e7d32,color:#fff
    style S2 fill:#2e7d32,color:#fff
    style C1 fill:#c62828,color:#fff
    style C2 fill:#c62828,color:#fff

Dimension	Simple Sharing	Complex Sharing
Role hierarchy depth	2-4 levels	8-15 levels
Sharing rules per object	5-15	50-100+
Recalculation time	Minutes	Hours (defer to maintenance window)
Debugging access issues	Straightforward	”Why can this user see this record?” becomes a multi-hour investigation
Onboarding new admins	Quick training	Weeks to understand the model
Impact of changes	Predictable	Ripple effects across rules

When to Accept Complexity

• The business has genuinely complex data access requirements (multi-territory, matrix management, regulatory segmentation)
• The alternative (Public OWD with manual processes) creates security risk
• The organization has dedicated Salesforce architects who can maintain the model
• Performance testing confirms acceptable recalculation times

When to Simplify

• More than 50 sharing rules per object — redesign the hierarchy
• Sharing recalculation takes more than 4 hours — too many rules or too many records
• Admins cannot explain who has access to what — the model is too complex to govern
• Users report “I can see records I shouldn’t” or “I can’t see records I should” frequently

Encryption Impact Analysis

The trade-off between data protection and platform functionality is the most concrete and testable security trade-off.

Functionality Impact by Encryption Scheme

Capability	Unencrypted	Deterministic	Probabilistic
SOQL WHERE (exact match)	Full	Yes	No
SOQL WHERE (LIKE, CONTAINS)	Full	No	No
SOQL ORDER BY	Full	Limited	No
Aggregate functions (SUM, AVG)	Full	No	No
Validation rules	Full	Limited	Limited
Workflow field comparisons	Full	Limited	Limited
Duplicate rules	Full	Exact match	No
Report grouping	Full	Yes	No
Report filtering	Full	Exact match	No
Search (SOSL)	Full	Depends on search index encryption	No
Formula references	Full	Limited functions	Limited functions
Auto-complete	Full	No	No

Encryption Can Break Production

Enabling encryption on a field that is used in SOQL WHERE clauses with LIKE, ORDER BY, or aggregate functions will break those queries in production. Always do a thorough code and configuration scan before encrypting any field.

Cost of Encryption

Cost Dimension	Impact
License cost	Shield is 30-50% of platform license cost
Functionality regression	Features break; users lose search/filter capabilities
Development effort	Code must be reviewed and potentially refactored
Testing effort	Every report, integration, and workflow touching encrypted fields must be tested
Operational overhead	Key management, rotation, disaster recovery for keys
Performance	Encrypted field operations are slower (encrypt/decrypt overhead)

Profile Complexity vs Permission Set Groups

Dimension	Many Profiles	Minimum Access + PSG
Initial setup effort	Lower (clone existing profiles)	Higher (design atomic Permission Sets)
Ongoing maintenance	High (changes across all profiles)	Lower (change one Permission Set)
Auditability	Difficult (permissions scattered)	Clear (each PS has one purpose)
Scalability	Poor (profile limit: 1,500)	Good (PSG composition is flexible)
User provisioning	Assign one profile	Assign one PSG (bundles multiple PS)
Exception handling	Create another profile clone	Add/remove individual PS or use Muting PS
Migration effort	N/A (legacy approach)	Significant (retrofitting existing profiles)

Multi-Org Identity Trade-offs

Multi-org scenarios (common after M&A or in global enterprises) introduce identity complexity that the CTA board frequently probes.

flowchart TD
    subgraph "Option A: Single IdP for All Orgs"
        IdPA["Central IdP\n(e.g., Okta)"]
        IdPA -->|SAML| Org1A["Production Org"]
        IdPA -->|SAML| Org2A["Sandbox / Dev Org"]
        IdPA -->|SAML| Org3A["Acquired Co Org"]
    end

    subgraph "Option B: SF Org as IdP"
        MainOrg["Main SF Org\n(Identity Provider)"]
        MainOrg -->|"SF-to-SF SAML"| Org2B["Secondary Org"]
        MainOrg -->|"SF-to-SF SAML"| Org3B["Acquired Org"]
    end

Dimension	Central External IdP (Option A)	Salesforce as IdP (Option B)
Best when	Existing IdP serves all apps; M&A consolidation	No external IdP; SF is primary system
Deprovisioning	Disable at IdP; all orgs locked out instantly	Must manage Connected Apps per org
MFA	Single MFA policy at IdP	MFA at IdP org; spokes trust it
Cost	IdP license cost	No additional license cost
Risk	IdP outage blocks all access	Compromised IdP org compromises all orgs
Complexity	One SAML config per org	Connected App per spoke org

IdP Architecture Trade-offs

Dimension	SF as Service Provider	SF as Identity Provider
Best when	Corporate IdP exists (Okta, Azure AD, ADFS)	SF is the user SOR (portals, small companies)
User experience	Consistent with other corporate apps	SF-centric; other apps redirect to SF
MFA management	IdP handles MFA centrally	SF handles MFA (or delegates)
User provisioning	IdP provisions via SCIM/JIT	Manual or custom provisioning
Deprovisioning	Disable at IdP; SSO stops working	Must deactivate in SF explicitly
Availability	Dependent on IdP uptime	Dependent on SF uptime
Complexity	SAML/OIDC configuration	Connected Apps for each SP
Cost	IdP license cost	No additional cost

Session-Based vs Permanent Permissions

Dimension	Permanent Permission Sets	Session-Based Permission Sets
Access duration	Always active	Active only during qualifying session
Use case	Standard business roles	Elevated access, step-up authentication, time-limited access
Security posture	Permissions always available	Permissions only when actively needed
Complexity	Simple — assign and forget	Requires activation logic (Flow, Auth Provider, Apex)
Audit trail	User always has permissions	Clear audit of when permissions were activated/deactivated
User experience	Transparent	May require re-authentication or additional steps

The Security Architecture Decision Summary

For CTA board presentations, frame security trade-offs using this structure:

flowchart TD
    Decision["Security Decision"] --> Recommend["1. State your recommendation"]
    Recommend --> Why["2. Explain why\n(tie to requirements)"]
    Why --> Tradeoff["3. Acknowledge the trade-off\n(what you sacrifice)"]
    Tradeoff --> Mitigate["4. Explain how you mitigate\nthe trade-off"]
    Mitigate --> Alternative["5. Note what you considered\nand rejected"]

    style Decision fill:#1565c0,color:#fff
    style Tradeoff fill:#e65100,color:#fff
    style Mitigate fill:#2e7d32,color:#fff

Example: “I recommend Private OWD for Accounts because the scenario includes partner users who should not see each other’s customer data. The trade-off is increased sharing complexity — I need three criteria-based sharing rules to grant regional visibility for internal sales teams. I mitigate this by keeping the role hierarchy flat at four levels and using public groups as sharing targets, which simplifies future changes. I considered Public Read Only but rejected it because partner users would see all Account names, which the scenario identifies as confidential.”

Related Topics

• Sharing Model — sharing architecture details
• Shield Encryption — encryption details and impact
• Field & Object Security — permission model architecture
• Identity & SSO — identity architecture decisions
• Decision Guides — visual decision flowcharts
• Security Best Practices — patterns and anti-patterns

Sources

• Salesforce Architects: Sharing and Visibility
• Salesforce Architects: Data Protection
• Salesforce Help: Platform Encryption Considerations
• Salesforce Architects: Security Architecture