Risk Management

The review board evaluates whether candidates can identify risks in a scenario, assess their probability and impact, and propose concrete mitigation strategies. Candidates who only address risks when prompted score lower than those who weave risk awareness throughout their architecture.

Risk Categories

Technical Risks

Risk	Description	Likelihood	Impact
Governor limit exceedance	Automation or integration hits platform limits	Medium	High
Performance degradation	Slow queries, page load times with data growth	High	High
Integration failure	External system downtime, API changes	Medium	High
Data migration errors	Incomplete, duplicated, or corrupted data	Medium	High
Security vulnerability	FLS bypass, sharing model gaps, injection	Low	Critical
Technical debt accumulation	Shortcuts that compound over time	High	Medium
Platform upgrade impact	Salesforce releases breaking existing functionality	Low	Medium

Organizational Risks

Risk	Description	Likelihood	Impact
Key person dependency	Single expert with no backup	Medium	High
Stakeholder misalignment	Business units with conflicting requirements	Medium	High
Change resistance	Users refusing to adopt new system	Medium	High
Scope creep	Requirements expanding beyond original scope	High	Medium
Resource availability	Team members pulled to other projects	Medium	Medium
Vendor dependency	AppExchange vendor acquired or sunset	Low	High
Knowledge gaps	Team lacks skills for chosen technology	Medium	Medium

Data Risks

Risk	Description	Likelihood	Impact
Data quality issues	Dirty data causing automation failures	High	Medium
Data volume growth	Unexpected data growth exceeding storage	Medium	High
Data loss	Accidental deletion, failed migration	Low	Critical
PII exposure	Sensitive data visible to unauthorized users	Low	Critical
Data silos	Duplicate data across systems with no sync	Medium	Medium

Integration Risks

Risk	Description	Likelihood	Impact
API version deprecation	External system deprecates API version	Medium	High
Message ordering	Events processed out of order	Medium	Medium
Data inconsistency	Sync failures creating divergent data	Medium	High
Rate limiting	External system throttles API calls	Medium	Medium
Authentication expiry	Tokens, certificates, or credentials expire	Medium	High

Probability x Impact Matrix

This matrix helps prioritize risks and determine which require active mitigation vs monitoring.

Figure 1. Performance degradation sits in the top-right quadrant (high probability and high impact), making it the single risk most deserving of proactive architectural investment. Security vulnerabilities land in the contingency quadrant: catastrophic if they occur, but low probability with proper controls in place.

Response Strategies by Quadrant

Quadrant	Strategy	Action
High Probability, High Impact	Mitigate Actively	Invest in prevention. Design architecture to avoid this risk. Budget time and resources.
Low Probability, High Impact	Contingency Plan	Have a documented response plan. Do not invest in prevention, but be prepared to respond.
High Probability, Low Impact	Monitor Closely	Accept the risk but track it. Set thresholds for escalation.
Low Probability, Low Impact	Accept and Monitor	Log the risk but do not invest resources. Review periodically.

Risk Response Flow

Once a risk is identified, assess it, classify it, and assign a response strategy. This flow ensures consistent handling across the project.

Figure 2. Risks with changing probability must re-enter the scoring step rather than being reassigned a response directly. A risk that was medium last sprint may now be critical. CAB escalation on materialization ensures deployment decisions account for the active incident.

Risk Register Template

A risk register tracks risks throughout the project. In a CTA scenario, reference the risk register as part of governance.

Field	Description	Example
Risk ID	Unique identifier	RISK-001
Category	Technical, Organizational, Data, Integration	Technical
Description	What could go wrong	”SOQL queries on Account may degrade with 10M+ records”
Probability	High, Medium, Low	High
Impact	Critical, High, Medium, Low	High
Risk Score	Probability x Impact (numeric)	9 (3 x 3)
Mitigation Strategy	What you will do to reduce probability or impact	”Implement skinny tables, selective indexes, archive records >5 years”
Contingency Plan	What you will do if the risk materializes	”Implement async processing, increase timeout, add caching layer”
Owner	Who is responsible for monitoring this risk	Technical Architect
Status	Open, Mitigating, Closed, Materialized	Mitigating
Review Date	When to next review this risk	Every sprint retrospective

