Security Decision Guides

This page provides visual decision flowcharts for the most critical security architecture decisions on the CTA exam. Use these as mental models when analyzing scenarios — the board expects you to articulate the decision process, not just the final answer.

Decision 1: OWD Selection Per Object

For each object in the data model, follow this decision tree to select the correct OWD.

flowchart TD
    Start["For object X:\nDoes ANY user exist who\nshould NOT see ALL records?"] -->|Yes| Private["OWD = Private"]
    Start -->|No| Q2{"Does ANY user exist who\nshould NOT EDIT all records?"}
    Q2 -->|Yes| PRO["OWD = Public Read Only"]
    Q2 -->|No| Q3{"Is this object\nLeads or Cases?"}
    Q3 -->|Yes| Q4{"Should any user be able\nto reassign/transfer?"}
    Q4 -->|Yes| Transfer["OWD = Public Read/Write/Transfer"]
    Q4 -->|No| PRW1["OWD = Public Read/Write"]
    Q3 -->|No| PRW2["OWD = Public Read/Write"]

    Private --> ExtQ{"Are there\nexternal users?"}
    PRO --> ExtQ
    ExtQ -->|Yes| ExtOWD["Set External OWD\n(same or MORE restrictive\nthan internal)"]
    ExtQ -->|No| HierQ{"Should managers see\nsubordinate records?"}
    ExtOWD --> HierQ

    HierQ -->|Yes| GrantHier["Enable 'Grant Access\nUsing Hierarchies'"]
    HierQ -->|No| NoHier["Disable hierarchy access\n(rare: HR, compensation)"]

    style Private fill:#c62828,color:#fff
    style PRO fill:#e65100,color:#fff
    style PRW1 fill:#2e7d32,color:#fff
    style PRW2 fill:#2e7d32,color:#fff
    style Transfer fill:#1565c0,color:#fff
    style ExtOWD fill:#c62828,color:#fff

CTA Approach

Walk through this decision tree for every object in the scenario. Start with the most sensitive objects first. The board wants to see a systematic process, not gut instincts.

Decision 2: Sharing Strategy Selection

Once OWD is set to Private, determine how to open access for users who need it.

flowchart TD
    Start["Users need access to\nrecords they don't own"] --> Q1{"Does access follow\nthe management hierarchy?"}
    Q1 -->|Yes| RoleHier["Role Hierarchy\n(Automatic upward visibility)"]
    Q1 -->|No| Q2{"Does access follow a\npredictable pattern?"}

    Q2 -->|Yes| Q3{"Is the pattern based on\nrecord ownership or field values?"}
    Q3 -->|"Ownership\n(who owns the record)"| OwnerRule["Ownership-Based\nSharing Rule"]
    Q3 -->|"Field values\n(Region, Type, Status)"| CriteriaRule["Criteria-Based\nSharing Rule"]

    Q2 -->|No| Q4{"Is access per-record\nand collaborative?"}
    Q4 -->|Yes| Q5{"Which object?"}
    Q5 -->|"Account"| AccTeam["Account Teams"]
    Q5 -->|"Opportunity"| OppTeam["Opportunity Teams"]
    Q5 -->|"Case"| CaseTeam["Case Teams"]
    Q5 -->|"Other"| Manual["Manual Sharing\nor Apex Sharing"]

    Q4 -->|No| Q6{"Is access driven by\ncomplex business logic?"}
    Q6 -->|Yes| ApexSharing["Apex Managed Sharing\n(Programmatic)"]
    Q6 -->|No| Q7{"Is access territory-based\nwith overlapping assignments?"}
    Q7 -->|Yes| ETM["Enterprise Territory\nManagement"]
    Q7 -->|No| OwnerRule2["Revisit Sharing Rules\nor Role Hierarchy design"]

    style RoleHier fill:#2e7d32,color:#fff
    style OwnerRule fill:#1565c0,color:#fff
    style CriteriaRule fill:#1565c0,color:#fff
    style AccTeam fill:#e65100,color:#fff
    style ApexSharing fill:#c62828,color:#fff
    style ETM fill:#4a148c,color:#fff

Sharing Mechanism Complexity and Performance

