Case Study 3: GlobalTrade Logistics - 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, Data, Integration, and Governance
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 global org on Hyperforce EU with Japan split-org fallback: 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. If FISC or APPI evidence requires physical Japanese residency, a separate Japan org on Hyperforce Japan (generally available on AWS Osaka since 2023) handles Japan-only records with MuleSoft bridging cross-border shipments. Rejected monolithic multi-org 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 + external data lake for LDV: 413M+ tracking events cannot live in standard objects. Hot tier (90 days, ~12M records) in standard objects for sub-3s loads; warm tier in Big Objects with platform-enforced access; cold tier in AWS S3 + Athena federated via Salesforce Connect (OData) and CRM Analytics External Data connectors. Data 360 is not a cold archive store and is reserved for real-time profile unification and segmentation use cases.
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 54) and supports immediate escalation workflows (Req 16).

Key Architectural Decisions

Decision 1: Hyperforce EU Primary with Japan Split-Org Fallback (D1)

Hyperforce on AWS EU (Frankfurt) is the primary region for 16 of 18 countries. Global users connect via edge network. APAC latency (200-400ms higher) mitigated by UI optimization, CDN caching, and async operations.

Japan data residency decision tree (committed):

Regulatory finding	Architecture	Cost delta
APPI contractual safeguards only	Single Hyperforce EU org; Japanese PII encrypted at rest with tenant-managed keys stored in Japan via BYOK. Data physically in Frankfurt.	Baseline
FISC or critical-infrastructure classification triggers physical residency	Separate Japan org on Hyperforce Japan (Osaka). 1,200 APAC users and Japan-headquartered accounts provisioned in Japan org. MuleSoft bridges cross-border shipments via bidirectional sync on Account, Shipment, Tracking Event. Global reporting consolidated in CRM Analytics federated queries.	+$420K/year license + $180K one-time integration build

Shield Platform Encryption does not change the physical storage location. Encryption with tenant keys protects data at rest and in motion; it is not a residency substitute. Legal confirms the APPI finding before Phase 2 design lock (month 6); the split-org fallback is budgeted in the contingency line and pre-scoped with Salesforce account team during Phase 1.

Decision 2: LDV Tiered Storage (D3)

Tier	Data	Storage	Access
Hot	Last 90 days (~12M events)	Standard Custom Object	Real-time SOQL, sub-3s page load
Warm	91 days - 2 years (~100M)	Big Objects (Tracking_Event_Archive__b)	Standard SOQL on indexed fields (ShipmentExternalId + EventTimestamp), Bulk API 2.0 for extraction
Cold	2-5 years (~300M)	AWS S3 + Athena data lake	Salesforce Connect (OData) for on-demand point lookups from UI, CRM Analytics External Data for trend analytics

Why not Data 360 for the cold tier: Data 360 is a real-time customer data platform for profile unification, segmentation, and activation. Billing is credit-based on ingestion events, identity resolution, and activations rather than archival storage volume. For 300M transactional tracking events queried for regulatory audit (point lookups by ShipmentId and date range), S3 at roughly $0.023/GB plus Athena at $5/TB scanned is an order of magnitude cheaper than Data 360 credits, and the Data 360 Salesforce CRM connector does not ingest Big Objects so a tier handoff from warm Big Objects to Data 360 cold would require a separate MuleSoft extraction pipeline anyway. Data 360 stays in the architecture for its intended purpose: unified customer profile scoring for the Experience Cloud portal and CRM Analytics real-time segmentation.

Warm to cold handoff: MuleSoft batch extracts Big Object partitions older than 2 years via Bulk API 2.0, writes Parquet files to S3 partitioned by year/month/shipment-prefix, and registers partitions in Athena. The Big Object records are then deleted via Database.deleteImmediate() in batches of 2,000.

Hot to warm handoff: Nightly Schedulable Apex batch migrates hot events crossing the 90-day boundary using Database.insertImmediate() with a scope size of 2,000 records per execute method (the maximum for Batch Apex). For the one-time NA historical backfill of 210M events, Bulk API 2.0 ingest jobs run against the Big Object through MuleSoft rather than Apex batch DML — Apex batch DML at 2,000 records per execute would require 105,000 executions and is the wrong tool for a one-time load. If the nightly job falls behind, the hot tier grows temporarily (degrades queries but no data loss). Monitor alert triggers if hot tier exceeds 15M records. Shipment summary and milestone dates are denormalized on the Shipment record for instant agent access without reaching into Tracking Event at all.

