🧠 CTA Knowledge Bytes #5 - Salesforce Security Architecture

Security architecture isn't a checkbox—it's a comprehensive strategy!

Security architecture isn’t a checkbox—it’s a comprehensive strategy that can make or break your Salesforce implementation. As an Architect, you’re not just designing security settings—you’re architecting a defense-in-depth system that protects customer’s organizations most valuable asset i.e. data.

Here’s how CTAs design bulletproof security models:

🏗️ The Security Layer Stack:

Layer 1 - Organization-Wide Defaults (OWD):

• Private / Public Read Only / Public Read/Write / Controlled by Parent

• Controls baseline record visibility across the entire org

• Strategic consideration: OWD changes require sharing recalculation (can take hours in large orgs)

Layer 2 - Role Hierarchy:

• Grant access UP the hierarchy automatically

• Opening mechanism ONLY—cannot restrict access

• Key insight: Role hierarchy grants READ access; edit permissions still require profile/permission sets

• Performance consideration: Deep hierarchies (10+ levels) can impact sharing calculations

Layer 3 - Profile & Permission Sets:

• Profiles: One per user—controls object/field CRUD, system permissions, page layouts, record types

• Permission Sets: Additive permissions, infinitely stackable, assigned as needed

• Permission Set Groups: Logical grouping of permission sets with muting capabilities

• Modern approach: Minimal profiles + permission sets for flexibility

Layer 4 - Sharing Rules:

• Criteria-based sharing: Share records matching specific criteria

• Owner-based sharing: Share records based on owner characteristics

• Opens access to specific users, roles, territories, or public groups

• Cannot restrict below OWD—only opens access

• Limitation: Maximum 300 sharing rules per object

Layer 5 - Manual/Programmatic Sharing:

• Implicit Sharing:

  • Parent-child relationships (Master-Detail, Lookup with grant access)

  • Account Teams, Opportunity Teams, Case Teams

  • Territory Management hierarchies

• Explicit Sharing:

  • Manual shares via sharing button

  • Apex managed sharing (Share objects)

  • Sharing reasons for tracking and removal

• Apex Sharing: Custom sharing logic via AccountShare, OpportunityShare, etc.

Layer 6 - Record Ownership:

• Determines base access level for record CRUD

• Ownership transfer triggers sharing recalculation

🎯 The Principle of Least Privilege (PoLP):

The Right Approach:

1. Start with minimum access (Private OWD, minimal profile)

2. Add permissions incrementally based on validated business needs

3. Conduct regular access reviews and audits (quarterly minimum)

4. Document all security decisions and exceptions

❌ Don’t:

• Give broad access and try to restrict later (impossible in many cases)

• Clone the System Admin profile “to save time”

• Grant access based on assumptions without validating use cases

✅ Do:

• Grant minimal access and expand deliberately with business justification

• Use permission sets to add granular permissions

⚠️ Security Restriction Rules

Restriction Rules (Shield/Advanced):

• RESTRICT access even for System Admins

• Filter records based on criteria (e.g., “Hide records where PII_Protected__c = TRUE”)

• Use cases: PII protection, regulatory compliance (GDPR, HIPAA, SOX)

• Cannot be bypassed—creates true data isolation

• Evaluation: Applied AFTER all opening mechanisms (OWD, sharing rules, etc.)

💡 CTA Security Design Principles:

1. Security by Design, Not by Afterthought

• Every architectural decision has security implications

• Consider security during requirements gathering, not after build

• Security requirements should drive architecture, not constrain it

2. Defense in Depth

• Layer multiple security controls

• If one layer fails, others provide backup protection

• Example: OWD (Private) + Sharing Rules + FLS + Validation Rules + Apex Security

3. Auditability & Compliance

• Enable field history tracking on sensitive fields

• Use Setup Audit Trail and Field Audit Trail

• Implement event monitoring for privileged user actions

• Document security model in solution architecture documents

4. Performance & Scalability

• Sharing calculations impact performance—especially with complex hierarchies

• Minimize sharing rule count where possible

• Consider Territory Management for sales hierarchies (more efficient than role hierarchy)

• Monitor sharing table sizes (AccountShare, OpportunityShare, etc.)

🔍 Common Security Anti-Patterns:

❌ Using “Public Read/Write” OWD to avoid complexity Why it’s wrong: Defeats purpose of layered security, creates data governance nightmare ✅ Better approach: Use Private OWD + targeted sharing rules

❌ Over-relying on Profile cloning Why it’s wrong: Creates maintenance burden, difficult to audit, inflexible ✅ Better approach: Minimal profiles + permission sets architecture

❌ Ignoring implicit sharing in M-D relationships Why it’s wrong: Creates unintended access paths, security audit failures ✅ Better approach: Document all implicit sharing, consider lookup + sharing rules when appropriate

❌ Not planning for record ownership transfers Why it’s wrong: Breaks workflows, impacts reporting, causes sharing recalculation storms ✅ Better approach: Design ownership models upfront, automate transfers thoughtfully

❌ Granting “View All” / “Modify All” permissions liberally Why it’s wrong: Bypasses OWD and sharing rules completely, creates audit gaps ✅ Better approach: Reserve for integration users only, document business justification

❌ Treating security as IT’s problem, not Architecture’s problem Why it’s wrong: Security is foundational to architecture—not a separate concern ✅ Better approach: Security requirements drive architectural decisions from day one

📚 Want to dive deeper? Check out my CTA Knowledge Bytes series covering:

• Enterprise Architecture Patterns

• Integration Architecture

• Data Migration Strategies

• Identity & Access Management

• Security Architecture (this post!)

🔔 Follow me for weekly CTA insights and practical architecture wisdom

#CTAKnowledgeBytes #SalesforceArchitecture #EnterpriseArchitecture #AI #Agentforce

Salesforce | Salesforce Architecture Talk | Salesforce Partners | Salesforce Architects | Salesforce Admins | Salesforce Developers