Mechanism	Setup Complexity	Performance Impact	Maintenance Burden	Scale Limit
Role Hierarchy	Low	Low (built-in)	Low	~500 roles (practical)
Ownership Sharing Rules	Low	Medium (recalculation)	Low	300 per object
Criteria Sharing Rules	Low	Medium (recalculation)	Medium	100 per object
Teams	Medium	Low per record	Medium	No hard limit
Territory Management	High	Medium-High	High	Complex territory models
Apex Managed Sharing	High	Varies (depends on code)	High	Governor limits

Decision 3: Identity Architecture

Determine the identity architecture for the scenario based on existing infrastructure and user types.

flowchart TD
    Start["Identity Architecture\nDecision"] --> Q1{"Does the customer have\nan existing corporate IdP?"}

    Q1 -->|"Yes (Okta, Azure AD,\nADFS, Ping)"| SFasSP["Salesforce = Service Provider\nCorporate IdP authenticates users"]
    Q1 -->|No| Q2{"Is Salesforce the\nsystem of record for users?"}

    Q2 -->|Yes| SFasIdP["Salesforce = Identity Provider\nSalesforce authenticates users"]
    Q2 -->|No| Q3{"Multiple systems, no\nclear IdP?"}
    Q3 -->|Yes| NewIdP["Recommend a dedicated IdP\n(Okta, Azure AD)\nSalesforce = SP"]
    Q3 -->|No| Evaluate["Evaluate on case-by-case\nbasis per system"]

    SFasSP --> Protocol1{"Which protocol?"}
    Protocol1 -->|"Web SSO only"| SAML1["SAML 2.0"]
    Protocol1 -->|"Web SSO + API"| OIDC1["OpenID Connect\n(Preferred for modern)"]
    Protocol1 -->|"Legacy system\nrequirement"| SAML2["SAML 2.0\n(Broader legacy support)"]

    SFasIdP --> Protocol2{"What needs\nauthentication?"}
    Protocol2 -->|"External web apps"| SAMLOIDC["SAML 2.0 or OIDC\n(via Connected Apps)"]
    Protocol2 -->|"Other SF orgs"| SAML3["SAML 2.0\n(Multi-org SSO)"]
    Protocol2 -->|"Customer portal"| Social["Social Sign-On\n+ SF authentication"]

    style SFasSP fill:#1565c0,color:#fff
    style SFasIdP fill:#2e7d32,color:#fff
    style NewIdP fill:#e65100,color:#fff

IdP Selection Criteria

Factor	Use Existing Corporate IdP	Use Salesforce as IdP	Recommend New IdP
Existing IdP in place	Yes	No	No
No existing IdP	No	If SF is user SOR	For enterprise needs
Multiple cloud apps	Yes	No	Yes
Customer portal only	Maybe	Yes	No
Regulatory compliance	Depends on IdP capabilities	If SF meets requirements	Dedicated IdP preferred
Total users > 100K	Yes (scalable IdP)	Evaluate SF limits	Yes

Decision 4: OAuth Flow Selection

When an integration or application needs API access to Salesforce, select the correct OAuth flow.

flowchart TD
    Start["Application needs\nSalesforce API access"] --> Q1{"Is there a\nhuman user involved?"}

    Q1 -->|Yes| Q2{"What type of\napplication?"}
    Q1 -->|No| Q5{"Server-to-server\nintegration"}

    Q2 -->|"Web app with\nbackend server"| AuthCode["Authorization Code\n(+ PKCE recommended)"]
    Q2 -->|"Mobile app"| AuthCodePKCE["Authorization Code + PKCE\n(Required)"]
    Q2 -->|"Single Page App"| AuthCodePKCE2["Authorization Code + PKCE\n(Required)"]
    Q2 -->|"CLI / IoT device"| Device["Device Flow"]

    Q5 -->|"Has certificate\n(mTLS capable)"| JWT["JWT Bearer\n(Preferred for S2S)"]
    Q5 -->|"Has client secret\nonly"| ClientCred["Client Credentials\n(Spring '23+)"]
    Q5 -->|"Has SAML\nassertion"| SAMLBearer["SAML Bearer\n(Bridge scenario)"]

    AuthCode --> ConnectedApp["Configure Connected App"]
    AuthCodePKCE --> ConnectedApp
    AuthCodePKCE2 --> ConnectedApp
    Device --> ConnectedApp
    JWT --> ConnectedApp
    ClientCred --> ConnectedApp
    SAMLBearer --> ConnectedApp

    style AuthCode fill:#2e7d32,color:#fff
    style AuthCodePKCE fill:#2e7d32,color:#fff
    style AuthCodePKCE2 fill:#2e7d32,color:#fff
    style JWT fill:#1565c0,color:#fff
    style ClientCred fill:#1565c0,color:#fff
    style SAMLBearer fill:#e65100,color:#fff
    style Device fill:#4a148c,color:#fff