Big Object security model (important nuance): Big Objects do not participate in the sharing model. Access is controlled exclusively by object and field permissions on the user’s profile and permission sets. There is no Controlled by Parent, no sharing rules, no row-level OWD. For the Shipment_Timeline__b warm tier, the security boundary is: (1) portal users do not have the Big Object object permission at all and cannot query the warm tier directly — their “Load Full History” experience is fulfilled by a brokered Apex action that enforces account ownership in server-side logic before returning the filtered event list; (2) internal agents have Big Object read permission on a “Tracking History Reader” permission set, and the same server-side Apex filter enforces territory scope on the Shipment parent before returning events.

Big Object 200-row sync SOQL limit and the Load Full History UX: SOQL queries against Big Objects from synchronous Apex return a maximum of 200 rows per query. For an ocean shipment with 50+ events across 18 months, a naive SELECT would truncate. The Load Full History button invokes a two-path design: (1) up to 200 rows per page via synchronous SOQL with query locators for UI-tier paging, or (2) for shipments exceeding the page threshold, the button enqueues an Async SOQL-style Batch Apex job that writes the full result set to a Platform Event; the LWC subscribes and renders the complete timeline when the event fires. Typical end-to-end time is 5-10 seconds per shipment.

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 one active Territory Model containing three regional parent territories (NA, EU, APAC) and 18 country leaf territories nested underneath. Salesforce allows only one active Territory Model per org at a time; additional models exist only in Planning or Archived state. The cold-chain team is represented by a parallel role hierarchy branch under the COO, not by a separate Territory Model.
• Shipment, Tracking Event, and related custom objects (26M+ rows): Enterprise Territory Management supports only Account, Opportunity, Case, and Lead standard objects, so it cannot be applied directly to custom Shipment. Shipment OWD is Private with sharing enforced by criteria-based sharing rules matched to the Shipper Account’s territory assignment, supplemented by Apex Managed Sharing on the Consignee Account path. Controlled by Parent is explicitly rejected because a master-detail chain from 26M Shipments up to 35K Accounts averages 740 children per parent with top accounts exceeding 50K children, which triggers parent-child data skew under the Salesforce 10K threshold and causes sharing recalculation storms on any bulk operation. Tracking Event, Shipment Leg, Temperature Log, and Shipment Document all use lookup-only relationships to Shipment with the hot tier on Private OWD and the warm tier on Big Objects (no sharing model at all).
• Global accounts (4,200): Criteria-based sharing rule where GlobalAccount__c = true shares with role-and-subordinates groups for the three regional directors. “Relevant regional teams” is defined by a Global_Account_Regions__c multi-select field on Account that lists which regions actually touch the account; the sharing rule evaluates this field before sharing, so a global account with only NA and EU operations does not leak to APAC. The field is maintained by the Global Account Manager role and audited quarterly.
• Restriction Rules (correct mechanics): Shipment OWD is Private. A Restriction Rule on Shipment filters records OUT of users who do NOT hold the “Sensitive Shipment Data” custom permission (delivered via the Sensitive Shipment Data permission set group). Restriction Rules do not grant access — they reduce what a user can see when criteria match. The rule’s userCriteria expression is $Permission.Sensitive_Shipment_Data_Access = false and the recordCriteria matches IsHazmat__c = true OR DeniedPartyHit__c = true OR PharmaColdChain__c = true. Users with the permission set are unaffected; users without it see the matching records hidden from list views, reports, SOQL queries, and API responses. Restriction Rules are supported on custom objects such as Shipment since Winter ‘22 GA (Beta in Summer ‘21) (Req 46).
• Portal licensing and sharing: Customer Community Plus licenses for the 35,000 accounts. Customer Community Plus supports role hierarchy (up to three portal roles per account), which is required for the Admin/Operations/Finance differentiation. External Apps and External Apps Login are separate HVPU license families that do NOT support role hierarchy and therefore cannot enforce the three-role model — they are rejected for this requirement. Login-based licensing is applied to occasional users and member-based to the roughly 300 top-tier enterprise accounts whose portal users log in daily; the licensing line is confirmed with the Salesforce account team during Phase 1 contracting.
• Sharing Sets (correct mechanics): Sharing Sets grant portal users access to records whose Account lookup matches the portal user’s own Account (or Contact’s Account). Specifically: Shipment.Shipper_Account__c = $User.AccountId OR Shipment.Consignee_Account__c = $User.AccountId. Sharing Sets key off the user’s Account or Contact fields directly; they do not rely on the AccountContactRelation junction. The portal user sees the shipment through either party context. Shipment Document, Tracking Event (hot tier), Temperature Log, and Quote all inherit the sharing set via their lookup to Shipment, so a portal user’s view stays scoped to shipments touching their own account.
• Three portal roles per account use permission sets rather than the role hierarchy for field-level and action-level differentiation: Admin (manage users, view all account shipments, download compliance bundles), Operations (track shipments, upload documents, view temperature data), Finance (view quotes, invoices, payment status). Role assignment via portal self-registration with an account-admin approval Flow (custom; Salesforce does not provide self-registration role gating natively).
• Account Role Optimization (ARO): Enabled to mitigate the role-explosion performance hit of 35K accounts × 3 portal roles = 105K role rows on the underlying UserRole table. ARO was introduced in Spring ‘22 for role-based Experience Cloud licenses; without it, the 35K-account scale on Customer Community Plus runs into sharing recalculation latency and login storm performance issues. Enabled via Setup before portal go-live.

