Case Study 1: Apex Wealth Partners - Worked Solution

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Reference Solution

This page compiles a worked answer for full-board study use. Compare the structure and trade-offs against your own attempt rather than treating it as the only acceptable design.

Solution Snapshot

Field	Detail
Open after	Scenario Paper
Difficulty	Advanced
Primary pressure areas	System Architecture, Security, Data, and Integration
Study role	Worked solution and artifact reference
Core frameworks	9 Essential Artifacts + Five-Finger Method
Related pages	Case Study Overview, Presentation Notes, Q&A Preparation

Only Open After Your Own Attempt

If you have not yet worked through the scenario paper, stop here. Set a full 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 plus external log archive required. Shield Platform Encryption covers data-at-rest encryption for restricted fields (SSN, account numbers, positions, MNPI flags). Shield Field Audit Trail retains up to 10 years of field-level history and satisfies SOX/FINRA 7-year retention for record-level changes. Shield Event Monitoring captures login, data access, and configuration events, but native EventLogFile retention is 30 days by default and 1 year maximum with the add-on, so meeting the SEC/FINRA 7-year record-access logging requirement needs a nightly export of EventLogFile records to an external archive (AWS S3 object-lock for WORM + Splunk SIEM for search and anomaly detection).
3. Experience Cloud (formerly Community 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, the sharing model isolates MNPI data at the child-record level within one org, compliance gets a single query surface, and there is 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, and (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 by isolating MNPI data on child records with their own Private OWD. Judges want to see that you considered multi-org seriously and rejected it with specific reasoning.

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

MNPI data lives on a dedicated child Financial Account record type (Commercial Lending) with its own Private OWD and Apex-managed sharing to the banking commercial lending team only. Restriction Rules are not supported on Account, so the wall is enforced at the child-record layer rather than the parent.

How it works:

• Person Account stays Private OWD. A wealth advisor can own the Account record for the individual (e.g., the client has a private wealth relationship), but the MNPI-sensitive attributes never live on Account.
• Commercial lending opens its relationship through a Financial Account record with RecordType = 'Commercial Lending'. This child record is not Controlled by Parent — it has its own Private OWD, breaking the inheritance chain so that Account ownership does not cascade.
• An Apex Managed Sharing trigger on the Commercial Lending Financial Account grants Read/Write access only to commercial lending team members and the MNPI_Authorized_Viewer group. The trigger runs on insert and owner change, writes rows to the Apex-managed sharing table, and reconciles nightly.
• A field-level-security profile hides the existence of Has_MNPI__c on Person Account from wealth advisor profiles. Wealth advisors never see the flag, never see the child Commercial Lending record, and cannot query it through SOQL.
• Restriction Rules on the supported junction object MNPI_Exposure__c (custom object) act as a defence-in-depth layer. The junction links authorised users to specific MNPI disclosures for audit traceability; the Restriction Rule filters rows so unauthorised users cannot see exposure records even if they gain object-level access.

Why not Restriction Rules on Account: Account is not on Salesforce’s supported-object list for Restriction Rules (the list is custom objects, external objects, contracts, events, quotes, tasks, time sheets, and time sheet entries). Restriction Rules also do not apply to record owners, users with View All / Modify All, or users with View All Data / Modify All Data. A wealth advisor who owns a Person Account would still see MNPI attributes on that Account regardless of any Restriction Rule. Isolating MNPI data to a child object with its own Private OWD is the only pattern that holds up against the “advisor already owns the record” edge case.

Apex Managed Sharing on the child object (accepted): Commercial Lending Financial Account starts from zero access (Private OWD, no inheritance, no role-hierarchy leakage) and the trigger builds shares up to the exact commercial lending user set. This is additive but starts from an isolated baseline, which is the correct pattern for “share only to this named team.”

Decision 3: Sharing Model Architecture (HEAVY - D2)

Private OWD on Account. Financial Account OWD is Private with criteria-based sharing rules scoped by record type (Wealth and Banking) and Apex Managed Sharing for the Commercial Lending record type (MNPI).

Object	OWD	Access Mechanism
Account (Person Account)	Private	Advisor ownership + Team shares + Territory rules
Financial Account (all record types)	Private	Wealth RT: criteria-based sharing rule to Wealth Advisors group. Banking RT: criteria-based sharing rule to Banking Staff group. Commercial Lending RT: Apex Managed Sharing to commercial lending team only.
Financial Holding	Controlled by Parent	Inherits from Financial Account (follows the division scoping of the parent record)
Opportunity	Private	Advisor ownership
Case (Banking Service)	Private	Branch ownership + queue assignment
Task / Event	Controlled by Parent	Inherits from related Account; MNPI-tagged activities attach to the Private Commercial Lending child record to stay isolated

Why Private OWD on Financial Account

Salesforce allows one OWD per object, not per RecordType. Setting Financial Account to Private gives the Commercial Lending record type the isolation it needs (no automatic Account-owner inheritance). The Wealth and Banking record types then get access through criteria-based sharing rules scoped by RecordType to the Wealth Advisors and Banking Staff public groups — this mimics the behaviour advisors and branch staff need (they see financial accounts under the Person Accounts they are expected to service) without cascading MNPI records to anybody who owns the parent Account. The Commercial Lending record type is deliberately excluded from the criteria-based sharing rules and receives Read/Write access only through an Apex Managed Sharing trigger that writes rows to FinancialAccountShare for the commercial lending team members.

Division isolation between Wealth and Banking: Role hierarchy alone does not scope a Person Account owner to division-specific Financial Accounts because Controlled-by-Parent grants Account owners access to all children. A criteria-based sharing rule on Financial Account (Wealth record type) grants Read/Write to the Wealth Advisors public group; a second rule grants Banking record types to the Banking Staff public group. Financial Accounts are then Private OWD with these two rules replacing the inheritance for Wealth and Banking record types, and Apex Managed Sharing covering Commercial Lending. An advisor who owns the Person Account still sees the Account, but only sees Financial Accounts whose RecordType matches their division.

Advisor teams: Account Teams (AccountTeamMember) group advisors into service teams. Each team member receives a defined access level (Read/Write) on all accounts where any team member is the owner. FSC Relationship Groups are a separate concept used for client households, not advisor teaming.

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: Compliance users are assigned a Minimum Access - Salesforce profile that grants no Edit or Delete on any object. All read access is layered on via a Permission Set Group containing View All on Account, Financial Account, Activity, and custom compliance objects. Because Salesforce permissions are strictly additive and cannot be subtracted by a Muting Permission Set across a base profile that already grants Edit, the minimal-profile pattern is the only way to guarantee compliance users have View-only access that cannot be escalated by future profile changes.

Artifact 1: System Landscape Diagram

Figure 1. System landscape for Apex Wealth Partners showing a single FSC org serving wealth advisors, banking staff, and compliance users, with MuleSoft Anypoint mediating all six custodian and service integrations. Dynamics 365 migrates in Phase 2 as banking operations consolidate onto the Salesforce platform.

Artifact 2: Data Model / ERD

Figure 2. FSC data model for Apex Wealth Partners showing the Person Account and Household hierarchy with Financial Account, Financial Holding, and Compliance Review objects. The Commercial Lending record type on Financial Account holds MNPI-sensitive data with its own Private OWD, and the Has_MNPI__c field on Person Account is hidden from wealth advisor profiles via field-level security.

FSC Data Model

Uses FSC Core standard objects (the standard-object model, not the managed package): Person Account, Account with RecordType = “Household” (NOT a separate object — members relate via AccountContactRelation), FinancialAccount, FinancialAccountParty (API v61.0+, the Core replacement for the managed package FinServ__FinancialAccountRole__c), Financial Holding, and Account Team Members (advisor teams). Custom objects: Compliance_Review__c, Suitability_Check__c, MNPI_Exposure__c. The MNPI_Exposure__c junction is a supported Restriction Rule target and acts as a defence-in-depth layer; the primary Chinese wall mechanism is the Commercial Lending Financial Account record type with its own Private OWD and Apex Managed Sharing. A greenfield implementation in 2025-2026 uses the FSC Core objects end-to-end; any data still on the legacy managed package (FinServ__FinancialAccountRole__c, FinServ__FinancialAccount__c) is migrated to Core objects as part of Phase 0 to avoid running two parallel data models.

Artifact 3: Role Hierarchy

Figure 3. Role hierarchy for Apex Wealth Partners with wealth management and retail banking in separate branches, ensuring no upward visibility between divisions. Compliance sits as a peer branch with read-only access granted via a Permission Set Group containing View All Read on the regulated objects, rather than hierarchy inheritance.

OWD Summary:

Object	OWD	Access Mechanism	Rationale
Account (Person Account)	Private	Advisor ownership + Team shares + Territory rules	Advisors see only their book; 30% team-sharing via AccountTeamMember
Financial Account (Wealth RT)	Private	Criteria-based sharing rule: RecordType = Wealth to Wealth Advisors group	Positions/balances visible only to wealth advisor team
Financial Account (Banking RT)	Private	Criteria-based sharing rule: RecordType = Banking to Banking Staff group	Banking data visible only within branch territory
Financial Account (Commercial Lending RT, MNPI)	Private	Apex Managed Sharing to commercial lending team only	MNPI isolated; inheritance chain from Account deliberately broken
Financial Holding	Controlled by Parent	Inherits from Financial Account	Custodian data follows division-scoped Financial Account access
Opportunity	Private	Advisor ownership	Pipeline isolated per advisor
Case (Banking Service)	Private	Branch ownership + queue assignment	Banking cases visible only within branch territory
Task / Event	Controlled by Parent	Inherits from related Account; MNPI activities attach to Commercial Lending child record	Activity history follows account access with MNPI isolation
Compliance Review	Private	Compliance PSG (View All)	Only compliance team sees all reviews
MNPI Exposure (junction)	Private	Restriction Rule + PSG	Defence-in-depth audit layer; Restriction Rule is supported on custom objects

Hierarchy Rationale

Wealth and banking are separate branches with no cross-branch inheritance. Compliance sits as a peer branch with read-only Permission Set Group grants, not through hierarchy, which prevents unintended upward access paths. IT/CoE staff should use the System Administrator profile (bypasses OWD) rather than hierarchy-based access. The split OWD approach on Financial Account prevents the edge case where a wealth advisor who owns a Person Account automatically gains access to every Financial Account child record regardless of division — Private OWD with record-type criteria-based sharing rules keeps Banking and Commercial Lending records out of wealth advisor visibility even when they own the parent.

Artifact 4: Integration Architecture

Figure 4. Integration architecture for Apex Wealth Partners showing Schwab and Pershing nightly batch loads via MuleSoft staging, Orion bidirectional 15-minute sync, FIS Horizon real-time SOAP queries, and event-driven Smarsh and DocuSign connections. All custodian data lands on Financial Account and Financial Holding objects.

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

Figure 5. Summary identity flow for Apex Wealth Partners showing Okta SAML 2.0 for employees and Experience Cloud native identity for wealth clients, with the two authentication paths completely independent at the architecture level.

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 Single Sign-On Setting and map Okta attributes to Salesforce User fields.

Artifact 6: Data Migration Strategy

Phase 2 - 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)	Bulk API 2.0 + custom Apex	8K records
5	Load banking financial accounts + cases	Bulk API 2.0	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 0 / Phase 1 - 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. Migrate any data still on the legacy FSC managed package (FinServ__FinancialAccount__c, FinServ__FinancialAccountRole__c) to the FSC Core standard objects (FinancialAccount, FinancialAccountParty) so the org runs a single data model end-to-end. The greenfield posture is FSC Core; the managed-package objects are retired from production metadata once the migration is validated.

Historical activity and archival plan: Dynamics activities (3 years) and existing Salesforce activities (5 years) combine to roughly 12M Task and Event records against an org already at 78% storage. Three-tier strategy:

• Hot tier (0-18 months): Active Task and Event records stay in standard objects, indexed by ActivityDate and WhatId for advisor day-to-day use.
• Warm tier (18-24 months): Activities older than 18 months are archived to a Activity_Archive__b Big Object via scheduled Batch Apex. Archive records retain the original ActivityDate, user, subject, and related record IDs. Big Object composite index is (AccountId, ActivityDate, Id) so advisor-specific lookbacks for a single client stay query-fast; cross-account aggregations use Bulk API 2.0 extractions or CRM Analytics external connectors rather than SOQL.
• Cold tier (24 months+): Records older than 24 months are offloaded nightly to AWS S3 via MuleSoft Anypoint + Salesforce Backup export, compressed, and retained for the full 7-year SEC/FINRA window. Compliance retrieval goes through a MuleSoft lookup API that streams matching records back to a Salesforce External_Activity_Archive__x external object bound via Salesforce Connect.

Dynamics activities migrate with Original_Activity_Date__c as a custom audit field (Salesforce does not allow setting CreatedDate without Enable Audit Fields). The archival pipeline holds storage consumption below 90% across the 24-month program and gives compliance a consistent interface for the full 7-year lookback.

SharePoint document migration (Req 36): The paper requires the 1.2 TB of SharePoint banking documents to be migrated, not just surfaced. Hybrid migration pattern:

• Target store: AWS S3 with object-lock (WORM) enabled for SEC Rule 17a-4 compliance. Salesforce Files Connect exposes the S3 store to Salesforce users so the files appear inside client records without consuming Salesforce file storage (1.2 TB dwarfs the standard Salesforce file storage allocation, and the per-GB cost on S3 is an order of magnitude lower).
• Bulk transfer: MuleSoft runs a one-time parallelised copy from SharePoint Online to S3 during Phase 2. Files are hashed on both ends for integrity, metadata (client ID, document type, branch, retention date) is extracted from the SharePoint content-type taxonomy and written to an S3 metadata index plus a Salesforce Document_Metadata__c custom object so search is native.
• Record linkage: A post-migration Batch Apex job walks the Document_Metadata__c records and creates ContentDocumentLink rows pointing to the corresponding Person Account or Financial Account so the documents appear under the expected record in the UI.
• Cutover: Once S3 becomes the system of record (end of Phase 2), SharePoint is decommissioned as a document store. This meets Req 36 (documents migrated, metadata tagged, accessible from client records) and also satisfies the 7-year regulatory retention requirement with a 48-hour production window via pre-indexed S3 metadata search.

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

Standard sandbox refresh pulls from Production. Sandbox-to-sandbox cloning (GA since Winter ‘23) allows cloning one sandbox into another, useful for replicating a validated integration environment without a full production 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

Figure 6. 24-month phased delivery roadmap for Apex Wealth Partners, sequencing foundation and Chinese wall work before the banking migration to meet the Dynamics 365 contract deadline, with the client portal deferred until both divisions are live and the unified data model is stable. The program starts six months after the acquisition close so cultural integration, governance formation, and vendor selection finish before Phase 0 execution begins.

Phase rationale:

• Phase 0 (Foundation): Address org technical debt, migrate from the FSC managed package to FSC Core standard objects, 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 the Chinese wall isolation pattern (Commercial Lending record type + Apex Managed Sharing + FLS on MNPI flag). This builds confidence before the more disruptive banking migration.
• Phase 2 (Banking Onboarding): Migrate banking data, banking staff, and the 1.2 TB SharePoint document library 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: The paper requires migration of 1.2 TB of SharePoint banking documents (Req 36), not just surfacing. The Phase 2 document migration workstream runs in parallel with banking console build: MuleSoft copies files from SharePoint Online to an S3 bucket with object-lock for WORM compliance, preserves the content-type taxonomy as metadata, writes Document_Metadata__c records in Salesforce for search, and binds the files to client records via Files Connect and ContentDocumentLink. SharePoint is decommissioned as a document store at the end of Phase 2. This meets Req 36 (migrated and accessible), holds Salesforce file storage below quota, and satisfies SEC Rule 17a-4 through S3 object-lock retention.

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 staff get Service Cloud licenses because their Permission Set Group grants View All on Case for the SOX access review workflow and customer-service dispute history — Platform licenses do not provide access to the Case object and would break the compliance review experience. Service Cloud is the lowest-cost license family that grants Case access, and the cost delta over Platform (roughly $75/user/month times 150 users, or about $135K/year) is absorbed into the $12M program budget. 200 operations staff get Service Cloud licenses for case management and service request processing. 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

Figure 7. Detailed identity and SSO flow for Apex Wealth Partners with three independent authentication lanes: Okta SAML 2.0 with JIT provisioning for 2,200 employees, Experience Cloud native MFA for wealth clients, and OAuth 2.0 client credentials for MuleSoft integration users.

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). Standard SAML JIT provisioning only maps assertion attributes to User record fields (Profile, Role, UserName, Email, etc.) — it cannot assign Permission Sets or Permission Set Groups natively. A Custom Apex JIT Handler (implementing Auth.SamlJitHandler) parses the Okta group-membership attribute on each assertion, looks up the mapped PSG name, and calls PermissionSetAssignment Apex to grant or revoke PSGs on login. The handler also writes an audit row to JIT_Event__c so the CCO has a record of every PSG change tied to a login timestamp. 8-hour session timeout with re-authentication for sensitive operations (e.g., modifying client access, accessing MNPI-flagged records via Step-Up Authentication through High Assurance session policies).
• 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: MuleSoft is the integration hub. All six external systems (Schwab, Orion, FIS, Smarsh, DocuSign, SharePoint) connect to MuleSoft, not to Salesforce directly. Salesforce therefore needs outbound Named Credentials only for the Salesforce-to-MuleSoft connection (a single Named Credential with OAuth 2.0 Client Credentials pointing at the MuleSoft API Gateway). MuleSoft holds the per-system credentials to Schwab, Pershing, Orion, FIS, Smarsh, DocuSign, and SharePoint in Anypoint Secrets Manager. For inbound traffic (MuleSoft calling Salesforce APIs), MuleSoft authenticates via a dedicated External Client App (the Spring ‘26 successor to Connected Apps) configured for OAuth 2.0 Client Credentials flow, running under a dedicated integration user with the least-privilege profile required to write Financial Account, Financial Holding, and staging object records. No interactive service accounts, satisfying the CISO requirement.
• 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