OAuth Flow Security Comparison

Flow	Secret Exposure Risk	Token Lifetime	Refresh Token	MFA Compatible
Authorization Code	Low (server-side secret)	Short (configurable)	Yes	Yes
Auth Code + PKCE	Very Low (no secret)	Short	Yes	Yes
JWT Bearer	Low (certificate-based)	Short	No	N/A (no user)
Client Credentials	Medium (secret required)	Short	No	N/A (no user)
SAML Bearer	Low (assertion-based)	Short	No	Via SAML IdP
Device	Medium (polling period)	Short	Yes	Yes

Decision 5: Encryption Strategy

Determine what to encrypt and how, based on regulatory requirements and business needs.

flowchart TD
    Start["Does the scenario mention\nregulatory compliance?"] -->|"Yes (HIPAA, PCI,\nGDPR, SOX)"| Analyze["Identify regulated\ndata fields"]
    Start -->|No| Q1{"Does the customer\nrequire 'encryption at rest'\nexplicitly?"}
    Q1 -->|Yes| Analyze
    Q1 -->|No| Standard["Standard Salesforce encryption\nis sufficient\n(All data encrypted at rest)"]

    Analyze --> FieldLoop["For each regulated field:"]
    FieldLoop --> Q2{"Does the field need\nto be searchable?"}
    Q2 -->|Yes| Det["Deterministic encryption"]
    Q2 -->|No| Prob["Probabilistic encryption"]

    Det --> Q3{"Does existing code\nuse LIKE, ORDER BY,\nor aggregates on this field?"}
    Q3 -->|Yes| Refactor["Refactor queries\nor accept limitation"]
    Q3 -->|No| DetOK["Deterministic is safe"]

    Prob --> Impact["Verify: no reports,\nlist views, or sorts\non this field"]

    Det --> KeyMgmt
    Prob --> KeyMgmt

    KeyMgmt{"Key management\nrequirement?"} -->|"Customer controls keys"| BYOK["BYOK"]
    KeyMgmt -->|"Maximum control\n(key never stored in SF)"| Cache["Cache-Only Keys"]
    KeyMgmt -->|"SF manages keys"| SFManaged["Salesforce-Managed Keys"]

    style Standard fill:#2e7d32,color:#fff
    style Det fill:#1565c0,color:#fff
    style Prob fill:#4a148c,color:#fff
    style BYOK fill:#e65100,color:#fff
    style Cache fill:#c62828,color:#fff

Encryption Decision Matrix

Data Type	Encrypt?	Scheme	Rationale
SSN / Tax ID	Yes	Deterministic	Searchable for matching; regulatory requirement
Credit card numbers	Yes	Probabilistic (or don’t store)	PCI-DSS; avoid storing if possible
Health records	Yes	Probabilistic	HIPAA; rarely need to search within
Email address	Maybe	Deterministic if encrypted	Often needed for search; weigh risk vs functionality
Phone number	Maybe	Deterministic if encrypted	Similar to email
Financial amounts	Rarely	Consider impact	Breaks aggregation, reporting
Free-text notes	If regulated	Probabilistic	Cannot search encrypted notes
Addresses	If regulated	Deterministic	May need for matching/dedup

Decision 6: Permission Model Architecture

Design the permission model for the scenario.