Decision 5: Proactive Exception Management (Req 11, 12)

Four exception categories with automated detection and escalation:

Exception Type	Detection Source	Trigger	Escalation
Late shipment	Project44/CargoSmart tracking vs. ETA	ETA exceeded by >2 hours	Auto-case creation, client notification via Twilio, assigned to regional ops
Routing deviation	Carrier tracking vs. planned route	Shipment deviates >50km from planned corridor	Alert to ops manager, client notification if delivery impact
Customs hold	Descartes screening + carrier status	Hold duration >4 hours	Escalate to trade compliance team, client notification with hold reason
Temperature excursion	FrostGuard via MuleSoft	Reading outside threshold for >5 minutes	Platform Event, immediate case, client + carrier + compliance notified within 2 minutes

All exceptions create Case records linked to the Shipment with exception type, detection timestamp, resolution SLA, and root cause field. CRM Analytics exception dashboard tracks open exceptions by region, type, and aging.

Decision 6: Mobile and Field Operations (Req 27-33)

Field Service vs Salesforce mobile app rationale: Salesforce’s Briefcase Builder makes offline access available in the Field Service Mobile App and in the standard Salesforce mobile app with a Mobile App Plus license (a paid add-on). The choice between them is driven by the service domain model: warehouse pick/pack/ship and driver delivery routes map naturally onto WorkOrder, ServiceAppointment, ServiceResource, and ServiceTerritory, which are first-class Field Service objects with dispatch, routing, and crew scheduling support. Those same workflows could be rebuilt on custom objects with the standard mobile app, but at the cost of rebuilding dispatching, crew assignment, skills matching, and reporting. Field Service is chosen for the native service data model fit, not because it is the only path to offline.

Field Service data model for GTL:

• Service Territories: One per warehouse facility (12 total) plus one per delivery region for drivers.
• Service Resources: 800 warehouse workers and 200 drivers modeled as ServiceResource records with skills (cold-chain certified, hazmat certified, forklift, last-mile delivery).
• Work Types: Pick-pack-ship, inventory cycle count, receiving inspection, damage documentation, delivery, proof-of-delivery capture.
• Work Orders and Service Appointments: Generated from Shipment on status transitions. Dispatcher Console assigns to resources based on territory and skills.

Warehouse workers (800 across 12 facilities):

• Salesforce Field Service on company-managed iPads using the Field Service Mobile App with Briefcase Builder for admin-configured priming (facility-level work orders and shipment staging) plus automatic priming of assigned work orders
• Offline data scope: assigned facility’s open work orders, inventory counts (ProductItem), and shipment staging records (typically 500-2,000 records per device)
• Sync frequency: every 15 minutes when connected; full sync on shift start
• Key workflows: pick/pack/ship confirmation, inventory cycle counts, receiving inspection, damage documentation (photo capture)
• Intermittent connectivity at port terminals handled by store-and-forward: actions queue locally and sync on next connection

Drivers (200, BYOD):

• Field Service Mobile App on personal iOS/Android devices using the standard automatic offline priming of assigned Work Orders and Service Appointments for the day’s route (Briefcase is optional here — the native FSM offline cache covers the “today’s deliveries” pattern)
• Mobile Device Management (MDM) via Microsoft Intune for container-level data protection on BYOD devices
• Offline scope: assigned deliveries for the current day, route details, customer contact info (~50-100 records)
• Key workflows: delivery confirmation, proof of delivery (photo + digital signature capture), exception reporting, route deviation notes
• Offline conflict resolution: last-write-wins for status fields; photo/signature uploads are append-only (no conflict possible)
• Session timeout: 4 hours (shorter than office users) with re-authentication via Entra SSO on reconnect