Figure 8. Environment topology for Apex Wealth Partners showing the SOX-compliant promotion pipeline from three developer sandboxes through QA and full-copy staging, with a mandatory CCO approval gate for any change touching security or compliance controls before reaching production.

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; Event Monitoring log files are exported nightly to S3 + Splunk for the full 7-year SEC/FINRA retention window (native Event Monitoring retention caps at 1 year). Field Audit Trail retains up to 10 years of field-level history on sensitive objects, satisfying the 7-year SOX/FINRA requirement at the field level.

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 use, 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

Mobile Strategy

Advisor mobile access (Req 65, 67): Salesforce Mobile App configured with a custom advisor navigation set showing key tabs (Accounts, Financial Accounts, Activities, Dashboards). Mobile Application Management (MAM) via Microsoft Intune enforces device-level security: passcode lock, remote wipe, jailbreak detection. The sharing model, record-type-scoped sharing rules, Apex Managed Sharing on Commercial Lending records, and Permission Set Groups apply identically on mobile. Offline access enabled for account records and activity logging so advisors can work during off-site meetings (30% of meetings) and sync when reconnected.

Future mobile banking (Req 66): The “pop-up banking” initiative uses a Salesforce Mobile App configuration scoped to the Banking Service Console. Branch staff at community events access a limited tab set (Account lookup, Case creation, Referral submission) with the same role hierarchy and OWD restrictions as the desktop experience. MDM enrollment is mandatory before granting mobile access.

