Solution 01: Apex Wealth Partners

AI-Generated Content — Use for Reference Only

This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.

Solution Context

Heavy domains: D1 System Architecture, D2 Security, D3 Data, D5 Integration | Difficulty: Advanced Time budget: 180 minutes | Key frameworks: 9 Essential Artifacts, Five-Finger Method

Attempt the Case Study First

If you have not yet worked through the case study paper, stop here. Set a 180-minute timer and build your own solution before reading this one.

Assumptions

1. Single org with Financial Services Cloud. The 8,000 overlapping clients confirm data co-location is the right pattern. A second org creates permanent integration overhead and makes the unified client view architecturally impossible without Salesforce Connect or middleware.
2. Salesforce Shield required. SOX audit trails, FINRA 7-year retention, SEC immutable records — Shield Platform Encryption + Field Audit Trail + Event Monitoring cover all three.
3. Experience Cloud for client portal. Inherits the sharing model, supports MFA, integrates with DocuSign, and displays portfolio data natively.
4. MuleSoft as integration middleware. Six external systems, mixed protocols (REST, SOAP, SFTP, webhooks), 2M-record nightly volume justify centralized middleware with protocol mediation, error handling, and monitoring.
5. Okta as single identity provider. Federated SSO for employees, separate Experience Cloud identity for clients, satisfying the authentication separation requirement.

Key Architectural Decisions

Decision 1: Single Org vs. Multi-Org (HEAVY — D1)

Single org because the unified client view is the core business requirement and 8,000 overlapping clients make data co-location essential.

Single org advantages: one Account/Contact per client with both wealth and banking financial accounts visible; household rollups operate on native data; sharing model enforces Chinese wall within one org using Restriction Rules; single compliance query surface; one license pool and deployment pipeline.

Multi-org rejected because: (a) 8,000 overlapping clients would need bidirectional sync or external objects, introducing latency and breaking real-time aggregation; (b) compliance needs a single query surface spanning both divisions; (c) the 10-person CoE cannot sustain two orgs operationally.

Judge Signal

Lead with the business requirement (unified view + 8,000 overlapping clients) then explain how the Chinese wall is enforced within a single org. Judges want to see that you considered multi-org seriously and rejected it with specific reasoning.

Decision 2: Information Barrier / Chinese Wall (HEAVY — D2)

Restriction Rules + custom MNPI flag + Permission Set Groups enforce the Chinese wall at the record-level, operating below the sharing model.

How it works:

• A custom Has_MNPI__c checkbox on Account is set by the banking commercial lending team when MNPI exists for a client
• A Restriction Rule on Account hides records where Has_MNPI__c = true from all users except those with the MNPI_Authorized_Viewer Permission Set
• Only designated compliance officers and the commercial lending team receive this Permission Set
• Wealth advisors cannot see MNPI-flagged commercial banking data even with a legitimate personal account relationship
• The restriction applies after the sharing model, narrowing access rather than broadening it

Apex Managed Sharing rejected because Apex sharing grants access — it cannot remove access the sharing model already provides. Restriction Rules are the correct mechanism for narrowing access below what sharing grants.

Decision 3: Sharing Model Architecture (HEAVY — D2)

Private OWD on Account and Financial Account with role hierarchy, team sharing, and territory-based rules.

Object	OWD	Access Mechanism
Account (Person Account)	Private	Advisor ownership + Team shares + Territory rules
Financial Account	Controlled by Parent	Inherits from Account
Financial Holding	Controlled by Parent	Inherits from Financial Account
Opportunity	Private	Advisor ownership
Case (Banking Service)	Private	Branch ownership + queue assignment
Task / Event	Controlled by Parent	Inherits from related Account

Advisor teams: FSC’s standard Relationship Group object groups advisors into teams. Account Team Members (AccountTeamMember) grant team members access to all accounts where any team member is the owner.

Banking staff isolation: Banking staff are in a separate branch of the role hierarchy with no upward access path to wealth management data. They see only Account records with an associated Banking Financial Account where the branch territory matches their assignment.

Compliance read-only: A Permission Set Group grants compliance users View All on Account, Financial Account, Activity, and Case — but explicitly excludes all Edit and Delete permissions.

Artifact 1: System Landscape Diagram