Decision 7: Document Management (Req 22-23)

6M documents/year across bills of lading, air waybills, commercial invoices, customs declarations, certificates of origin, dangerous goods declarations, temperature compliance certs, and proof of delivery.

• Storage: Salesforce Files for active shipment documents (last 12 months). Documents older than 12 months archived to Amazon S3 via MuleSoft with metadata reference retained in Salesforce (Shipment_Document record links to S3 presigned URL).
• Upload: Portal users and internal ops upload via Shipment_Document related list. MuleSoft virus scan on upload. File type validation (PDF, JPG, PNG, TIFF only).
• Download: Single-document download from Shipment record. “Download Document Bundle” button generates a ZIP of all documents for a shipment via MuleSoft experience API. Portal users can download bundles for their own account’s shipments only (enforced by sharing set).
• Compliance bundles: Trade compliance documents grouped per shipment per jurisdiction. Regulatory auditors access via a read-only compliance portal view with time-limited access links.
• Retention: 7 years for trade compliance documents (regulatory requirement). 5 years for standard shipping documents. Automated archival batch runs monthly.

Decision 8: Self-Service Quoting (Req 21)

Portal users with the Finance role request quotes through a guided LWC flow on the Experience Cloud portal:

1. Select origin/destination, mode (ocean/air/ground), cargo type, temperature requirements (if cold-chain), and estimated volume
2. Flow calls MuleSoft experience API, which queries carrier system APIs for rate quotes (top 3 carriers by historical reliability for that lane)
3. Rates displayed with transit time estimates and service level options
4. Client selects preferred option; Quote record created in Salesforce linked to Account and Opportunity
5. Internal sales rep reviews and approves (or adjusts) within SLA (4 business hours for standard, 1 hour for cold-chain)
6. Approved quote generates a PDF via document generation and notifies the client via portal notification + email

For FrostLine’s existing Excel-based pricing: pricing matrices migrated to Custom Metadata Types. Cold-chain surcharges calculated dynamically based on temperature range, shipment duration, and regulatory requirements.

Decision 9: Per-Account Portal Branding (Req 26)

Experience Cloud does not support per-account branding on a single site out of the box — Themes and CMS content apply at the site level. Three options with trade-offs:

Approach	Mechanism	Effort	Trade-off
Single site + dynamic header LWC	Custom LWC reads Branding_Logo__c and Branding_Primary_Color__c from the portal user’s Account and overrides the header banner, footer, and primary button color via CSS custom properties	Low	Main Experience Cloud theme applies; only header/footer/CTA colors can swap per account; rest of the portal stays GTL-branded
Digital Experience Theme per tier	Build three Experience Cloud Themes (Standard / Enterprise / Cold-Chain). Apply via Theme assignment at session start based on account tier	Medium	Three themes is manageable; does not offer true per-account branding, only per-tier
Multi-site Experience Cloud	One Experience Cloud site per top-tier enterprise account	High	Supports true per-account themes; adds site maintenance overhead and multiplies content sync burden. Rejected because 35K sites is not feasible, and a top-20-enterprise-accounts variant would still require 20 parallel sites

Chosen: Single site + dynamic header LWC for all 35K accounts, with the header LWC reading Branding_Logo__c, Branding_Primary_Color__c, and Branding_Secondary_Color__c fields on the portal user’s Account. Only the top-tier enterprise accounts (estimated 300) populate custom branding fields; the rest default to GTL’s global theme. Branding assets (logos) live in a dedicated Account_Branding Content Workspace with jurisdictional access controls.

Decision 10: Data Classification and Jurisdictional Tagging (Req 48)

Salesforce Data Classification is operationalized at the field level with three required metadata tags applied by every field created in the global data model:

• Compliance Categorization picklist: GDPR PII, APPI PII, PDPA PII, Trade Compliance, Financial, Operational, None.
• Data Sensitivity Level picklist: Public, Internal, Confidential, Restricted.
• Data Owner lookup: the business role accountable for the field’s data (regional Director, CISO, Trade Compliance Lead).

The tags drive four downstream systems:

1. GDPR right-to-erasure workflow: Privacy Center policies query fields tagged GDPR PII and delete or anonymize them on a subject-access request.
2. Shield Platform Encryption policies: All fields tagged APPI PII or Confidential-or-above receive deterministic or probabilistic encryption based on query pattern needs.
3. Cross-border transfer logs: Shield Event Monitoring filters access to GDPR PII or APPI PII fields by user geography and writes a transfer log for the CISO’s quarterly review.
4. Sandbox masking rules: Salesforce Data Mask post-refresh scripts mask any field tagged GDPR PII, APPI PII, PDPA PII, or Financial before allowing the sandbox to open for regional UAT.

