Security Decision Guides

Use these decision flowcharts 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

Sharing model selection starts with a per-object OWD decision, not an org-wide choice. For each object, identify the single most restrictive user — the one who must see the fewest records — and set OWD accordingly. Once OWD is set, fill access gaps using the sharing stack in order: role hierarchy for upward management visibility, ownership-based sharing rules for predictable owner-pattern access, criteria-based sharing rules for field-value patterns, teams for collaborative record-specific access, and Apex managed sharing for runtime-calculated access that declarative mechanisms cannot express. A common mistake is reaching for Apex sharing too early, which adds maintenance burden for patterns that criteria-based rules could handle with zero code. Present your OWD and hierarchy choices first, then justify each sharing rule as closing a specific gap.

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

Figure 1. OWD selection must be performed per object, not once for the whole org. The presence of even a single user who must not see all records of an object forces Private OWD, and then external OWD and hierarchy settings are configured as follow-on decisions.

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.

Figure 2. Sharing mechanism selection follows the nature of the access pattern. Predictable, field-value-based patterns suit criteria sharing rules; unpredictable or per-record collaborative access suits teams; complex runtime logic requires Apex managed sharing.

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	50 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

Identity approach selection starts with whether a corporate IdP already exists. If it does, Salesforce is always the Service Provider and the corporate IdP authenticates users via SAML 2.0 or OIDC. If no corporate IdP exists and Salesforce is the system of record for users (typically in customer portal scenarios), Salesforce becomes the IdP. In post-M&A or multi-business-unit scenarios with multiple IdPs, recommend a centralized identity broker such as Okta or Azure AD, with Login Discovery routing users to the correct IdP by email domain. The wrong pattern is configuring SAML SSO directly to two competing IdPs without a broker — this creates user routing ambiguity and requires manual fallback procedures. Always address the SSO breakglass scenario: a designated admin account that bypasses SSO, reachable when the IdP is down.

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

Figure 3. The first identity architecture decision is whether Salesforce acts as an SP or IdP, which is almost always SP when a corporate IdP exists. Protocol selection follows: SAML for pure web SSO with legacy systems, OIDC when modern web or mobile apps also need API access.

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.

Figure 4. All OAuth flows terminate at a Connected App configuration, but the path to get there differs. Server-to-server integrations with a certificate should use JWT Bearer, as it is the most secure option and does not expose credentials in requests.

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

Encryption strategy selection follows a three-level decision cascade. First, establish whether regulatory compliance mandates encryption (HIPAA, PCI-DSS, GDPR, SOX). If yes, identify the regulated fields. Second, determine whether the org is on Hyperforce — if it is and the requirement is broad data-at-rest protection, Database Encryption has zero functional impact and is preferred over field-level encryption. If field-selective control or Cache-Only Key management is needed, Shield Platform Encryption is the option regardless of infrastructure. Third, for each field to be encrypted with Shield FLE, evaluate whether it must be searchable or filterable. If yes, use deterministic encryption and explicitly address the LIKE/aggregate trade-offs with whoever owns the reporting requirements. If no, use probabilistic for maximum protection. Always perform a query impact analysis before enabling encryption on any field used in existing reports, list views, or SOQL filters.

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

Figure 5. Encryption decisions cascade: regulatory requirement drives whether to encrypt at all, searchability requirements drive scheme selection, and existing query patterns determine whether refactoring is needed before encryption can be safely enabled.

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

Figure 6. The Minimum Access Profile pattern is the default recommendation for any org with growth potential or more than three distinct access patterns. Even when starting with a few custom profiles, the design should plan for migration to the PSG model as the org scales.

Decision 7: Portal Security Architecture

Figure 7. Portal license selection at scale hinges on whether reporting and role hierarchy are genuinely needed. Customer Community (HVCP) with Sharing Sets handles millions of users more efficiently than Community Plus, but surrenders role-based reporting. This trade-off must be explicitly justified.

Quick Reference: Security Decision Checklist

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

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