Solution 05: PrecisionParts Global Manufacturing

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.

Worked Solution

This is a reference solution for Scenario 05: PrecisionParts Global Manufacturing. Attempt the scenario paper first before reviewing. Use the 9 Essential Artifacts and Five-Finger Method as your framework.

Assumptions

• Budget authority for MuleSoft as part of the $4.5M Phase 1 investment
• Hyperforce available in the EU (Frankfurt) for data residency
• Experience Cloud for dealer portal (not custom-built)
• AWS IoT Core / Timestream remains system of record for raw sensor data
• MuleSoft Anypoint replaces SAP PI/PO as middleware
• China PIPL addressed via cross-border security assessment (not a separate org) given 580-user scale and “One PPG” mandate

Key Architectural Decisions

AD-1: Single Org with Hyperforce (EU Data Residency)

Decision: Single Salesforce org on Hyperforce with EU (Frankfurt) data residency.

I chose single org because it directly supports the “One PPG” mandate — unified global dealer view, consolidated pipeline, single territory management. Hyperforce Frankfurt satisfies GDPR. Global users access the same org with acceptable CRM latency. MuleSoft’s EU Runtime Plane must be explicitly configured for strict GDPR data processing compliance.

Rejected multi-org because it would require cross-org data sync for global dealer groups, duplicate the product catalog, triple SAP integration complexity, and make the global dealer health score nearly impossible in real-time. Adds $1-2M ongoing integration cost the budget cannot absorb.

China PIPL: Requires a security assessment for cross-border transfer, not mandatory in-country storage. PPG completes the standard government assessment and implements field-level encryption on Chinese PII. Fallback: Chinese Hyperforce region in Phase 2 (low-probability risk for B2B manufacturer with no consumer PII).

AD-2: External Data Lake for IoT + Summarized Data in Salesforce

Decision: Keep raw IoT data in AWS Timestream. Push daily/weekly aggregates into Salesforce custom objects for CRM correlation.

I chose external storage because 210M sensor readings/year far exceeds Salesforce storage economics and query limits. Platform storage alone would exceed $500K/year. Timestream handles time-series queries natively with 90-day hot / 2-year warm retention matching PPG’s policy.

CRM pattern: MuleSoft pulls hourly/daily aggregates from Timestream into Equipment Health Summary records. Dashboard widgets show equipment status; automated alerts create Cases on threshold breaches. Deep analysis via embedded Grafana dashboard through an LWC iframe.

AD-3: MuleSoft Anypoint as Unified Middleware + Experience Cloud Dealer Portal

Decision: MuleSoft replaces SAP PI/PO; Experience Cloud (PRM licenses) powers the global dealer portal.

MuleSoft consolidates all integration through one platform — pre-built SAP S/4HANA connectors (OData + RFC/BAPI), Salesforce connector for bidirectional sync, and Anypoint MQ for async messaging. Eliminates dual-middleware complexity and addresses PI/PO end-of-life risk.

Experience Cloud natively inherits Salesforce sharing rules for dealer isolation, supports 7 languages, integrates with the product catalog, and avoids custom portal maintenance. PRM licenses for 8,000 dealers are cost-effective vs. full CRM licenses. Portal features include CPQ tier-based pricing, Flow-driven order submission with SAP validation, near-real-time order status, CSV bulk upload, and document downloads.

Product catalog data model: 4-level hierarchy (Family > Line > Group > SKU) with 25 universal fields on Product, family-specific attributes via key-value child records, and a self-referential Supersedes__c lookup. Nightly Apex job traverses supersession chains to populate Current_Replacement__c.

Critical Diagrams

System Landscape