Governance: the GARB reviews every new field at the PR gate and rejects any field that lacks all three tags.

Artifact 1: System Landscape

Figure 1. System landscape for GlobalTrade Logistics showing three retiring regional Salesforce orgs and the FrostLine acquisition consolidating into a single Hyperforce EU org, with MuleSoft API-led connectivity providing a canonical integration layer for 40-plus carrier APIs and all operational systems.

Artifact 2: Data Model

Figure 2. Data model for GlobalTrade Logistics with Shipment as the central object linking legs, tracking events, temperature logs, customs records, documents, and Field Service execution. Shipment carries both Shipper_Account__c and Consignee_Account__c lookups so the shipper and consignee parties both have visibility context. Tracking Event is a critical LDV object requiring hot/warm/cold tiered storage to handle 42-56 million new records per year.

• Shipment is the central object. It carries both a Shipper_Account__c lookup and a Consignee_Account__c lookup — a cross-border shipment from a German shipper to a Japanese consignee lives on one Shipment record that both the NA/EU Shipper rep and the APAC Consignee rep see through their respective account relationships. A Shipment_Party__c junction could be used instead for shipments with multiple notify parties or bill-to accounts, but the dual-lookup pattern covers the two-party case with simpler joins and faster portal queries.
• Shipment OWD is Private (not Controlled by Parent). Controlled by Parent is rejected because (a) master-detail from Shipment to Account creates parent-child data skew at top accounts exceeding 10K children, and (b) Controlled by Parent does not provide a mechanism to share a single shipment with both the shipper account’s territory and the consignee account’s territory — two independent sharing grants are required. Sharing is implemented via a criteria-based sharing rule on the Shipper territory plus Apex Managed Sharing injected on the Consignee territory at save time.
• Tracking Event uses hot/warm/cold tiering. The hot tier is a standard custom object with a lookup (not master-detail) to Shipment; a sharing rule matches the Shipment’s access model via Apex Managed Sharing to avoid master-detail’s sharing recalc cost at 395M rows. The warm tier is a Big Object which has its own object/field permission model (no row-level sharing); access is brokered through Apex with explicit account ownership checks.
• Shipment Document wraps ContentDocument and ContentDocumentLink — actual files live in Salesforce Files, and Shipment_Document__c carries the metadata (document type, jurisdiction, retention date). The sharing set on Shipment_Document propagates via the Shipment lookup.
• Temperature Log stores 5-minute aggregated readings (not raw 60-second). Only cold-chain shipments populate this.
• Field Service objects (WorkOrder, ServiceAppointment, ServiceResource, ServiceTerritory, ProductItem) are standard Field Service objects used for warehouse and driver workflows; they are not custom.
• Quote is the standard Salesforce Quote object (Sales Cloud), not a custom object. It uses the native Controlled by Parent OWD to Opportunity which Sales Cloud provides out of the box.
• ObjectTerritory2Association (standard SF object) links Accounts to Territory2 records in the single active Territory Model.

Artifact 3: Role Hierarchy & Sharing Model

Figure 3. Role hierarchy for GlobalTrade Logistics showing three regional director branches (NA, EU, APAC) and a dedicated cold-chain branch for the FrostLine acquisition, with Enterprise Territory Management providing account-level access scoping across one active Territory Model containing three regional parents and 18 country leaf territories.

Object	OWD	Mechanism
Account	Private	Enterprise Territory Management (single active model, 3 regional parents + 18 country leaves) + criteria-based sharing (global accounts, scoped by Global_Account_Regions__c)
Shipment	Private	Criteria-based sharing rule on Shipper territory + Apex Managed Sharing for Consignee territory + Sharing Set for portal access on Shipper or Consignee Account match
Tracking Event (hot)	Private	Apex Managed Sharing mirrors Shipment access; lookup (not master-detail) to avoid parent-child skew at 50+ events per shipment
Tracking Event (warm)	N/A (Big Object)	Object/field permission on “Tracking History Reader” permission set; account ownership enforced in brokered Apex read action
Shipment Leg	Private	Sharing rule matches Shipment
Shipment Document	Private	Sharing Set inherits from Shipment via ContentDocumentLink
Case	Private	Assignment rules + queue-based sharing
Quote (standard object)	Controlled by Parent (native)	Inherits from Opportunity natively — Quote is the standard Sales Cloud object
Temperature Log	Private	Sharing rule matches Shipment
Customs Record	Private	Compliance permission set only

