Case Study 03: GlobalTrade Logistics — Worked Solution

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

Attempt the Scenario First

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

Assumptions

1. Single global org on Hyperforce EU — delivers unified global account view (Req 2), cross-regional visibility (Req 7), eliminates $4.2M multi-org maintenance. Hyperforce EU (Frankfurt) satisfies GDPR data residency. Rejected multi-org/S2S because bidirectional sync contradicts consolidation goal.
2. Sales Cloud + Service Cloud + Field Service + Experience Cloud + Shield — each product addresses distinct requirements at the scale required (800 warehouse workers, 200 drivers, 35K portal accounts).
3. MuleSoft Anypoint — 40+ carrier APIs, TMS, WMS, customs, ERP, and IoT require middleware with canonical data model and centralized monitoring. Rejected custom integration layer.
4. Big Objects + Data Cloud for LDV — 413M+ tracking events cannot live in standard objects. Hot tier (90 days, ~12M records) in standard objects for sub-3s loads; warm in Big Objects; cold in Data Cloud.
5. FrostGuard stays standalone — ingest 5-minute aggregated readings (720K/day reduced to ~144K) plus real-time excursion alerts via MuleSoft. Meets 2-minute alert SLA (Req 35).

Key Architectural Decisions

Decision 1: Single Global Org on Hyperforce (D1)

Hyperforce on AWS EU (Frankfurt) for data residency. Global users connect via edge network. APAC latency (200-400ms higher) mitigated by UI optimization, CDN caching, and async operations. Trade-off accepted for unified account view and consolidation ROI.

Decision 2: LDV Tiered Storage (D3)

Tier	Data	Storage	Access
Hot	Last 90 days (~12M events)	Standard Custom Object	Real-time, sub-3s
Warm	91 days - 2 years (~100M)	Big Objects	Async SOQL
Cold	2-5 years (~300M)	Data Cloud (external lake)	Analytics, compliance

Nightly Schedulable Apex batch migrates hot to warm at 90-day boundary using Database.insertImmediate() with 10K-record checkpoint batches. If the job falls behind, hot tier grows temporarily (degrades queries but no data loss). Monitor alert triggers if hot tier exceeds 15M records. Shipment summary and milestone dates denormalized on Shipment record for instant agent access.

Decision 3: API-Led Connectivity (D5)

• System APIs: One per external system — abstracts vendor protocol and format
• Process APIs: Orchestrate multi-system flows (e.g., “Book Shipment” calls TMS + carrier + creates SF record)
• Experience APIs: Tailored for consumers (Salesforce, portal, mobile)

Carrier canonical model: Single normalized Canonical Shipment Event schema. Each carrier gets a thin system API translating native format. New carrier = one system API, zero changes to Salesforce or process layers. Top 10 carriers (80% volume) migrate in Phase 1; remaining 30 over 12 months.

Decision 4: Multi-Region Sharing (D2)

• Account OWD: Private. Enterprise Territory Management with 18 country territories in 3 regional models.
• Global accounts (4,200): Criteria-based sharing rule where GlobalAccount__c = true shares with Public Group containing regional director roles and their subordinates. Territory-based user groups cannot be directly targeted by criteria-based sharing rules — Public Group is the correct mechanism.
• Restriction Rules: Sensitive data (hazmat, denied-party, pharma cold-chain) requires “Sensitive Shipment Data” permission set (Req 29).
• Portal: Sharing sets scoped via Account Contact Relationship.