graph TB
    subgraph Legend
        direction LR
        NEW["🟢 NEW - Being Built"]
        KEEP["⚪ KEEPING - No Changes"]
        RETIRE["🔴 RETIRING - Decommissioning"]
        INT["🟠 INTEGRATION LAYER"]
    end

    subgraph Salesforce["Salesforce (Hyperforce - Frankfurt)"]
        SC[Sales Cloud — 1,240 users]
        EC[Experience Cloud — 8,000 dealers]
        CPQ[CPQ — Tier pricing]
        SVC[Service Cloud — Warranty]
        IoT[Equipment Health Summaries]
    end

    subgraph Mule["MuleSoft Anypoint"]
        API[API Gateway]
        SAP_C[SAP Connector]
        IOT_C[AWS Connector]
    end

    subgraph SAP["SAP S/4HANA"]
        FIN[Finance]
        MFG[Manufacturing]
        OTC[Order-to-Cash]
    end

    subgraph AWS["AWS IoT"]
        TS[Timestream — 210M/year]
    end

    EC -->|REST real-time orders| API
    SC -->|REST real-time opp sync| API
    API --> SAP_C -->|OData + RFC/BAPI real-time + batch| SAP
    API --> IOT_C -->|Batch hourly/daily aggregates| IoT
    IOT_C -.->|REST on-demand raw query| TS

    style SC fill:#cce5ff,stroke:#0d6efd
    style EC fill:#d4edda,stroke:#28a745
    style CPQ fill:#cce5ff,stroke:#0d6efd
    style SVC fill:#cce5ff,stroke:#0d6efd
    style IoT fill:#d4edda,stroke:#28a745
    style API fill:#fff3cd,stroke:#fd7e14
    style SAP_C fill:#fff3cd,stroke:#fd7e14
    style IOT_C fill:#fff3cd,stroke:#fd7e14
    style FIN fill:#e9ecef,stroke:#6c757d
    style MFG fill:#e9ecef,stroke:#6c757d
    style OTC fill:#e9ecef,stroke:#6c757d
    style TS fill:#e9ecef,stroke:#6c757d

Order Placement Flow (60-Second SLA)

sequenceDiagram
    participant Dealer as Dealer Portal
    participant SF as Salesforce
    participant Mule as MuleSoft
    participant SAP as SAP S/4HANA

    Dealer->>SF: Submit order
    SF->>SF: Validate tier pricing (CPQ)
    SF->>Mule: Sync — order payload

    par Credit + Inventory
        Mule->>SAP: Credit check (RFC/BAPI)
        SAP-->>Mule: Credit status
    and
        Mule->>SAP: ATP check (OData)
        SAP-->>Mule: Availability
    end

    alt All pass
        Mule->>SAP: Create sales order
        SAP-->>Mule: Confirmation
        Mule-->>SF: Order confirmed
        SF-->>Dealer: SAP order #
    else Fail
        Mule-->>SF: Order held + reason
        SF-->>Dealer: Contact rep
    end

Identity & SSO Flow

sequenceDiagram
    participant User as Internal User<br/>(Sales Rep / Corp Mgr)
    participant Browser as Browser
    participant AD as Active Directory<br/>(Microsoft Entra ID)
    participant SF as Salesforce<br/>(Hyperforce Frankfurt)

    User->>Browser: Navigate to Salesforce
    Browser->>AD: Redirect (SP-initiated SSO)
    AD->>AD: Authenticate (MFA via Authenticator)
    AD->>Browser: SAML 2.0 Assertion
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: Match Federation ID → User record
    SF->>Browser: Session Cookie + Redirect to Home

sequenceDiagram
    participant Dealer as Dealer Portal User
    participant Browser as Browser
    participant SF as Salesforce<br/>(Experience Cloud)

    Dealer->>Browser: Navigate to Dealer Portal
    Browser->>SF: Login page (Experience Cloud)
    SF->>SF: Username/Password + MFA (Email OTP)
    SF->>Browser: Session Cookie + Portal Home

Internal users (1,240): SAML 2.0 SP-initiated SSO with Microsoft Entra ID (Azure AD). PPG already uses Microsoft 365 globally, making Entra ID the natural IdP. MFA enforced via Microsoft Authenticator. Federation ID mapped to employee ID for all three regions.

Dealer portal users (8,000): Experience Cloud native login with email-based MFA. Dealers are external parties across 45 countries — SSO via a shared corporate IdP is not feasible. Self-registration with admin approval during onboarding. High-volume dealers (200 accounts) can optionally federate via their own corporate IdP using SAML Connected Apps.

Integration Error Handling

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring	Fallback
SAP Order Validation (credit + ATP)	Sync REST via MuleSoft	3 retries: 1s, 5s, 30s exponential backoff	Failed orders → MuleSoft DLQ → Order_Error__c staging object	Alert on > 5 failures/min or latency > 45s; PagerDuty to integration team	Order held with “Pending Validation” status; dealer sees “order received, confirming shortly”
SAP Order Status Polling	Near-real-time polling (5 min)	3 retries per poll cycle with 1s, 5s, 30s backoff	Unprocessed status changes → Anypoint MQ DLQ	Stale order alert if no status update > 30 min; dashboard monitor	Last known status displayed with “as of” timestamp; manual SAP lookup available
SAP Product Catalog Sync (CDC + nightly)	CDC delta + nightly full reconciliation	CDC: retry on next event; Nightly: full re-run on failure	Failed catalog records → Catalog_Sync_Error__c with SKU + error detail	Reconciliation mismatch report; alert if delta > 50 SKUs differ	Portal shows “pricing may not reflect latest changes” banner; CSR can look up SAP pricing manually
IoT → Equipment Health Summaries	Batch hourly/daily via MuleSoft	Batch re-run on failure; individual reading failures logged and skipped	Failed aggregations → S3 error bucket + Anypoint MQ DLQ	Alert if > 2 consecutive batch failures; CloudWatch alarm on Timestream query errors	Dashboard shows “last updated” timestamp; plant managers fall back to Grafana direct access
Legacy CRM Migration (one-time)	Bulk API batch loads	Record-level retry for failures; batch re-run for systemic errors	Migration_Error__c staging object with source system + record ID	Daily migration progress dashboard; error rate threshold alerts	Parallel-run with legacy systems continues until migration verified