Restriction Rules (correct mechanics): The Shipment OWD is Private. A Restriction Rule on Shipment filters records OUT of users who do NOT hold the Custom Permission Sensitive_Shipment_Data_Access (delivered via the Sensitive Shipment Data permission set group). userCriteria is $Permission.Sensitive_Shipment_Data_Access = false and recordCriteria is IsHazmat__c = TRUE OR DeniedPartyHit__c = TRUE OR PharmaColdChain__c = TRUE. Users with the permission see all Shipments (including sensitive ones); users without it see the sensitive Shipments hidden from list views, reports, SOQL queries, Lightning pages, and API responses. Restriction Rules do not grant access, they subtract it.

Artifact 4: Integration Architecture

Figure 4. Integration architecture for GlobalTrade Logistics showing the three-layer API-led design with Anypoint MQ providing async buffering between process and system APIs. The canonical carrier model means adding a new carrier requires only one system API without touching Salesforce or process-layer components.

System	Pattern	Direction	Protocol	Frequency	Volume
BluJay TMS	Request-Reply + Events	Bidirectional	REST via MuleSoft	Near-real-time	8,000 bookings/day
Manhattan WMS	Event-Driven	Inbound (within 5 min)	REST webhooks to MuleSoft	Event-driven	15,000 events/day
SAP S/4HANA (NA)	Request-Reply + Batch	Bidirectional	OData via MuleSoft SAP connector	Real-time + nightly batch	12,000 txn/day
SAP ECC 6.0 (EU)	Request-Reply	Bidirectional	BAPI/RFC via MuleSoft	Real-time + nightly batch	8,000 txn/day
APAC local ERPs	Varies (CSV/SOAP/REST)	Bidirectional	Mixed via MuleSoft	Daily batch	5,000 txn/day
Descartes	Request-Reply	Outbound (sync, sub-5s)	SOAP via MuleSoft	Synchronous per-shipment	4,000 screenings/day
Project44/CargoSmart	Webhook	Inbound (real-time)	REST to MuleSoft listener	Real-time	42,000 events/day
FrostGuard	Event-Driven	Inbound	MQTT to MuleSoft; 5-min aggregated + immediate excursion alerts	5-min aggregated + instant alerts	144K readings/day + excursions
40+ Carriers	Canonical Model	Bidirectional	REST via carrier system APIs	Per-booking + polling	65,000 API calls/day
Twilio	Fire-and-Forget	Outbound	REST via MuleSoft	Event-driven	35,000 SMS/day

FrostGuard stream processing detail (720K readings/day, sustained ~8.3/second, peak 15-20/second):