flowchart TD
    Start["How many distinct\naccess patterns exist?"] --> Q1{"More than 3-4\ndistinct patterns?"}

    Q1 -->|"Yes (5+)"| MinAccess["Minimum Access Profile\n+ Permission Set Groups"]
    Q1 -->|"No (2-3)"| Q2{"Will the org grow\nsignificantly?"}
    Q2 -->|Yes| MinAccess
    Q2 -->|No| Q3{"Are the patterns\nvery distinct?"}
    Q3 -->|Yes| FewProfiles["2-3 Custom Profiles\n+ Permission Sets for variations"]
    Q3 -->|No| MinAccess

    MinAccess --> Design1["1. Create Minimum Access Profile\n2. Create atomic Permission Sets\n3. Bundle into Permission Set Groups\n4. Use Muting PS for exceptions"]

    FewProfiles --> Design2["1. Create custom profiles per pattern\n2. Use Permission Sets for variations\n3. Plan migration to PSG model"]

    Design1 --> Validate["Validate:\n- Each PSG maps to a business role\n- PS are reusable across groups\n- Muting handles exceptions\n- No duplicate permissions"]

    Design2 --> Validate

    style MinAccess fill:#2e7d32,color:#fff
    style FewProfiles fill:#1565c0,color:#fff

Decision 7: Portal Security Architecture

Design security for external-facing scenarios.

flowchart TD
    Start["Scenario has\nexternal users"] --> Q1{"What type of\nexternal users?"}

    Q1 -->|"Customers (self-service)"| Q2{"Volume?"}
    Q1 -->|"Partners (collaborate)"| Partner["Partner Community License\n+ Partner Role Hierarchy"]
    Q1 -->|"Both"| Both["Separate license types\n+ Separate community or\nsame community with\nseparate pages"]
    Q1 -->|"Anonymous (public site)"| Guest["Guest User\n(Maximum lockdown)"]

    Q2 -->|"< 10K users"| CCPLUS["Customer Community Plus\n(Role hierarchy + reporting)"]
    Q2 -->|"> 10K users"| Q3{"Need reporting\nor role hierarchy?"}
    Q3 -->|Yes| CCPLUS2["Customer Community Plus\n(Accept higher cost)"]
    Q3 -->|No| CC["Customer Community\n(HVCP - optimized for scale)"]

    CC --> SharingSet["Configure Sharing Sets\nfor record access"]
    CCPLUS --> PortalRoles["Configure Portal\nRole Hierarchy"]
    Partner --> PartnerRoles["Configure Partner\nRole Hierarchy"]
    Guest --> GuestLockdown["Lock down Guest Profile:\n- Minimum object access\n- Criteria-based sharing only\n- No API access\n- Audit quarterly"]

    style Guest fill:#c62828,color:#fff
    style GuestLockdown fill:#c62828,color:#fff
    style CC fill:#2e7d32,color:#fff
    style CCPLUS fill:#1565c0,color:#fff
    style Partner fill:#e65100,color:#fff

Quick Reference: Security Decision Checklist

Use this checklist for every CTA scenario to ensure complete security coverage:

#	Decision	Key Question	Reference
1	OWD per object	Who is the most restrictive user?	[[02-security/sharing-model
2	External OWD	Are there external users? Set separately	[[02-security/portal-security
3	Role hierarchy	Data access pattern, not org chart?	[[02-security/sharing-model
4	Sharing rules	What access gaps remain after hierarchy?	[[02-security/sharing-model
5	Profile/Permission model	Minimum access + Permission Set Groups?	[[02-security/field-object-security
6	FLS per profile/PS	Which fields do each user type need?	[[02-security/field-object-security
7	Identity/SSO	Existing IdP? SF as SP or IdP?	[[02-security/identity-sso
8	OAuth flows	Which flows for which integrations?	[[02-security/identity-sso
9	MFA	Where is MFA enforced?	[[02-security/identity-sso
10	Portal security	License type, External OWD, guest user?	[[02-security/portal-security
11	Encryption	Regulatory requirement? What fields?	[[02-security/shield-encryption
12	Apex security	with sharing? CRUD/FLS enforced?	[[02-security/programmatic-security

Sources

• Salesforce Architects: Security Decision Guide
• Salesforce Architects: Identity Decision Guide
• Salesforce Architects: Data Access Decision Guide
• Salesforce Architects: Data Protection Decision Guide
• Salesforce Help: Sharing Architecture