flowchart TB
    subgraph Legend["Legend"]
        L1["🟢 NEW system"]
        L2["⚪ KEEPING as-is"]
        L3["🔴 RETIRING"]
        L4["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Salesforce Single Org — FSC"]
        WM["Wealth Advisor Console"]
        BK["Banking Service Console"]
        CO["Compliance Dashboard"]
        EC["Experience Cloud Portal"]
        SH["Shield — Encryption + FAT + Event Mon"]
    end

    subgraph MW["MuleSoft Anypoint"]
        APIGW["API Gateway"]
        BATCH["Batch Processing"]
    end

    subgraph EXT["External Systems"]
        SCH["Schwab"]
        PER["Pershing"]
        ORI["Orion"]
        FIS["FIS Horizon"]
        SMA["Smarsh"]
        DOC["DocuSign"]
        SP["SharePoint"]
    end

    subgraph ID["Identity"]
        OKTA["Okta"]
        ECID["EC Identity"]
    end

    subgraph RET["Retiring"]
        DYN["Dynamics 365 CRM"]
    end

    SF <-->|"REST / Bulk API"| APIGW
    APIGW --- BATCH
    SCH -->|"SFTP nightly 600K"| BATCH
    PER -->|"File nightly 200K"| BATCH
    ORI <-->|"REST bidirectional 15-min"| APIGW
    FIS <-->|"SOAP real-time inquiry"| APIGW
    SMA <-->|"REST near-real-time"| APIGW
    DOC <-->|"REST webhook on completion"| APIGW
    SP -->|"REST on-demand retrieval"| APIGW
    OKTA -->|"SAML 2.0 SSO"| SF
    ECID -->|"MFA + password"| EC
    DYN -.->|"Migrating to SF"| SF

    classDef newSystem fill:#d4edda,stroke:#28a745,color:#000
    classDef keepSystem fill:#f8f9fa,stroke:#6c757d,color:#000
    classDef retireSystem fill:#f8d7da,stroke:#dc3545,color:#000,stroke-dasharray:5 5
    classDef integrationLayer fill:#fff3cd,stroke:#fd7e14,color:#000
    classDef sfSystem fill:#cce5ff,stroke:#0d6efd,color:#000

    class SF,WM,BK,CO,EC,SH sfSystem
    class MW,APIGW,BATCH integrationLayer
    class SCH,PER,ORI,FIS,SMA,DOC,SP keepSystem
    class OKTA,ECID keepSystem
    class DYN retireSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 retireSystem
    class L4 integrationLayer

Artifact 2: Data Model / ERD