• Ingress: MuleSoft Anypoint MQ connector subscribes to the FrostGuard MQTT broker with QoS 2 (exactly-once delivery) and persistent sessions so reconnects do not drop readings.
• Windowing and aggregation: A MuleSoft DataWeave streaming transform buckets readings into 5-minute tumbling windows keyed by sensor_id. At window close, the aggregate (min / max / mean / reading count) writes a Temperature Log record. This reduces 720K/day to ~144K/day.
• Real-time threshold evaluation: Every raw reading (not just aggregated) evaluates against its shipment’s threshold profile in parallel to the aggregation window. Threshold crossings fire an Anypoint Exchange alert flow.
• Deduplication: An alert identity key of sensor_id + threshold_type + current_state_bucket prevents duplicate alerts when 5 consecutive readings cross the same threshold — only the state transition (below -> above, above -> below) fires an alert. Once the state changes back, a new state bucket is generated so re-excursions are not suppressed.
• Backpressure: The MQTT listener publishes into a bounded Anypoint MQ queue with a 10-minute TTL. If downstream Salesforce ingestion lags, the queue absorbs the burst; if the queue approaches capacity, the listener applies back-pressure on the MQTT subscription and an alert fires to on-call to scale the CloudHub worker horizontally.
• Dead letter queue: Readings that fail validation (malformed payload, unknown sensor, timestamp skew beyond 15 minutes) write to a DLQ with the raw payload, sensor ID, and failure reason for triage.
• Excursion alert SLA (2 minutes, Req 54): The alert flow publishes a Salesforce Platform Event via Pub/Sub API in sub-second once a state transition is detected. The SLA is bounded by MQTT inbound latency (typically 1-3 seconds) + aggregation bypass (<100ms) + Platform Event publish (<500ms) + Apex triggered subscriber handling (<1s) = well under the 2-minute envelope.
• Raw data retention: Raw 60-second readings stay in FrostGuard for 180-day retention and are not loaded into Salesforce.

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): Customer Community Plus licenses (consistent across all 4 CTA artifacts). Salesforce Identity with self-registration + MFA (TOTP/SMS). Enterprise clients federate via SAML with Salesforce acting as SP and the client IdP authenticating. SSO Setting per federated client (Connected Apps and External Client Apps are outbound OAuth/OIDC patterns, not inbound SAML authentication).
• 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 ~40-45K post-consolidation accounts across 3 orgs + FrostLine using Informatica Cloud (Company Name + Tax ID). NA record is master where most complete. The 2,800 FrostLine overlaps: top 200 by revenue get manual review, the rest automated.
3. NA Shipment migration (14M shipments + 210M tracking events):
   • Hot tier (90 days, ~2.4M events) loaded to the standard custom Tracking_Event__c via Bulk API 2.0 ingest jobs from MuleSoft. Batches of 10,000 records with parallel mode.
   • Warm tier (90 days-2 years, ~100M events) loaded to the Tracking_Event_Archive__b Big Object via Bulk API 2.0 against the Big Object ingest endpoint — 10,000 records per batch, parallel mode. This is the correct pattern for a one-time load of this scale. Apex batch DML with Database.insertImmediate() is rejected for the historical load because at the 2,000-records-per-execute maximum it would require over 50,000 batch executions and saturate Apex governor quotas. Apex batch DML stays reserved for the ongoing nightly hot-to-warm aging job (much smaller batch counts).
   • Cold tier (2-5 years, ~300M events) extracts to AWS S3 + Athena through a dedicated MuleSoft extraction flow writing Parquet files partitioned by year, month, and shipment prefix.
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. Zero-downtime portal cutover mechanism (Req 5 + Constraint 6):
   • Months 6-8, parallel run: MuleSoft dual-writes every carrier/TMS/WMS event to both the legacy NA org and the new global org. The new org is in read-only mode for portal users. Legacy portal remains the customer-facing system of record; new org is reconciled nightly against the legacy baseline with discrepancy reports.
   • Cutover day (month 8, Saturday 02:00 UTC):
     • T-60 min: Freeze writes on legacy NA portal. Existing sessions remain read-only.
     • T-45 min: Final reconciliation sweep via CDC replay from legacy to new org for any events in flight.
     • T-30 min: DNS TTL already reduced to 60 seconds. Portal static assets pre-warmed on CDN.
     • T-0: DNS flip at the CDN edge routes portal.gtl.com from legacy origin to Experience Cloud in the new org. Legacy portal returns HTTP 302 to the same URL. End-user impact is a single page reload with a new session cookie.
     • T+30 min: Legacy portal is decommissioned in read-only mode for 30 days as rollback insurance. MuleSoft dual-write switches direction (new org is primary, legacy receives async mirror writes) for the first 30 days post-cutover.
   • Total customer-facing downtime: sub-2-minute DNS propagation window (within Constraint 6’s 2-hour envelope). The “zero downtime for shipment tracking” requirement (Req 5) is met because tracking reads stay available throughout — only writes pause for ~60 minutes, during which carrier events queue in MuleSoft Anypoint MQ and replay to the new org on completion.

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 the difference; only the system API changes while the process API stays 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): Japan residency decision committed by end of month 6 following Legal’s APPI and FISC review. Per Decision 1’s decision tree, if the finding is APPI contractual safeguards only, Japanese data remains in Hyperforce EU Frankfurt with BYOK tenant keys stored in Japan. If the finding requires physical residency, the pre-budgeted Hyperforce Japan split-org is provisioned in month 10 and 1,200 APAC users plus Japan-headquartered accounts migrate there by month 14; MuleSoft bridges cross-border shipments and CRM Analytics consolidates reporting. Shield Platform Encryption is a confidentiality control, not a residency control, and is applied to sensitive APAC fields regardless of which residency path is chosen.

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

Unlimited Edition includes 1 Partial Copy sandbox by default. For three simultaneous regional Partial Copy sandboxes (NA, EU, APAC), GTL purchases two additional Partial Copy add-ons on top of the base Unlimited Edition entitlement. This is budgeted under the Phase 1 licensing line. Full Copy (1 per Unlimited Edition) is 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