Common CTA Scenario Risks and Mitigations

Scenario: Large Data Volume Implementation

Risk	Mitigation	Contingency
Query performance degradation	Skinny tables, custom indexes, selective filters	Implement caching, async processing
Storage limit exceedance	Data archival strategy, Big Objects	Purchase additional storage, aggressive archival
Data migration timeout	Batch processing, parallel loads, off-hours	Phased migration over multiple weekends
Report performance	Summary reporting objects, async reports	CRM Analytics for complex reporting

Scenario: Multi-Cloud Implementation

Risk	Mitigation	Contingency
Cross-cloud data inconsistency	Event-driven sync, conflict resolution rules	Manual reconciliation process, data steward role
License cost overrun	License optimization analysis, feature mapping	Renegotiate license mix, consolidate users
Integration complexity	Middleware layer, standardized patterns	Simplify to point-to-point for critical paths
User adoption challenges	Role-specific training, change champions	Phased rollout, parallel running

Scenario: AppExchange-Heavy Architecture

Risk	Mitigation	Contingency
Vendor acquisition/sunset	Exit strategy for each package, data portability	Build replacement with custom code
Governor limit conflicts	Limit budget allocation per package, monitoring	Remove lowest-value package, optimize custom code
Upgrade breaking changes	Regression test suite, staging validation	Version lock, coordinate with vendor
Total cost escalation	TCO model with annual review triggers	Renegotiate or replace with custom build

Scenario: Global/Multi-Org Rollout

Risk	Mitigation	Contingency
Regulatory non-compliance	Per-region compliance mapping, Shield encryption	Region-specific org isolation
Data residency violation	Hyperforce region selection, data masking	Separate orgs per jurisdiction
Timezone/language issues	Locale-aware development, i18n testing	Region-specific customization layer
Coordinated deployment complexity	Release train model, feature flags	Staggered regional releases

Risk Communication

How to Present Risks to the Review Board

Present risks as a structured, proactive analysis, not as an afterthought.

Structure the discussion as:

1. Identify the top 3-5 risks specific to the scenario (not generic risks)
2. For each risk, state:
   • What the risk is and why it exists in this specific scenario
   • How likely it is and how severe the impact would be
   • What the architecture does to prevent it
   • What the fallback plan is if prevention fails
3. Connect risks to architecture decisions: “I chose middleware over point-to-point integration partly because it reduces the integration failure risk by providing retry logic and monitoring.”

CTA Risk Presentation Pattern

“The top risk I see in this scenario is [risk]. It’s likely because [reason specific to scenario]. If it materializes, the impact is [consequence]. My architecture mitigates this by [architectural decision]. As a contingency, [fallback plan].”

Risk Reporting

Audience	Detail Level	Format	Frequency
Steering Committee	High-level, top 5 risks	Dashboard, RAG status	Monthly
Project Team	Detailed, all active risks	Risk register	Sprint review
Technical Team	Technical risks with actions	Technical risk log	Weekly standup
CAB	Deployment-specific risks	Change request form	Per deployment

Risk Monitoring

Early Warning Indicators

Risk Area	What to Monitor	Alert Threshold
Governor limits	Apex CPU time, SOQL count per transaction	>70% of limit
Performance	Page load time, query execution time	>3 second page load
Storage	Data storage usage, file storage usage	>80% capacity
Integration	Error rate, response time, queue depth	>5% error rate
API limits	Daily API call consumption	>70% of daily limit
User adoption	Login frequency, feature usage	<50% expected adoption

Related Topics

• Governance Model: Risk governance structures (CAB, ARB)
• Testing Strategy: Testing as risk mitigation
• CI/CD & Deployment: Deployment risks and rollback strategies
• Environment Strategy: Environment risks and data masking
• Decision Guides: Risk-informed decision flowcharts
• Review Board Presentation: Presenting risks at the CTA board

Sources

• Salesforce Architects: Risk Management for Implementations
• PMBOK Guide: Risk Management Knowledge Area
• Salesforce Help: Governor Limits
• Salesforce Architects: Well-Architected Framework - Trusted Principle
• CTA Study Groups: Community-sourced risk patterns from CTA exam scenarios