Security parity (Req 67): All mobile sessions enforce the same MFA, session timeout (8-hour), and data classification rules as desktop. Shield Platform Encryption protects data at rest in the Salesforce database (server-side encryption). On-device data protection is handled by MDM (Intune) enrollment and OS-level encryption (iOS Data Protection / Android file-based encryption), not by Shield. Salesforce mobile inherits the same OWD, record-type-scoped sharing rules, and Apex Managed Sharing on the Commercial Lending Financial Account record type that enforce the Chinese wall on desktop, so MNPI isolation holds regardless of access channel.

Performance and Scalability

Page load targets (Req 60): Aggregated client views (household AUM, financial accounts, holdings) target sub-3-second loads through selective SOQL with indexed fields, rollup summary fields on Household for pre-computed totals, and lazy loading of historical holdings. Custom LWC components fetch Financial Holding data on demand rather than loading all positions on page render.

Scalability to 250K accounts and 3,000 employees (Req 62): The FSC data model supports this growth within standard platform limits. Custom indexes on Financial Account and Financial Holding accelerate reporting queries at sub-2M record volumes. Skinny Tables are reserved for extreme LDV scenarios (tens of millions of records) and require Salesforce Support to create. The Big Objects archival strategy (holdings older than 2 years) keeps the active Financial Holding table under 2M records, making standard custom indexes sufficient. Annual architecture reviews assess storage trending and governor limit consumption.