Artifact 1: System Landscape

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

    subgraph SF["Salesforce Global Org — Hyperforce EU"]
        SC[Sales + Service Cloud]
        FS[Field Service]
        EC[Experience Cloud Portal<br/>35K accounts]
        Shield[Shield — Encryption + Audit]
        DC[Data Cloud — Cold Tier]
        CRMA[CRM Analytics]
    end

    subgraph MW["MuleSoft Anypoint — API-Led"]
        EXP[Experience APIs]
        PROC[Process APIs]
        SYS[System APIs]
    end

    subgraph EXT["External Systems"]
        TMS[BluJay TMS]
        WMS[Manhattan WMS]
        CUST[Descartes Customs]
        SAP[SAP S/4HANA]
        FG[FrostGuard IoT]
        P44[Project44]
        TW[Twilio]
    end

    subgraph CARR["40+ Carrier APIs"]
        C1[FedEx / UPS / DHL]
        C2[Maersk / MSC / CMA CGM]
        C3[Air + Regional Carriers]
    end

    subgraph ID["Identity"]
        ENTRA[Entra ID]
    end

    subgraph RET["Retiring"]
        NAORG[NA Salesforce Org]
        EUORG[EU Salesforce Org]
        APORG[APAC Salesforce Org]
        FMKR[FrostLine FileMaker]
        SAPO[SAP ECC 6.0 — EU]
    end

    SF <-->|"REST / Bulk API"| MW
    EC -->|"REST"| EXP
    EXP --> PROC
    PROC --> SYS
    SYS <-->|"REST bidirectional"| TMS
    SYS <-->|"REST webhooks within 5 min"| WMS
    SYS <-->|"SOAP sync sub-5s"| CUST
    SYS <-->|"OData bidirectional"| SAP
    SYS <--|"MQTT 5-min aggregated + excursion alerts"| FG
    SYS <--|"REST webhook real-time"| P44
    SYS -->|"REST fire-and-forget"| TW
    SYS <-->|"REST canonical model"| CARR
    ENTRA -->|"SAML 2.0 SSO + SCIM lifecycle"| SF
    DC -->|"Analytics queries"| CRMA
    NAORG -.->|"Migrating to global org"| SF
    EUORG -.->|"Migrating to global org"| SF
    APORG -.->|"Migrating to global org"| SF
    FMKR -.->|"CSV extract + cleanse"| SF
    SAPO -.->|"Replaced by S/4HANA"| SAP

    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,SC,FS,EC,Shield,DC,CRMA sfSystem
    class MW,EXP,PROC,SYS integrationLayer
    class TMS,WMS,CUST,SAP,FG,P44,TW keepSystem
    class CARR,C1,C2,C3 keepSystem
    class ENTRA keepSystem
    class NAORG,EUORG,APORG,FMKR,SAPO retireSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 retireSystem
    class L4 integrationLayer

Artifact 2: Data Model