erDiagram
    PERSON_ACCOUNT ||--o{ FINANCIAL_ACCOUNT : owns
    PERSON_ACCOUNT }o--|| HOUSEHOLD : member_of
    PERSON_ACCOUNT ||--o{ CASE : raises
    PERSON_ACCOUNT ||--o{ COMPLIANCE_REVIEW : subject_of

    HOUSEHOLD ||--o{ PERSON_ACCOUNT : contains

    FINANCIAL_ACCOUNT ||--o{ FINANCIAL_HOLDING : contains
    FINANCIAL_ACCOUNT_ROLE }o--|| FINANCIAL_ACCOUNT : on_account
    FINANCIAL_ACCOUNT_ROLE }o--|| CONTACT : advisor_role

    PERSON_ACCOUNT {
        string RecordType_WealthOrBanking
        boolean Has_MNPI__c
        string Risk_Profile__c
        currency Total_AUM__c
        currency Total_Deposits__c
    }

    HOUSEHOLD {
        currency Household_AUM__c
        string Service_Tier__c
    }

    FINANCIAL_ACCOUNT {
        string Type_Investment_Deposit_Loan
        string Custodian
        currency Balance
        date As_Of_Date
    }

    FINANCIAL_HOLDING {
        string Symbol
        decimal Quantity
        currency Market_Value
        currency Cost_Basis
    }

FSC Data Model

Uses FSC standard objects: Person Account, Account with RecordType = “Household” (NOT a separate object — members relate via AccountContactRelation), Financial Account, Financial Holding, Financial Account Role (links advisors to accounts, replacing “book of business” concept), and Account Team Members (advisor teams). Custom objects: Compliance_Review__c, Suitability_Check__c. The Has_MNPI__c field drives the Chinese wall Restriction Rule.

Artifact 3: Role Hierarchy

flowchart TD
    CEO --> CCO & VPWM & VPRB & COO & CTO

    CCO --> COMP["Compliance (View All Read Only)"]
    VPWM --> RD["Regional Directors"] --> TL["Team Leads"] --> FA["Advisors (600)"]
    VPRB --> BRM["Branch Regional Mgrs"] --> BM["Branch Mgrs (30)"] --> TELLER["Branch Staff (400)"]
    COO --> OPS["Operations (200)"]
    CTO --> IT["IT / CoE"]

Hierarchy Rationale

Wealth and banking are separate branches — no cross-branch inheritance. Compliance sits as a peer branch with read-only Permission Set Group grants, not through hierarchy, preventing unintended upward access paths. IT/CoE staff should use System Administrator profile (bypasses OWD) rather than hierarchy-based access.

Artifact 4: Integration Architecture

flowchart LR
    subgraph Legend["Legend"]
        L1["🟢 NEW"]
        L2["⚪ KEEPING"]
        L3["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Salesforce FSC"]
        FA_OBJ["Financial Account / Holding"]
        ACCT["Person Account"]
        PE["Platform Events"]
    end

    subgraph MULE["MuleSoft Anypoint"]
        API_GW["API Gateway"]
        BATCH["Batch + Reconciliation"]
        RT["Real-Time APIs"]
    end

    subgraph CUST["Custodians"]
        SCH["Schwab"]
        PER["Pershing"]
    end

    subgraph SVC["Service Providers"]
        ORI["Orion"]
        FIS["FIS Horizon"]
        SMA["Smarsh"]
        DOC["DocuSign"]
        SP["SharePoint"]
    end

    SCH -->|"SFTP nightly 600K records"| BATCH
    PER -->|"Proprietary file nightly 200K"| BATCH
    ORI <-->|"REST bidirectional every 15 min"| RT
    FIS <-->|"SOAP real-time per-query"| RT
    SMA <-->|"REST near-real-time 5K/day"| RT
    DOC <-->|"REST webhook on completion"| RT
    SP -->|"REST on-demand retrieval"| RT

    BATCH -->|"Bulk API staged load"| API_GW
    API_GW -->|"Upsert"| FA_OBJ
    RT <-->|"REST API"| API_GW
    API_GW <-->|"REST API"| ACCT
    PE <-->|"Pub/Sub API"| RT

    classDef newSystem fill:#d4edda,stroke:#28a745,color:#000
    classDef keepSystem fill:#f8f9fa,stroke:#6c757d,color:#000
    classDef integrationLayer fill:#fff3cd,stroke:#fd7e14,color:#000
    classDef sfSystem fill:#cce5ff,stroke:#0d6efd,color:#000

    class SF,FA_OBJ,ACCT,PE sfSystem
    class MULE,API_GW,BATCH,RT integrationLayer
    class SCH,PER,ORI,FIS,SMA,DOC,SP keepSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 integrationLayer

Integration pattern summary:

System	Pattern	Protocol	Frequency	Volume	Direction
Schwab	Batch ETL	SFTP + CSV	Nightly	600K records	Inbound
Pershing	Batch ETL + Transform	File + Proprietary	Nightly	200K records	Inbound
Orion	Bidirectional sync	REST API	15-min + Nightly	50K records	Bidirectional
FIS Horizon	Request-Reply	SOAP	Real-time on demand	Per-query	Bidirectional
Smarsh	Event-driven	REST API	Near-real-time	~5K comms/day	Bidirectional
DocuSign	Event-driven (webhook)	REST + Webhook	On completion	~200 docs/day	Bidirectional
SharePoint	On-demand retrieval	REST API	User-triggered	As needed	Inbound

Key patterns: Custodian batch loads use a staging object for idempotent chunk-based processing with reconciliation before promotion to Financial Holding. If a chunk fails, MuleSoft retries 3x, logs to dead letter queue, and continues remaining chunks — partial failure does not corrupt loaded data. FIS queries are synchronous callouts through MuleSoft — no transaction data stored in Salesforce (FIS is SOR, 400K txn/day exceeds storage economics). Orion conflict resolution: Salesforce wins for demographics, Orion wins for performance/billing. Future-proofing: adding eMoney Advisor or a reporting portal replacement is a new MuleSoft connector, not a rearchitecture (API-led connectivity: system APIs, process APIs, experience APIs).

Artifact 5: Identity and SSO Flow

sequenceDiagram
    participant EMP as Employee
    participant OKTA as Okta
    participant SF as Salesforce FSC
    participant CLIENT as Client
    participant ECID as EC Identity
    participant PORTAL as Portal

    EMP->>OKTA: Login (username + MFA)
    OKTA->>SF: SAML 2.0 Assertion + JIT Provisioning
    SF->>EMP: Session (role + permissions)

    CLIENT->>ECID: Login (password + MFA + device recognition)
    ECID->>PORTAL: Authenticated session (external user license)
    PORTAL->>CLIENT: Portfolio view (scoped to own data)

Identity architecture decisions:

• Employees: Okta SAML 2.0 SSO with MFA enforcement. JIT provisioning creates/updates Salesforce User records on login using SAML assertion attributes (role, profile, permission sets from Okta group membership). Single identity source after Azure AD migration completes. 8-hour session timeout, re-authentication for sensitive operations.
• Clients: Experience Cloud native identity with self-registration + email verification. MFA required at every login. Customer Community Plus licenses for portal access (supports sharing model inheritance needed for portfolio views).
• Separation: Employee and client identities are completely independent. Clients never touch Okta. Employees never use Experience Cloud credentials.

JIT Provisioning Required

Without JIT provisioning (or pre-provisioned users), Salesforce rejects SAML assertions for users without a User record. Configure JIT in the Okta SAML Connected App and map Okta attributes to Salesforce User fields.

Artifact 6: Data Migration Strategy

Phase 1 — Banking Migration (Dynamics to FSC):

Step	Activity	Tool	Volume
1	Extract from Dynamics 365 via API	MuleSoft batch	60K accounts
2	Transform to FSC Person Account model	MuleSoft DataWeave	60K records
3	Duplicate detection against wealth org	Duplicate Rules + fuzzy match	60K vs 120K
4	Merge overlapping records (survivorship)	Data Loader + custom Apex	8K records
5	Load banking financial accounts + cases	Data Loader	60K accounts, 200K cases
6	Validate counts, relationships, completeness	Automated test scripts	All

Survivorship rules:

Field Category	Source of Truth	Rationale
Investment (AUM, risk profile, suitability)	Wealth org	Advisory relationship is authoritative
Banking (deposits, loans, branch)	Dynamics 365	Banking system is authoritative
Demographics (address, phone, email)	Most recently updated	Fresher data wins
Compliance (KYC, sanctions)	Both — retain stricter status	Regulatory conservatism

Phase 2 — Wealth Org Cleanup: Archive 15K orphaned accounts, enrich 22K contacts missing email, reassign 8.5K departed-advisor records, consolidate redundant custom fields, refactor 47 triggers into trigger framework with unit tests.

Historical activity: Dynamics activities (3 years) extracted, transformed to Task/Event with original date in Original_Activity_Date__c (Salesforce does not allow setting CreatedDate without special org permission). Existing Salesforce activities (5 years) remain in-org — reassign activities for departed-advisor records.

Artifact 7: Governance Framework

Center of Excellence:

Role	Count	Responsibility
CoE Lead / Release Manager	1	Release coordination, change management, vendor oversight
Salesforce Administrators	4	Configuration, user management, declarative automation (2 wealth, 2 banking)
Salesforce Developers	3	Apex, LWC, integration development, code review
Business Analysts	2	Requirements, UAT coordination, training documentation
Compliance Liaison (part-time)	1	CCO delegate for change approval on security/compliance changes

Change governance:

Change Type	Approval Required	Deployment Path
Security / access control	CCO sign-off	Dev -> QA -> Staging (CCO review) -> Prod
Standard configuration	CoE Lead approval	Dev -> QA -> Staging -> Prod
Emergency hotfixes	CTO + CoE Lead (post-hoc CCO review)	Hotfix sandbox -> Prod (with rollback plan)

SOX controls: Segregation of duties (no single person develops and deploys), quarterly access certification (CoE generates reports, business owners certify), change documentation with business justification, risk assessment, and rollback plan for every deployment.

Artifact 8: Environment Strategy

Environment	Type	Purpose
DEV-WEALTH / DEV-BANKING / DEV-INT	Developer Pro	Feature development (metadata only from Prod)
QA	Partial Copy	Functional and regression testing
STAGING	Full Copy	UAT, compliance review, performance testing
HOTFIX	Developer Pro	Emergency fixes only

Sandbox Refresh

All sandboxes refresh FROM Production only — there is no sandbox-to-sandbox refresh. Developer Pro sandboxes copy metadata only (no production data).

Data masking: All non-production environments use Salesforce Data Mask to anonymize client PII, financial account numbers, and portfolio data. Compliance-validated test data sets maintained separately for UAT scenarios requiring realistic data patterns.

Deployment pipeline: Salesforce DX with source-driven development. GitHub for version control. GitHub Actions for CI/CD: validate, test (minimum 85% Apex coverage enforced), deploy. CCO approval gate in STAGING for compliance-flagged changes. Every deployment includes a change record with business justification and rollback plan.

Artifact 9: Phased Delivery Roadmap

gantt
    title 24-Month Delivery Roadmap
    dateFormat YYYY-MM-DD
    axisFormat %b %Y

    section Phase 0 — Foundation
    Org cleanup + FSC data model    :p0a, 2025-10-01, 60d
    MuleSoft + CI/CD + Okta SSO     :p0b, 2025-10-15, 45d

    section Phase 1 — Wealth Enhancement
    Sharing model + Chinese wall     :p1a, 2025-12-01, 45d
    Advisor console + integrations   :p1b, 2026-01-01, 75d
    Wealth UAT + Go-Live             :p1c, 2026-03-01, 30d

    section Phase 2 — Banking Onboarding
    Data migration + FIS integration :p2a, 2026-03-01, 75d
    Banking console + referrals      :p2b, 2026-04-01, 60d
    Banking UAT + Go-Live            :p2c, 2026-06-01, 30d

    section Phase 3 — Client Portal
    Portal build + client identity   :p3a, 2026-07-01, 75d
    Portal UAT + Go-Live             :p3b, 2026-09-01, 30d

    section Phase 4 — Optimization
    Data cleanup + analytics         :p4a, 2026-10-01, 90d
    CoE knowledge transfer           :p4b, 2026-11-01, 90d
    Program Close                    :milestone, 2027-04-01, 0d

Phase rationale:

• Phase 0 (Foundation): Address org technical debt, establish FSC data model, stand up environments and CI/CD before any feature work begins. The existing Public Read/Write OWD, 85 custom objects, and untested triggers must be remediated before expansion.
• Phase 1 (Wealth Enhancement): Deliver value to existing division first — advisors get a better console, custodian integrations go through MuleSoft, sharing model is hardened with Chinese wall. This builds confidence before the more disruptive banking migration.
• Phase 2 (Banking Onboarding): Migrate banking data and staff before Dynamics 365 contract renewal (14-month deadline) and data center lease expiry (22 months). Banking staff retrained during this phase with union-compliant communication plan. If Phase 2 slips, mitigation options: accelerate data migration by running parallel with Phase 1, negotiate 3-month Dynamics extension, or migrate data first and have banking staff use standard Salesforce UI temporarily.
• Phase 3 (Client Portal): Launch only after both divisions are live and the unified data model is stable — the portal depends on complete household data across both divisions for accurate portfolio views.
• Phase 4 (Optimization): Clean up remaining technical debt, build analytics and reporting, train the CoE to full self-sufficiency (18-month target). Banking Dynamics admins cross-trained into Salesforce roles by this phase.

SharePoint document strategy: 1.2 TB exceeds practical Salesforce file storage limits. Use Salesforce Files Connect to surface SharePoint documents within client records without migrating content into Salesforce storage. During Phase 2, apply metadata tags (client ID, document type, branch) to enable search. Long-term document platform consolidation is outside the 24-month program scope.

Licensing approach: 600 advisors + wealth support get FSC licenses (upgrade from partial implementation). 400 banking staff get FSC licenses with banking-focused layouts. 150 compliance + 200 operations get standard Salesforce licenses with Permission Set Groups. Client portal uses Customer Community Plus licenses (supports MFA and sharing model inheritance). Shield (Platform Encryption, Event Monitoring, Field Audit Trail) is a required add-on for regulatory compliance. Recommend negotiating an enterprise agreement bundling FSC, Shield, Experience Cloud, and MuleSoft for volume discount — licensing is a significant portion of the $12M budget.

Managed compliance app: Keep the existing managed package through Phase 1 (it works today, replacing it adds scope). Evaluate in Phase 4 whether to build custom using FSC’s native Compliance objects + Shield, or migrate to a managed package with a stronger roadmap. Decision criteria: vendor contract timing, FINRA feature parity, and CoE capacity to maintain custom code.

Judge Signal

Be prepared to defend why banking comes before portal (data completeness), why Chinese wall is Phase 1 not Phase 0 (depends on role hierarchy and FSC data model), and what happens if Phase 2 slips past Dynamics renewal (negotiate short-term extension or accelerate migration-only workstream).

Identity & SSO Flow

sequenceDiagram
    participant EmpBrowser as Employee Browser
    participant Okta as Okta (Enterprise IdP)
    participant SF as Salesforce FSC
    participant ClientBrowser as Client Browser
    participant ECID as EC Identity
    participant Portal as Experience Cloud Portal
    participant MuleSoft as MuleSoft (Integration User)

    rect rgb(230, 240, 255)
    Note over EmpBrowser,SF: Internal Employee SSO (SAML 2.0)
    EmpBrowser->>Okta: Navigate to Salesforce (SP-initiated)
    Okta->>Okta: Authenticate (password + MFA push)
    Okta->>Okta: Evaluate Okta group membership
    Okta->>EmpBrowser: SAML 2.0 Assertion (Federation ID + attributes)
    EmpBrowser->>SF: POST Assertion to ACS URL
    SF->>SF: JIT Provisioning — create/update User<br/>(Profile, Permission Sets from SAML attributes)
    SF->>SF: Match Federation ID to User record
    SF->>EmpBrowser: Session established (8-hour timeout)
    end

    rect rgb(230, 255, 230)
    Note over ClientBrowser,Portal: Client Portal Authentication (EC Identity)
    ClientBrowser->>ECID: Self-registration or login
    ECID->>ECID: Verify email + password
    ECID->>ECID: Enforce MFA (SMS/TOTP) + device recognition
    ECID->>Portal: Authenticated session (Community Plus license)
    Portal->>Portal: Sharing model scopes data to client's own accounts
    Portal->>ClientBrowser: Portfolio view (own household only)
    end

    rect rgb(255, 245, 230)
    Note over MuleSoft,SF: System-to-System Integration Auth
    MuleSoft->>SF: OAuth 2.0 Client Credentials flow
    SF->>SF: Validate Connected App + scope
    SF->>MuleSoft: Access token (integration user context)
    MuleSoft->>SF: API calls with token (REST / Bulk / Pub/Sub)
    end

Identity architecture rationale:

• Okta SAML 2.0 for all 2,200 employees. Banking staff currently on Azure AD complete migration to Okta within 6 months (per paper constraint). JIT provisioning maps Okta group memberships to Salesforce Permission Set Groups — no manual provisioning after initial setup. 8-hour session timeout with re-authentication for sensitive operations (e.g., modifying client access, viewing MNPI-flagged records via Step-Up Authentication).
• Experience Cloud native identity for wealth clients. Self-registration with email verification, MFA at every login, and device fingerprinting. Customer Community Plus licenses support sharing model inheritance required for portfolio views scoped to the client’s household. No connection to Okta — client and employee identity paths are architecturally separated.
• MuleSoft integration authentication uses OAuth 2.0 Client Credentials flow via Named Credentials. A dedicated Connected App with scoped permissions runs under an integration user profile. No interactive service accounts — CISO requirement satisfied. Each external system connection (Schwab, Orion, FIS, Smarsh, DocuSign, SharePoint) has its own Named Credential with per-system OAuth client credentials.
• MFA enforcement: Okta enforces MFA for employees (push notification or hardware key for compliance officers handling MNPI data). Experience Cloud enforces MFA for clients. Integration users bypass MFA (machine-to-machine — no human login).

Integration Error Handling

Each integration has specific error handling tailored to its pattern, volume, and business criticality.

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
Schwab (SFTP nightly)	Batch ETL	MuleSoft retries file retrieval 3x at 15-min intervals; chunk-level retry (10K records per chunk) — failed chunks retry independently	Failed chunks written to MuleSoft DLQ with file name, chunk number, and error detail; DLQ reviewed daily by ops	MuleSoft Anypoint Monitoring dashboard; PagerDuty alert if load not complete by 6:00 AM EST; email to CoE on any DLQ entry	Advisors see prior-day positions (stale but available); ops team escalates to Schwab support; manual SFTP pull as last resort
Pershing (nightly file)	Batch ETL + Transform	Same as Schwab — 3x retry per chunk; proprietary format errors trigger transform-level retry after schema validation	Separate DLQ queue for Pershing; format translation errors logged with raw payload for debugging	Alert if not complete by 6:30 AM EST; separate dashboard for institutional team (40 users); escalation to BNY Mellon support	Institutional team uses prior-day data; CoE manually runs reconciliation once connection restores
Orion (bidirectional 15-min)	Near-real-time sync	Exponential backoff: 1 min, 5 min, 15 min, then park; demographics outbound retries 5x; performance inbound retries 3x	Anypoint MQ DLQ for failed messages; conflict records (SF vs. Orion disagree) written to Conflict_Resolution__c staging object	Conflict count dashboard; alert if >10 conflicts/day; alert if sync gap exceeds 30 minutes	SF demographics are authoritative — Orion reads stale until restored; performance/billing data frozen at last successful sync; manual reconciliation before next quarterly billing
FIS Horizon (SOAP real-time)	Request-Reply	Client-side retry 2x with 3-second timeout; circuit breaker opens after 5 consecutive failures in 60 seconds	No DLQ (synchronous) — failed queries return a cached response or “temporarily unavailable” message to the user	Circuit breaker state dashboard; alert on open circuit; FIS batch window (10 PM-2 AM EST) expected — suppress alerts during that period	Display “Banking data temporarily unavailable” in UI with last-known balance and timestamp; queue user-initiated refresh requests for when FIS returns; no transaction data stored in SF (FIS is SOR)
Smarsh (near-real-time)	Event-driven	Webhook delivery retry 3x at 5-min intervals; MuleSoft reprocesses from Smarsh API if webhook missed	MuleSoft DLQ for unmatched communications (no matching SF client record); compliance team reviews weekly	Alert if linking rate drops below 95% (currently incomplete per paper); daily compliance dashboard showing unlinked communications	Smarsh continues archiving independently — no data loss; linking to SF records is catch-up only; compliance can still search Smarsh directly for regulatory requests
DocuSign (webhook on completion)	Event-driven	DocuSign retries webhook delivery per their retry policy (up to 24 hours); MuleSoft acknowledges and reprocesses failures from DocuSign status API	Failed document links written to DLQ; manual review queue for docs that cannot be matched to a client record	Alert if >5 unsigned envelopes stale >48 hours; dashboard for ops showing pending vs. completed envelopes	Advisors can still send envelopes via DocuSign directly (out-of-band); ops team manually links completed docs on restoration
SharePoint (on-demand)	Request-Reply	Client-side retry 2x with 5-second timeout; MuleSoft caches recent metadata queries for 1 hour	No DLQ (synchronous, user-triggered)	Alert if SharePoint availability drops below 99% over rolling 24 hours	Display “Documents temporarily unavailable” in UI; regulatory requests (48-hour production requirement) handled directly via SharePoint search if SF integration is down

Judge Signal

Judges probe error handling for custodian feeds specifically — if the Schwab nightly load fails, do advisors see stale data or nothing? The answer is stale (prior-day positions remain in Financial Holding). The staging object pattern ensures partial loads never corrupt production data. Also be ready to explain FIS circuit breaker behavior during the nightly batch window when the API is intentionally unavailable.

Governance & DevOps

Environment Topology

flowchart LR
    subgraph DevEnvs["Developer Sandboxes (Metadata Only)"]
        DEV_W["DEV-WEALTH\n(Developer Pro)"]
        DEV_B["DEV-BANKING\n(Developer Pro)"]
        DEV_INT["DEV-INT\n(Developer Pro)"]
        HOTFIX["HOTFIX\n(Developer Pro)"]
    end

    subgraph TestEnvs["Test Environments"]
        QA["QA / Integration\n(Partial Copy)\nMasked PII + financial data"]
        UAT["UAT / Staging\n(Full Copy)\nCompliance + performance testing"]
    end

    DEV_W -->|"PR merge to develop"| QA
    DEV_B -->|"PR merge to develop"| QA
    DEV_INT -->|"PR merge to develop"| QA
    QA -->|"Release branch cut"| UAT
    UAT -->|"CCO approval gate\nfor security/compliance changes"| PROD["PRODUCTION"]
    HOTFIX -->|"Emergency path\nCTO + CoE Lead approval"| PROD

    style PROD fill:#d4edda,stroke:#28a745,color:#000
    style QA fill:#fff3cd,stroke:#fd7e14,color:#000
    style UAT fill:#cce5ff,stroke:#0d6efd,color:#000
    style HOTFIX fill:#f8d7da,stroke:#dc3545,color:#000

Branching Strategy

Adapted for a regulated financial services environment with SOX segregation-of-duties requirements:

• main — mirrors production. Only release manager can merge (SOX: deployer is not the developer). Protected branch with required approvals.
• develop — integration branch. All feature branches merge here after PR review. Auto-deploys to QA sandbox on merge via GitHub Actions.
• feature/* — one branch per user story or work item. Developers work in their Developer Pro sandbox and validate locally before PR.
• release/* — cut from develop when sprint is release-ready. Deployed to UAT (Full Copy) for compliance review and performance testing. Only bug fixes cherry-picked into release branches — no new features.
• hotfix/* — branches from main for emergency production fixes. Requires CTO + CoE Lead approval. Merged to both main and develop after fix is validated. Post-hoc CCO review within 48 hours for any changes touching security or access controls.

Sandbox Strategy

Sandbox	Type	Purpose	Data	Refresh Cadence
DEV-WEALTH	Developer Pro	Wealth feature development	Metadata only	On-demand
DEV-BANKING	Developer Pro	Banking feature development	Metadata only	On-demand
DEV-INT	Developer Pro	Integration development (MuleSoft endpoints)	Metadata only	On-demand
HOTFIX	Developer Pro	Emergency fixes only	Metadata only	On-demand
QA	Partial Copy	Functional testing, regression, integration	Masked PII, anonymized financial data (Data Mask)	Bi-weekly
UAT / Staging	Full Copy	UAT, compliance review, performance testing	Full production clone with Data Mask applied post-refresh	Monthly

Data masking requirements (SOX + FINRA + GLBA):

• Salesforce Data Mask applied to all non-production environments immediately after refresh
• Masked fields: SSN, account numbers, portfolio values, position details, MNPI flags, contact PII (name, email, phone, address)
• Compliance-validated test data sets maintained for UAT scenarios requiring realistic patterns (e.g., Chinese wall testing, tier threshold workflows, suitability checks)
• No production client data used in developer sandboxes — metadata only (Developer Pro does not copy data)

Testing Strategy

Test Type	Target	Environment	Gate
Unit tests (Apex)	>= 85% coverage (above 75% Salesforce minimum; firm standard)	Developer sandbox	PR merge to develop
Integration tests	MuleSoft + Salesforce end-to-end per integration point	QA (Partial Copy)	Sprint completion
Regression tests	Full test suite including sharing model, Chinese wall, suitability workflows	QA	Release branch cut
Performance tests	Nightly batch (2M records in 5-hour window), page load < 3s for aggregated client views, 2,200 concurrent users	UAT (Full Copy)	Release to production
Security / compliance UAT	Chinese wall visibility, advisor book isolation, MNPI restriction, SOX segregation of duties	UAT with CCO + compliance officers	CCO sign-off
User acceptance	Advisor workflows, banking staff cross-sell, operations service requests, portal client experience	UAT with representative users from each division	Business owner sign-off

SOX-specific controls in the pipeline:

• Segregation of duties: The developer who writes code cannot be the person who deploys to production. Release manager (CoE Lead) owns production deployments.
• Change documentation: Every deployment includes a change record with business justification, risk assessment, and rollback plan — stored in GitHub and linked to the Jira work item.
• Quarterly access certification: GitHub Actions generates quarterly access reports (who has admin/deploy permissions). Business owners certify access is appropriate. Results archived for SOX auditors.
• Immutable audit trail: Shield Event Monitoring captures login, data access, and configuration changes. Field Audit Trail retains 7+ years of field-level changes on sensitive objects.

CoE & Ongoing Governance

Center of Excellence structure (10 people, self-sufficient by month 18):

Role	Count	Background	Ramp Plan
CoE Lead / Release Manager	1	Existing (hire or promote)	Immediate
Wealth Admins	2	Existing 2-person admin team (upskilled)	Salesforce Admin cert by month 6
Banking Admins	2	From banking’s 5 Dynamics admins (3 wanting SF cert)	Salesforce Admin cert by month 9; Platform App Builder by month 12
Developers	3	1 existing + 2 from banking (.NET devs retrained)	Platform Developer I cert by month 9
Business Analysts	2	Existing (wealth + banking BA)	Salesforce Business Analyst cert optional
Compliance Liaison	1 (part-time)	CCO delegate	No cert needed — regulatory expertise

Banking staff retraining (union-compliant):

• 3 of 5 Dynamics admins want Salesforce certification — prioritize them for Admin cert training starting Phase 1
• 2 .NET developers retrained as Salesforce developers (Apex, LWC) — structured 3-month training program with Trailhead, hands-on project work in DEV-BANKING, and mentoring from existing SF developer
• Union notification submitted 90 days before banking go-live for any role changes affecting daily workflows (banking staff in 3 unionized states)

Release cadence:

• During implementation (Phases 0-3): 2-week sprints with deployments to production every 4 weeks (every other sprint). Compliance-flagged changes require CCO review in UAT before production promotion.
• Post-stabilization (Phase 4+): Monthly release cadence with biweekly hot-fix window. Full regression testing before every release. 48-hour hypercare after each production deployment.

Ongoing maintenance model:

• MuleSoft monitoring via Anypoint Monitoring — integration health dashboards, error rate alerting, SLA tracking
• Shield Event Monitoring reviewed weekly by compliance liaison for anomalous access patterns
• Quarterly platform health reviews: storage trending, governor limit utilization, sharing model performance, API consumption
• Annual architecture review: evaluate managed compliance app vendor status, assess new Salesforce features (e.g., native MFA improvements, new Shield capabilities), plan technical debt reduction

Reporting Approach

CRM Analytics powers the daily CIO dashboard (firm-wide AUM, net new assets, attrition, advisor productivity — refreshed by 7:30 AM via nightly custodian batch loads), weekly regional director reports (per-advisor book metrics with drill-down scoped by the sharing model), and branch performance dashboards (deposit growth, loan origination, cross-sell conversion from FIS Horizon data). Compliance audit reports (record access history, suitability changes, trade surveillance) leverage Shield Event Monitoring and Field Audit Trail. Ad-hoc manager reporting uses CRM Analytics with row-level security inheriting the Salesforce sharing model — no IT involvement required (Req 29).

Related Resources

• Case Study 01 Paper
• Presentation Notes
• Q&A Preparation