Portal capacity (Req 63): Experience Cloud supports 5,000 concurrent external users with Customer Community Plus licenses. Portfolio views query pre-aggregated rollup fields rather than real-time SOQL against Financial Holding, reducing query load. CDN caching for static portal assets (branding, help content) reduces server-side rendering.

Quarterly rebalancing peaks (Req 64): During rebalancing, trade confirmation webhooks from Schwab increase to 3x normal volume. MuleSoft scales horizontally with auto-provisioned workers during peak windows. Platform Events decouple webhook receipt from Salesforce processing, buffering spikes without exceeding API limits. The staging object pattern absorbs volume surges during nightly custodian loads that coincide with rebalancing activity.

Advisor Licensing and Secure Messaging

Advisor licensing tracking (Req 9): A custom Advisor_License__c object tracks each advisor’s certifications (Series 7, Series 66, state registrations, insurance licenses) with expiration dates. A validation rule on Opportunity prevents advisors from initiating activities requiring certifications they do not hold (e.g., insurance product recommendations without an active insurance license). Automated alerts notify the compliance team 90 days before any license expiration.

Secure client messaging (Req 21): Experience Cloud supports a secure messaging channel between clients and their advisory team using the Messaging object model (MessagingSession, MessagingEndUser). Session metadata (participants, timestamps, routing, disposition) is on-platform and linked to the client’s Person Account, but message body content sits in the off-platform conversation store and is not queryable via SOQL or standard reports. For FINRA Rule 4511 supervision and examiner retrieval, the architecture runs two parallel retention paths: (a) a MuleSoft connector calls the Conversation Data API nightly to bulk-export completed conversations into Smarsh, where the 7-year retention policy and supervisory review workflow live; (b) a Data 360 ingestion stream subscribes to the Messaging Conversation data kit so conversation content is replicated into a Data 360 data lake object that compliance can search via the Data 360 query API during an examination. Either path produces examiner-ready output within the 48-hour production window; Smarsh is the primary system of record for regulatory search, Data 360 is the Salesforce-native working copy.