SAP Circuit Breaker

The MuleSoft SAP connector implements a circuit breaker pattern: after 10 consecutive failures within 60 seconds, the circuit opens and all new order validation requests are queued in Anypoint MQ rather than sent to SAP. The circuit half-opens after 120 seconds, testing with a single request. This protects SAP from request storms during outages and prevents the 60-second SLA from cascading into portal timeouts.

Requirements Addressed

1. Unified dealer view — Single org with Account hierarchy + global permission sets (Reqs 1, 2, 5)
2. Dealer self-service portal — Experience Cloud PRM with 7-language support, CPQ tier pricing, bulk CSV upload (Reqs 8, 9, 10, 11, 12)
3. 60-second order SLA — Synchronous MuleSoft SAP validation with parallel credit + ATP checks (Reqs 13, 14)
4. Product catalog with hierarchy — 4-level custom object model with supersession chains and key-value attributes (Reqs 16, 12)
5. IoT data architecture — External AWS Timestream with summarized aggregates in Salesforce (Reqs 19, 31)
6. Regional data isolation — OWD Private, sharing rules per region, GDPR/PIPL field-level encryption (Reqs 22, 23, 24)
7. Mobile with offline — Salesforce Mobile with Briefcase for intermittent connectivity (Req 3)
8. 3-CRM migration with dedup — Pre-migration stewardship, tax ID + address match key, Chinese character preservation (Reqs 17, 18, 21)
9. Reporting and analytics — CRM Analytics for CEO dashboard, Data Cloud for cross-system supply chain correlation (Reqs 28, 29, 30)

Governance & DevOps

flowchart LR
    DEV_CHI[Developer Sandbox x4<br/>Chicago Team] --> SIT[SIT — Partial Copy<br/>SAP Test Connection]
    DEV_HYD[Developer Sandbox x2<br/>Hyderabad Team] --> SIT
    FB1[Feature Branch<br/>ERP Integration] --> SIT
    FB2[Feature Branch<br/>Portal Features] --> SIT
    SIT --> UAT[UAT — Full Copy<br/>8K Dealer Data + 150K SKUs]
    UAT --> PROD[Production<br/>Hyperforce Frankfurt]

Branching Strategy

Trunk-based with short-lived feature branches. The main branch represents production. Feature branches (max 1 week) are created for each user story. The two distributed teams (Chicago 8 + Hyderabad 4) work on separate feature branches and merge to main via pull request with mandatory code review.