Figure 6. Phased delivery roadmap for the GlobalTrade Logistics global consolidation, structured so NA goes live at month 8, EU and APAC follow at month 15, and the FrostLine cold-chain acquisition with Experience Cloud portal completes at month 18, with carrier API consolidation and the MuleSoft ECC-to-S/4HANA swap running in parallel across the program.

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. The MuleSoft SAP swap is sequenced after EU Salesforce migration. The abstraction layer means no Salesforce changes; only the system API component updates from ECC BAPI/RFC to S/4HANA OData.

Identity & SSO Flow

Figure 5. Identity and SSO flow for GlobalTrade Logistics covering four distinct authentication paths: Entra ID SAML 2.0 with JIT provisioning for 5,800 global employees across 18 countries, federated SAML from client corporate IdPs for enterprise portal customers, Salesforce Identity with MFA for non-federated portal customers, and OAuth 2.0 Client Credentials for MuleSoft system-to-system integration.

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). Standard SAML JIT can only set Profile and Role. A custom Auth.SamlJitHandler Apex class reads Entra group attributes from the SAML assertion and assigns the appropriate Permission Set Groups for regional territory, business unit, function, and cold-chain access. SCIM 2.0 handles lifecycle management. User deactivation in Entra automatically deactivates the Salesforce user within the SCIM sync interval (default 40 minutes).
• Portal user authentication (35,000 accounts): Two paths. Large enterprise clients federate via their own SAML IdP — Salesforce acts as SP with an SSO Setting (Single Sign-On configuration under Identity Provider) per federated client. Connected Apps and External Client Apps are outbound OAuth/OIDC patterns and are not used for inbound SAML. This supports Req 45 (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 through External Client Apps (the Spring ‘26 successor to Connected Apps — Salesforce restricted creation of new Connected Apps by default starting Spring ‘26 and External Client Apps are the recommended replacement for new integrations). Each target system (TMS, WMS, SAP, Descartes, FrostGuard, Project44, Twilio, 40+ carriers) is paired with an External Client App whose integration user’s profile grants the object and field permissions required. MuleSoft manages the token lifecycle and rotation from its own Named Credentials or Secrets Manager. 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

At 920,000 events/day across 40+ carrier APIs, the system requires strong 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, preventing any 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

Figure 7. Environment topology for GlobalTrade Logistics showing a four-sandbox developer layer promoting through region-specific Partial Copy UAT environments (NA, EU with GDPR testing, APAC) into a Full Copy sandbox for LDV performance validation at 413M+ record volumes before GARB-approved release to the Hyperforce EU production org.

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 64). 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 (Constraint 6): 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 34) with a 4-hour refresh cadence from Salesforce + MuleSoft data sources (shipment volumes by region/mode, on-time rates, exception rates, revenue per shipment). The dataflow is scheduled every 4 hours (6 runs per 24 hours) with incremental extraction on the Shipment and Tracking Event hot tier, well within the CRM Analytics dataflow run limits. Running every 6 hours would violate the 4-hour refresh SLA in Req 34. Finance quote-through-invoice reconciliation (Req 35) queries SAP OData feeds via MuleSoft experience APIs. Regional compliance dashboards (Req 36) pull GDPR processing logs from Shield Event Monitoring, trade screening results from Descartes integration data, and temperature compliance records from FrostGuard. LDV historical tracking analytics (Req 40) query the S3 + Athena cold tier via CRM Analytics External Data connectors for 5-year trend reporting without impacting transactional performance.

Presentation Strategy

In 45 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.

Scoring Rubric

Criterion	Weight	What Judges Look For
Data Architecture & LDV	25%	Tiered storage strategy for millions of shipment tracking events (hot/warm/cold). Big Objects for warm tier and S3 + Athena for cold tier with federated access from Salesforce Connect and CRM Analytics. Carrier data canonical model. Cold-chain acquisition data integration. Record volume projections with archival plan
Integration Depth	25%	Carrier API canonical model abstracting multiple carrier protocols. SAP OData integration for finance. FrostGuard cold-chain integration. Descartes trade screening. Each system classified by pattern, protocol, direction, volume, and SLA
Security & Data Residency	20%	Multi-region data residency (GDPR, APPI, PDPA). Cross-border transfer controls. Regional sharing rules. Shield Event Monitoring for data access audit. Customer data isolation across regions
System Architecture	15%	Org strategy for multi-region operations. Licensing model. Mobile strategy for logistics. Phased delivery including acquisition integration. System landscape with all integration points and legend
Trade-offs & Communication	15%	Clear articulation of LDV strategy trade-offs. Carrier canonical model justification. Data residency approach defended with regulatory specifics. Presentation flows logically from business context to technical decisions

---

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.