Compliance Shield retention and external archive: Shield Field Audit Trail retains field-level history for up to 10 years, covering the 7-year SOX/FINRA requirement for record-level changes. Shield Event Monitoring is different — log file retention is 30 days by default and extensible to a maximum of 365 days with the Event Monitoring add-on. Meeting the 7-year SEC/FINRA record-access logging requirement (who viewed which record, when, from where) therefore requires exporting Event Monitoring log files to an external archive. The architecture streams EventLogFile records nightly via MuleSoft to AWS S3 with object-lock enabled (for WORM compliance) and into a Splunk SIEM for anomaly detection and compliance dashboards. The Splunk/S3 archive covers the full 7-year window; Shield alone does not.

Reporting Approach

CRM Analytics (formerly Tableau CRM) 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), 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) use Shield Event Monitoring exports and Field Audit Trail. Ad-hoc manager reporting uses CRM Analytics with row-level security implemented through security predicates on the dataset plus the Integration User and Security User configuration that determines what rows are ingested and which user’s sharing context is evaluated at query time. CRM Analytics does not natively inherit the Salesforce sharing model at the row level; the predicate is an explicit filter expression (for example, 'Owner.Role' == "$User.Role" or 'RecordType' == "Wealth") that references user attributes and record attributes and must be designed during dataset build. The business outcome — a regional director seeing only their own region’s advisors — is reproduced via predicates, not inherited for free. This is a design decision each dashboard must make explicit and test during UAT (Req 29).

Scoring Rubric

Criterion	Weight	What Judges Look For
Security & Compliance	25%	Chinese wall enforcement (advisor cannot see banking client who hasn’t consented). SOX/FINRA/SEC compliance mapped to specific Salesforce controls (Shield, Field Audit Trail, Event Monitoring). SSO separation for employees vs clients. Suitability record immutability
Architecture & Org Strategy	20%	Single-org justification with 8,000 overlapping clients. FSC data model using standard objects. Multi-cloud licensing (FSC + Experience Cloud + Shield). Clear system landscape with all 6+ integration points
Data Architecture	20%	Custodian data integration (2M-record nightly volumes). Client household and account relationship model. 7-year retention via Field Audit Trail. Migration strategy for Commonwealth banking data into existing org
Integration Depth	20%	Each external system classified by pattern, protocol, and volume. Custodian (Pershing/Schwab) batch integration. FIS Horizon banking integration. DocuSign for client onboarding. Error handling with retry, DLQ, and reconciliation per endpoint
Communication & Presentation	15%	Boardroom-ready artifacts. Confident defense of single-org over multi-org. Clear articulation of how advisor team-based books of business work. Logical flow from business requirements to technical decisions

Related Topics

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

---

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.