• main — production-ready, protected branch
• feature/* — short-lived branches per user story (ERP integration, portal features, catalog sync)
• hotfix/* — emergency fixes cherry-picked to main, then merged back to active feature branches
• Quarterly release branches cut from main for release stabilization aligned with SAP maintenance windows

Sandbox Strategy

Sandbox Type	Count	Purpose
Developer	6	4 for Chicago team, 2 for Hyderabad. Individual developer work.
Developer Pro	2	Complex Apex development requiring more data (catalog testing, order validation logic)
Partial Copy	1	SIT environment with SAP test instance connection. Representative subset of dealer/product data.
Full Copy	1	UAT with full production data replica — 8,000 dealers, 150K SKUs, order history. Refreshed quarterly before release.

Testing Strategy

ERP integration testing is the highest priority given the 60-second order SLA and 5-minute status sync requirements.

• Apex unit tests: >80% code coverage target (above 75% minimum). All SAP callout classes use HttpCalloutMock with realistic response payloads including error scenarios (credit hold, ATP unavailable, SAP timeout).
• Integration testing (SIT): End-to-end order validation against SAP test instance. Load testing: simulate 9,200 peak orders/day (384/hour) to validate the 60-second SLA. MuleSoft API contract tests triggered on any SAP connector version change.
• Supply chain data validation: Automated reconciliation scripts verify product catalog counts, pricing accuracy, and supersession chain integrity between SAP and Salesforce after every sync cycle.
• UAT: Business stakeholders from all 3 regions validate dealer portal workflows, tier-based pricing, multi-language support, and reporting. 2-week UAT cycle before each quarterly release.
• Regression: Automated Selenium tests for critical portal workflows (order placement, catalog search, warranty claims). Run on every deployment to SIT and UAT.

CoE / Governance

Center of Excellence led by a Salesforce Platform Owner in Chicago, reporting to the CIO.

• Post-go-live ownership: CoE maintains the platform with 2 full-time admins + 2 developers. MuleSoft integration team (2 developers) handles SAP connector maintenance and monitoring.
• Change management: All changes follow Salesforce DX source-driven development. CAB approval required for production deployments (meets every other Wednesday per Req 34). Emergency hotfix process bypasses CAB with CIO + IT Director sign-off.
• Release cadence: Quarterly releases aligned to SAP maintenance windows. Experience Cloud updates deployed independently via rolling updates for zero-downtime dealer portal.
• SAP coordination: Joint SAP-Salesforce release calendar. SAP API contract changes require 4-week advance notice and regression testing in SIT before Salesforce release proceeds.

Risk Assessment

Risk	Likelihood	Impact	Mitigation
China PIPL security assessment denied	Low	High	Pre-engage legal counsel; fallback to Chinese Hyperforce region in Phase 2
60-second order SLA breached at peak (9,200 orders/day)	Medium	High	MuleSoft horizontal scaling; SAP ATP optimization; circuit breaker with queued retry
150K SKU catalog sync performance	Medium	Medium	Delta-only sync via CDC; nightly full reconciliation; index Part_Number and Supersedes fields
Dealer deduplication across 3 CRMs (1,200 duplicates)	High	Medium	Pre-migration data stewardship sprint; Duplicate Management Rules; match on tax ID + address

Domain Scoring Notes

D1 System Architecture (HEAVY): Judges want clear org strategy justification. Single-org-with-Hyperforce must address all three regions with GDPR/PIPL callouts. Licensing: Sales Cloud Enterprise (1,240), Experience Cloud PRM (8,000 dealers), Service Cloud for warranty. Mobile: Salesforce Mobile with offline briefcase for field reps with intermittent connectivity.

D3 Data (HEAVY): Must explicitly handle 210M IoT records externally — storing in Salesforce is a red flag. Product catalog must show 4-level hierarchy, supersession chain, and attribute flexibility. Migration: 3 CRMs with dedup, 4.2M orders (25.2M line items), 87K warranty claims, Chinese character preservation. Big Objects for archived legacy data (7-year retention).

D5 Integration (MEDIUM): Dual SAP patterns: synchronous (order validation, credit check via RFC/BAPI) and near-real-time polling (order status every 5 minutes via OData). MuleSoft replacing PI/PO as strategic platform consolidation.

D2 Security (MEDIUM): OWD Private on Account/Order/Case; sharing rules for regional teams; “Global View” permission set for corporate account managers. Warranty approval via entitlements ($5K/$25K/unlimited tiers).

D6 Dev Lifecycle (LIGHT): Two-team setup (Chicago 8 + Hyderabad 4) needs scratch org development with CI/CD. Quarterly releases aligned to SAP maintenance windows. Environments: Dev, SIT (SAP test connection), UAT (representative dealer/product data), Production. Zero-downtime deployment for Experience Cloud via rolling updates.

Reporting Approach

CRM Analytics for the CEO monthly dashboard and dealer health scores (D1 heavy). Cross-system supply chain reporting (CRM + SAP data) via MuleSoft-powered data replication into CRM Analytics datasets — NOT direct SAP queries from reports. Rebate calculation automated via scheduled Apex + CRM Analytics dashboard replacing the 3-person x 4-day Excel process.

What Would Fail

Recommending multi-org without quantifying cost. Judges will probe: “How do you show a global dealer view across orgs? How do you sync the product catalog? What is the cross-org integration cost?” Without strong answers, this collapses.

Putting IoT data in Salesforce. 210M records/year in Big Objects or custom objects is a storage and performance disaster. This is an external data lake problem with summarized data flowing into Salesforce.

Ignoring the 60-second order SLA. Requires synchronous SAP integration for credit and inventory checks. Batch/async processing for order submission misses a hard requirement. The parallel credit + inventory check pattern is the key.

Generic “we’ll migrate the data” without addressing deduplication. The 1,200 known duplicates across 3 CRMs require a specific dedup strategy. Judges will ask: “What is your match key? How do you handle Chinese character records? How do you preserve historical order-to-dealer linkages during merge?”

Not addressing legacy portal coexistence. You cannot flip 3,200 US dealers overnight. The solution must include a parallel-run period with the legacy Java portal and a phased dealer migration plan.