erDiagram
    ACCOUNT ||--o{ SHIPMENT : ships
    ACCOUNT ||--o{ QUOTE : requests
    ACCOUNT ||--o{ CONTACT : has
    SHIPMENT ||--o{ TRACKING_EVENT : generates
    SHIPMENT ||--o{ SHIPMENT_LEG : contains
    SHIPMENT ||--o{ SHIPMENT_DOCUMENT : attached
    SHIPMENT ||--o{ TEMPERATURE_LOG : monitored_by
    SHIPMENT ||--o{ CUSTOMS_RECORD : cleared_by
    SHIPMENT }o--|| QUOTE : originates_from
    SHIPMENT_LEG }o--|| CARRIER : handled_by
    TEMPERATURE_LOG ||--o{ TEMP_EXCURSION : triggers
    CASE ||--o{ SHIPMENT : relates_to

    ACCOUNT {
        boolean GlobalAccount
        string DataResidencyRegion
        picklist Region
    }
    SHIPMENT {
        string ShipmentNumber
        picklist Mode "Ocean / Air / Ground"
        picklist Status
        boolean ColdChain
        string ExternalTMSId
    }
    TRACKING_EVENT {
        datetime EventTimestamp
        picklist EventType
        string Location
        string CarrierRef
    }
    TEMPERATURE_LOG {
        decimal Temperature
        decimal MinThreshold
        decimal MaxThreshold
        boolean ExcursionFlag
    }

• Shipment is the central object; all tracking, documents, customs, and temperature data reference it.
• Tracking Event uses hot/warm/cold tiering. Standard custom object holds 90 days; Big Object mirrors schema for warm tier.
• Temperature Log stores 5-minute aggregated readings (not raw 60-second). Only cold-chain shipments populate this.
• ObjectTerritory2Association (standard SF object) links Accounts to Territory2 records.

Artifact 3: Role Hierarchy & Sharing Model

graph TB
    CEO --> COO
    CEO --> CISO
    CEO --> CIO
    COO --> NADir["NA Director"]
    COO --> EUDir["EU Director"]
    COO --> APDir["APAC Director"]
    COO --> CCDir["Cold-Chain Director"]
    NADir --> NASales["NA Sales Mgr"]
    NADir --> NAOps["NA Ops Mgr"]
    NADir --> NASvc["NA Service Mgr"]
    NASales --> NASR["NA Sales Reps"]
    NASvc --> NAAgent["NA Agents"]
    NAOps --> NAField["NA Field Workers"]
    EUDir --> EUSales["EU Sales Mgr"]
    EUDir --> EUOps["EU Ops Mgr"]
    APDir --> APSales["APAC Sales Mgr"]
    APDir --> APOps["APAC Ops Mgr"]
    CCDir --> CCOps["CC Operations"]
    CCDir --> CCComp["CC Compliance"]

Object	OWD	Mechanism
Account	Private	Territory Management (regional) + criteria-based sharing (global accounts)
Shipment	Controlled by Parent	Inherits from Account
Tracking Event	Controlled by Parent	Inherits from Shipment
Case	Private	Assignment rules + queue-based sharing
Quote	Controlled by Parent	Inherits from Opportunity
Temperature Log	Controlled by Parent	Inherits from Shipment
Customs Record	Private	Compliance permission set only

Artifact 4: Integration Architecture

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

    subgraph SF["Salesforce — Hyperforce EU"]
        PE[Platform Events]
        CDC[Change Data Capture]
        BULK[Bulk API 2.0]
    end

    subgraph Mule["MuleSoft Anypoint — API-Led"]
        EXP["Experience APIs"]
        PROC["Process APIs"]
        SYS["System APIs"]
        AQ[Anypoint MQ]
    end

    subgraph ExtSys["External Systems"]
        TMS[BluJay TMS]
        WMS[Manhattan WMS]
        SAP[SAP S/4HANA]
        CUST[Descartes Customs]
        FG[FrostGuard IoT]
        P44[Project44 / CargoSmart]
        TW[Twilio]
        CARR[40+ Carriers]
    end

    PE -->|"Pub/Sub API — outbound events"| EXP
    CDC -->|"Change events — account/shipment changes"| EXP
    EXP -->|"REST / Bulk API — inbound data"| BULK
    EXP --> PROC
    PROC --> SYS
    PROC -->|"Async queue — retry + DLQ"| AQ
    AQ --> SYS
    SYS <-->|"REST bidirectional"| TMS
    SYS <--|"REST webhooks within 5 min"| WMS
    SYS <-->|"OData bidirectional + batch"| SAP
    SYS <-->|"SOAP sync sub-5s"| CUST
    SYS <--|"MQTT 5-min aggregated + alerts"| FG
    SYS <--|"REST webhook real-time"| P44
    SYS -->|"REST fire-and-forget"| TW
    SYS <-->|"REST canonical shipment model"| CARR

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

    class SF,PE,CDC,BULK sfSystem
    class Mule,EXP,PROC,SYS,AQ integrationLayer
    class TMS,WMS,SAP,CUST,FG,P44,TW,CARR keepSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 integrationLayer

System	Pattern	Direction	Protocol
BluJay TMS	Request-Reply + Events	Bidirectional	REST via MuleSoft
Manhattan WMS	Event-Driven	Inbound (within 5 min)	REST webhooks to MuleSoft
SAP S/4HANA	Request-Reply + Batch	Bidirectional	OData via MuleSoft SAP connector
SAP ECC 6.0 (EU)	Request-Reply	Bidirectional	BAPI/RFC via MuleSoft
Descartes	Request-Reply	Outbound (sync, sub-5s)	SOAP via MuleSoft
Project44/CargoSmart	Webhook	Inbound (real-time)	REST to MuleSoft listener
FrostGuard	Event-Driven	Inbound	MQTT to MuleSoft; 5-min aggregated + immediate excursion alerts
40+ Carriers	Canonical Model	Bidirectional	REST via carrier system APIs
Twilio	Fire-and-Forget	Outbound	REST via MuleSoft

FrostGuard detail: MuleSoft subscribes to MQTT topic, aggregates 60-second readings into 5-minute summaries for Temperature Log objects. Excursion alerts bypass aggregation and fire Platform Events immediately (2-minute SLA). Raw data stays in FrostGuard for 180-day retention.

Carrier canonical model: All 40+ carriers map to a single Canonical Shipment Event schema. Adding a new carrier means building one thin system API — zero changes to Salesforce, process APIs, or portal.

Artifact 5: Identity & SSO

• Employees (5,800): Entra ID via SAML 2.0 for auth. SCIM 2.0 via Entra’s Salesforce enterprise application for lifecycle management (create, update, deactivate). Entra groups map to permission set groups for regional access.
• Portal users (35,000 accounts): Salesforce Identity with self-registration + MFA (TOTP/SMS). Enterprise clients can federate via SAML (Salesforce as SP, client IdP authenticates). Connected App per federated client.
• FrostLine (400 employees): JIT provisioning on first Entra login after FrostLine identities migrated to Entra.

Artifact 6: Data Migration Strategy

Phase 1 — Foundation + NA (Months 1-8):

1. Global data model deployed to Hyperforce org (months 1-3)
2. Account/Contact master merge: deduplicate ~35K across 3 orgs + FrostLine using Informatica Cloud (Company Name + Tax ID). NA record is master (most complete). The 2,800 FrostLine overlaps: top 200 by revenue get manual review, rest automated.
3. NA Shipment migration: 14M shipments + 210M tracking events. Hot tier (90 days, ~2.4M events) to standard objects. Warm (90 days-2yr) to Big Objects via Apex batch DML. Cold (2-5yr) to external storage for Data Cloud.
4. NA 180 custom objects rationalized: expect 40% deprecated (unused), 30% mapped to global model, 30% migrated as-is with post-go-live refactoring.
5. Parallel run (months 6-8): exit criteria — 30 days zero discrepancies, all integrations validated, all users trained.

Phase 2 — EU + APAC (Months 6-16): 6. EU Salesforce data migrated months 6-10. ERP integration swap (ECC to S/4HANA) deferred until EU upgrade completes — MuleSoft abstracts (only system API changes, process API unchanged). 7. GDPR records migrated with zero tolerance for missing consent. Zendesk 1.2M tickets to Service Cloud as read-only cases. 8. APAC (months 10-14): APPI compliance via Shield encryption on specific fields. Confirm with Legal whether FISC mandates physical Japan data residency.

Phase 3 — Cold-Chain + Portal (Months 12-22): 9. FrostLine FileMaker CSV export, cleanse, load. 3,500 accounts mapped against global master (2,800 merged in Phase 1). 10. FrostGuard MuleSoft integration built. Portal built and load-tested for 8K concurrent.

Artifact 7: Governance

GARB (Global Architecture Review Board): Bi-weekly. CIO (chair), 3 regional leads, cold-chain lead, SI architect. Reviews cross-region, integration, data model, and security changes.

Regional admin teams (4-5 per region): Local config within guardrails. Regional-only changes need regional lead approval. All changes through CI/CD.

Change Type	Approval	Lead Time
Global schema	GARB	2 sprints
Integration	GARB + integration lead	2 sprints
Regional config	Regional lead	1 sprint
Emergency P1/P2	CIO + regional lead	Same day

Standards: Naming GTL_[Region]_[Object]_[Purpose]. PMD + 85% coverage. No Process Builders. All integrations through MuleSoft.

Artifact 8: Environment Strategy

Environment	Purpose	Refresh
Full Copy	Performance testing (413M+ records) + UAT	Monthly
Partial Copy — NA	Regional UAT	Bi-weekly
Partial Copy — EU	Regional UAT + GDPR testing (masked data)	Bi-weekly
Partial Copy — APAC	Regional UAT	Bi-weekly
Dev Sandbox (x3)	Core / Integration / Cold-Chain teams	Sprint start
Dev Pro Sandbox	SI Partner	Sprint start

Partial Copy sandboxes are a purchased add-on (not included in standard editions). Full Copy required for performance testing at realistic volumes. EU sandbox specifically tests right-to-erasure and consent workflows.

CI/CD: Salesforce CLI + GitHub + GitHub Actions. Branch strategy: main (production), release/* (UAT), feature/* (dev). Promotion: Dev -> Regional Partial -> Full Copy -> Production. No manual deployments.

Artifact 9: Phased Delivery Roadmap

gantt
    title GlobalTrade — 24-Month Delivery
    dateFormat  YYYY-MM
    axisFormat  %b %Y

    section Phase 1 — Foundation + NA
    Global data model + org setup         :p1a, 2026-04, 3M
    MuleSoft + core integrations          :p1b, 2026-04, 5M
    NA data migration                     :p1c, 2026-06, 4M
    NA parallel run + cutover             :p1d, 2026-09, 2M
    NA Go-Live                            :milestone, m1, 2026-11, 0d

    section Phase 2 — EU + APAC
    EU data migration                     :p2a, 2026-10, 4M
    APAC data migration                   :p2b, 2027-01, 4M
    EU Zendesk migration                  :p2c, 2026-11, 3M
    EU + APAC Go-Live                     :milestone, m2, 2027-06, 0d

    section Phase 3 — Cold-Chain + Portal
    FrostLine CRM migration               :p3a, 2027-02, 3M
    FrostGuard IoT integration            :p3b, 2027-03, 4M
    Experience Cloud portal               :p3c, 2027-04, 4M
    Portal load testing (8K concurrent)   :p3d, 2027-07, 2M
    Full Program Complete                 :milestone, m3, 2027-09, 0d

    section Cross-Cutting
    MuleSoft SAP swap (ECC to S4)         :cc1, 2027-02, 4M
    Carrier API consolidation (40+)       :cc2, 2026-06, 12M
    Training + change management          :cc3, 2026-04, 20M

Sequencing rationale: Phase 2 starts before Phase 1 completes (month 6 vs 8) because EU data extraction can begin during NA parallel run. Carrier consolidation spans 12 months — top 10 first by volume. MuleSoft SAP swap sequenced after EU Salesforce migration; abstraction layer means no Salesforce changes — only the system API component updates from ECC BAPI/RFC to S/4HANA OData.

Identity & SSO Flow

sequenceDiagram
    participant EmpBrowser as Employee Browser
    participant Entra as Microsoft Entra ID
    participant SF as Salesforce (Hyperforce EU)
    participant PortalUser as Portal User (Customer)
    participant ClientIdP as Client Corporate IdP
    participant ECID as EC Identity
    participant Portal as Experience Cloud Portal
    participant MuleSoft as MuleSoft (System-to-System)

    rect rgb(230, 240, 255)
    Note over EmpBrowser,SF: Internal Employee SSO (5,800 users — 18 countries)
    EmpBrowser->>Entra: Navigate to Salesforce (SP-initiated)
    Entra->>Entra: Authenticate (password + MFA)
    Entra->>Entra: Map user to Entra groups<br/>(region, BU, function, cold-chain)
    Entra->>EmpBrowser: SAML 2.0 Assertion (Federation ID + region + role)
    EmpBrowser->>SF: POST Assertion to ACS URL
    SF->>SF: JIT Provisioning — set Profile, Perm Set Groups<br/>(regional territory, function, cold-chain access)
    SF->>EmpBrowser: Session (region-scoped access)
    end

    rect rgb(230, 255, 230)
    Note over PortalUser,Portal: Federated Customer Portal (Enterprise Clients)
    PortalUser->>Portal: Navigate to GTL Portal
    Portal->>ClientIdP: SAML redirect (GTL as SP, client as IdP)
    ClientIdP->>ClientIdP: Authenticate via corporate SSO + MFA
    ClientIdP->>Portal: SAML Assertion
    Portal->>Portal: Match to portal user, apply sharing set
    Portal->>PortalUser: Account-scoped dashboard
    end

    rect rgb(255, 245, 230)
    Note over PortalUser,Portal: Non-Federated Customer Portal
    PortalUser->>ECID: Login (email + password + MFA TOTP/SMS)
    ECID->>Portal: Authenticated session (Customer Community Plus)
    Portal->>Portal: Sharing set scopes to own Account
    Portal->>PortalUser: Shipment tracking + documents
    end

    rect rgb(245, 235, 250)
    Note over MuleSoft,SF: System-to-System Integration Auth
    MuleSoft->>SF: OAuth 2.0 Client Credentials (per Connected App)
    SF->>MuleSoft: Access token (integration user)
    MuleSoft->>SF: API calls (REST / Bulk / Platform Events)
    end

Identity architecture rationale:

• Entra ID SAML 2.0 for all 5,800 employees across 18 countries. FrostLine’s 400 employees are migrated into Entra (JIT provisioning creates their Salesforce users on first login). SCIM 2.0 handles lifecycle management — user deactivation in Entra automatically deactivates Salesforce user within the SCIM sync interval (default 40 minutes). Entra group membership drives regional territory assignment, business unit, function, and cold-chain access via Permission Set Groups.
• Portal user authentication (35,000 accounts): Two paths. Large enterprise clients federate via their own SAML IdP — Salesforce acts as SP with a Connected App per federated client. This supports Req 28 (client IdP federation). Smaller clients use Salesforce Identity with self-registration + MFA (TOTP or SMS). All portal users authenticate with MFA regardless of path.
• System-to-system integration via OAuth 2.0 Client Credentials on Named Credentials. Each integration target (TMS, WMS, SAP, Descartes, FrostGuard, Project44, Twilio, 40+ carriers) has its own Connected App with scoped permissions. MuleSoft manages the token lifecycle and rotation. Carrier APIs use varied auth mechanisms (API key, OAuth, basic auth) — MuleSoft’s system API layer abstracts these into a consistent internal auth model.
• Data residency and SSO: Hyperforce EU (Frankfurt) hosts the org. Entra ID authenticates globally — SAML assertions route to the EU ACS URL regardless of user geography. APAC users experience 200-400ms additional latency on login but this is a one-time cost per session. Session timeout: 8 hours for office users, 4 hours for mobile (warehouse/driver).
• Field operations (warehouse + drivers): 800 warehouse workers and 200 drivers access Salesforce Field Service via mobile. Warehouse iPads use managed app deployment; drivers use BYOD with Salesforce Mobile container. Both require Entra SSO + MFA. Offline sessions re-authenticate on connectivity restoration if session has expired.

Integration Error Handling

The scale (920,000 events/day across 40+ carrier APIs) demands robust error handling with automated recovery and clear escalation paths.

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
BluJay TMS (bidirectional)	Request-Reply + Events	Exponential backoff: 30s, 2m, 10m. Max 5 retries per request. Anypoint MQ buffers events during TMS downtime	Anypoint MQ DLQ for failed booking confirmations and status updates. Correlation ID links SF Shipment to TMS booking ID	Dashboard: booking success rate, sync lag. Alert if >10 failed bookings in 1 hour or sync gap >15 min. PagerDuty escalation for sustained failures	Ops team books shipments directly in TMS (out-of-band). SF Shipment records created manually or via batch catch-up on restoration. Critical: no customer shipments delayed — TMS is operational independently
Manhattan WMS (inbound events)	Event-Driven (webhooks within 5 min)	MuleSoft acknowledges webhook idempotently. On processing failure: retry from Anypoint MQ 3x at 5-min intervals	DLQ for failed warehouse events with facility, event type, and shipment reference. Ops team reviews daily	Alert if event volume drops >30% from rolling average per facility. Alert on DLQ depth >20. Dashboard: events per facility per hour	Warehouse operations continue independently. SF shows “warehouse status pending refresh.” Supervisor visibility (Req 21) temporarily stale. Batch catch-up on restoration
Descartes Customs (SOAP sync)	Request-Reply (sub-5s)	Client-side retry 2x with 5-second timeout. Circuit breaker: opens after 3 consecutive failures in 60 seconds, half-open test every 5 min	No DLQ (synchronous). Failed screening results returned to user as “screening unavailable — manual review required”	Circuit breaker state dashboard. Alert on open circuit. Dashboard: screening volume and average response time	Trade compliance staff perform manual screening via Descartes web portal. Shipments flagged “pending compliance review” in SF — no auto-clearance during outage (regulatory safety)
SAP S/4HANA (OData bidirectional)	Request-Reply + Batch	Real-time: retry 3x with 30s backoff. Batch (nightly 12K+ transactions): chunk-level retry (1K records per chunk), failed chunks retry independently	Anypoint MQ DLQ for failed financial transactions. Finance team reviews next business day. Chunks with GL posting errors held for manual correction	Alert if real-time sync gap >30 min. Alert if nightly batch not complete by 6 AM local time. Dashboard: transaction volume, error rate by type	Financial postings queue in MuleSoft. SF records show “finance sync pending.” No revenue recognition delay >24 hours. During EU ERP swap (months 10-18): MuleSoft system API switches from ECC BAPI/RFC to S/4HANA OData — process API unchanged, zero SF impact
SAP ECC 6.0 (EU legacy)	Request-Reply	Same as S/4HANA but via BAPI/RFC connector	Same DLQ pattern	Same alerting	Replaced by S/4HANA at month 18. MuleSoft system API swap only — transparent to Salesforce
FrostGuard IoT (MQTT + REST)	Event-Driven	MuleSoft MQTT subscriber auto-reconnects on broker disconnect. 5-min aggregated readings: retry from Anypoint MQ 3x. Excursion alerts: immediate retry 3x at 10-second intervals (2-min SLA)	DLQ for failed temperature readings with sensor ID, shipment ID, and timestamp. Excursion alerts that fail to publish Platform Event are escalated to on-call immediately	Alert if any cold-chain shipment has no readings for >15 min (sensor or connectivity issue). Alert if excursion Platform Event not published within 2 min of threshold breach. Dashboard: reading volume per facility, excursion count	FrostGuard dashboard remains independently accessible for cold-chain ops. Temperature alerts route directly from FrostGuard email/SMS as backup. SF shows “temperature data temporarily unavailable” with last-known readings and timestamps
Project44 / CargoSmart (webhooks)	Webhook (real-time)	MuleSoft acknowledges idempotently. Processing failure: retry from Anypoint MQ 3x at 1-min intervals	DLQ for failed tracking events with carrier reference and shipment number	Alert if tracking event volume drops >40% from baseline (may indicate webhook delivery failure). Dashboard: events per carrier per hour	Customer portal shows “tracking update pending” with last-known position. Ops team can query Project44 portal directly for real-time status. Batch catch-up processes DLQ and backfills on restoration
Twilio (outbound SMS)	Fire-and-Forget	Retry 3x at 30-second intervals. Twilio handles downstream delivery retries	Failed SMS written to DLQ with recipient, message body, and shipment reference	Alert if >50 SMS failures in 1 hour. Dashboard: SMS delivery rates, failure reasons	Email notification as fallback channel (already configured). Portal notification as secondary fallback. Customer sees shipment update in portal even if SMS fails
40+ Carrier APIs (canonical model)	Bidirectional REST	Per-carrier retry policy (configurable in MuleSoft): default 3x exponential backoff. Rate limit handling: respect 429 headers; queue excess requests in Anypoint MQ	Per-carrier DLQ. Carrier-specific error codes mapped to canonical error types. New carrier onboarding includes DLQ configuration	Per-carrier health dashboard. Alert if any carrier error rate >5% over 1 hour. Aggregate carrier health score displayed to ops. Alert on rate limit throttling (early warning)	Carrier booking falls back to carrier’s own portal/email (manual). Tracking updates stale until carrier API restores. Top 10 carriers (80% volume) have dedicated escalation contacts

Carrier API Resilience

The canonical model architecture means that a single carrier API failure affects only that carrier’s shipments. All other carriers continue operating normally. MuleSoft’s system API layer isolates failures — no cascade to process APIs or Salesforce. New carrier onboarding includes mandatory DLQ configuration, retry policy, and monitoring threshold setup as part of the integration checklist.

Governance & DevOps

Environment Topology

flowchart LR
    subgraph DevEnvs["Developer Sandboxes"]
        DEV_CORE["DEV Core\n(Dev Sandbox)"]
        DEV_INT["DEV Integration\n(Dev Sandbox)"]
        DEV_CC["DEV Cold-Chain\n(Dev Sandbox)"]
        DEV_SI["DEV SI Partner\n(Dev Pro)"]
    end

    subgraph RegionalTest["Regional UAT Sandboxes"]
        NA_PC["NA UAT\n(Partial Copy)"]
        EU_PC["EU UAT\n(Partial Copy)\nGDPR testing"]
        APAC_PC["APAC UAT\n(Partial Copy)"]
    end

    subgraph PerfTest["Performance & Full UAT"]
        FULL["Full Copy\nPerformance testing\n413M+ record volume"]
    end

    DEV_CORE -->|"PR merge to develop"| NA_PC
    DEV_INT -->|"PR merge to develop"| NA_PC
    DEV_CC -->|"PR merge to develop"| NA_PC
    DEV_SI -->|"PR merge to develop"| NA_PC
    NA_PC -->|"Regional validation"| FULL
    EU_PC -->|"GDPR + regional validation"| FULL
    APAC_PC -->|"Regional validation"| FULL
    FULL -->|"GARB approval +\nregional lead sign-off"| PROD["PRODUCTION\n(Hyperforce EU)"]

    style PROD fill:#d4edda,stroke:#28a745,color:#000
    style NA_PC fill:#fff3cd,stroke:#fd7e14,color:#000
    style EU_PC fill:#dcedc8,stroke:#689f38,color:#000
    style APAC_PC fill:#fff3cd,stroke:#fd7e14,color:#000
    style FULL fill:#cce5ff,stroke:#0d6efd,color:#000

Branching Strategy

Adapted for a globally distributed team across 3 time zones with bi-weekly release cadence:

• main — mirrors production. Only the release manager (CIO-delegated) can merge. Protected branch with required approvals from GARB.
• develop — integration branch. Feature branches merge here via PR after peer review. Auto-deploys to NA UAT (Partial Copy) on merge.
• feature/* — one branch per work item, prefixed by team (feature/core-*, feature/int-*, feature/cc-*). Developer validates in Dev sandbox. 85% Apex coverage + PMD scan enforced at PR gate.
• release/* — cut from develop bi-weekly. Deployed to Full Copy for performance testing and final UAT. Regional leads validate their region’s functionality. Only bug fixes after cut.
• hotfix/* — emergency path. CIO + regional lead approval. Merged to main and develop. Post-hoc GARB review.

Multi-timezone coordination: NA team cuts release branches (Chicago morning = EU afternoon). EU team validates in EU Partial Copy during their morning. APAC validates next. 24-hour follow-the-sun validation cycle before Full Copy promotion.

Sandbox Strategy

Sandbox	Type	Purpose	Data	Refresh
DEV Core	Dev Sandbox	Core platform development	Metadata only (200 MB)	Sprint start
DEV Integration	Dev Sandbox	MuleSoft + carrier API development	Metadata only (200 MB)	Sprint start
DEV Cold-Chain	Dev Sandbox	FrostGuard integration, temperature objects	Metadata only (200 MB)	Sprint start
DEV SI Partner	Dev Pro	SI partner feature development	Metadata only	Sprint start
NA UAT	Partial Copy	NA regional validation	Masked data (NA records)	Bi-weekly
EU UAT	Partial Copy	EU regional + GDPR validation	Masked data (EU records) + GDPR test scenarios	Bi-weekly
APAC UAT	Partial Copy	APAC regional validation	Masked data (APAC records)	Bi-weekly
Full Copy	Full Copy	Performance testing at LDV scale (413M+), cross-region UAT	Full production clone, masked PII	Monthly

Data masking and residency:

• All non-production environments use Salesforce Data Mask post-refresh
• Masked: client company names, contact PII, shipment values, trade compliance details, temperature compliance certificates
• EU sandbox specifically validates GDPR workflows: right-to-erasure, consent withdrawal, data processing records
• APAC sandbox validates APPI/PDPA data handling per jurisdiction
• Full Copy required for performance testing — LDV hot/warm/cold tier behavior can only be validated at realistic volumes (standard Partial Copy insufficient for 413M+ tracking events)

Testing Strategy

Test Type	Target	Environment	Gate
Unit tests (Apex)	>= 85% coverage (PMD static analysis required)	Developer sandbox	PR merge to develop
Integration tests	MuleSoft end-to-end per integration target (TMS, WMS, SAP, carriers, FrostGuard)	Dev Integration + carrier API stubs	Sprint completion
Regional UAT	Region-specific workflows, language validation, regulatory compliance	Regional Partial Copy (NA/EU/APAC)	Regional lead sign-off
Performance tests	LDV: sub-3s shipment page loads with 12M hot-tier records; nightly batch hot-to-warm migration; 8K concurrent portal users; 920K events/day integration throughput	Full Copy	GARB sign-off
GDPR compliance tests	Right-to-erasure, consent tracking, data processing logs, cross-border transfer controls	EU Partial Copy	EU Director + CISO sign-off
Carrier API integration tests	Canonical model validation for each carrier; rate limit behavior; error handling per carrier	Dev Integration with carrier sandboxes	Integration lead sign-off
Cross-region regression	Global account visibility, territory sharing, no cross-region data leakage, cold-chain restriction rules	Full Copy	GARB

Process Builder migration testing: NA org has 420 Process Builders (retired by Salesforce). Migration to Flows is tested in NA Partial Copy with a dedicated test suite comparing before/after behavior for each converted Process Builder. No Process Builders deployed to the global org.

CoE & Ongoing Governance

Global Architecture Review Board (GARB):

• Composition: CIO (chair), NA Director, EU Director, APAC Director, Cold-Chain Director, SI lead architect
• Bi-weekly during implementation; monthly post-go-live
• Reviews: cross-region changes, integration additions, data model modifications, security configurations, carrier API onboarding

Regional admin teams (15 total across 3 regions + cold-chain):

Region	Admin/Dev Count	Responsibility
NA	5	NA configuration, NA carrier integrations, SAP S/4HANA coordination
EU	4	EU configuration, GDPR compliance, SAP ECC-to-S/4HANA swap
APAC	3	APAC configuration, local ERP integrations, APPI/PDPA compliance
Cold-Chain	3 (from FrostLine IT)	FrostGuard integration, temperature monitoring, FDA/MHRA/TGA compliance

SI partner (Big Four, 35 people): Handles build during Phase 1-2, transitions to advisory in Phase 3. Knowledge transfer plan: each SI consultant paired with an internal team member from month 1. SI exits at month 22 with 2-month hypercare overlap.

Standards enforced globally:

• Naming: GTL_[Region]_[Object]_[Purpose] (e.g., GTL_EU_Shipment_GDPRConsent)
• PMD static analysis + 85% Apex test coverage at every PR
• No Process Builders — all automation via Flows or Apex
• All integrations through MuleSoft — no direct Apex callouts to external systems
• Carrier onboarding checklist: system API, canonical mapping, DLQ config, monitoring, rate limit profile

Release cadence:

• During implementation: 2-week sprints; bi-weekly releases to production after GARB approval
• Post-go-live: Bi-weekly releases (Req 37). Each release includes: regional Partial Copy validation, Full Copy regression, GARB approval. Emergency releases: same-day with CIO + regional lead approval.
• Max 2-hour downtime constraint (Req 6 in constraints): All deployments use quick deploy (pre-validated test results) to minimize deployment window. Metadata-only changes deployed during low-traffic hours (Saturday 2-6 AM UTC). Data migrations use Bulk API during batch windows.

Ongoing operations:

• MuleSoft Anypoint Monitoring: carrier health dashboard, integration SLA tracking, error rate by system
• Shield Event Monitoring: data access audit per GDPR/APPI/PDPA requirements
• LDV health monitoring: hot-tier record count alert (>15M triggers investigation), warm-tier migration job monitoring
• Quarterly platform review: storage trending across tiers, API consumption by region, sharing model performance at scale
• Annual GDPR audit: data processing record review, right-to-erasure compliance, cross-border transfer documentation

Reporting Approach

CRM Analytics provides the global operations dashboard (Req 22) with 4-hour refresh from Salesforce + MuleSoft data sources (shipment volumes by region/mode, on-time rates, exception rates, revenue per shipment). Finance quote-through-invoice reconciliation (Req 23) queries SAP OData feeds via MuleSoft experience APIs. Regional compliance dashboards (Req 24) pull GDPR processing logs from Shield Event Monitoring, trade screening results from Descartes integration data, and temperature compliance records from FrostGuard. LDV tracking event analytics query Data Cloud cold tier for historical trend reporting without impacting transactional performance.

Presentation Strategy

In 30 minutes, go deep on three decisions: (1) LDV tiered storage — make-or-break technical risk, (2) carrier API canonical model — integration mastery, (3) multi-region sharing with data residency — security depth. Cover remaining artifacts at summary level.