Case Study 3: GlobalTrade Logistics - Q&A Preparation

Work in Progress

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

Q&A Guide

This page compiles judge-style follow-up questions for the case study. Use it after your presentation run-through so you can test how well you defend your choices.

Q&A Snapshot

Field	Detail
Open after	Presentation Notes
Format	45-minute Q&A following a 45-minute presentation
Study role	Practice concise, defensible answers
Related pages	Case Study Overview, Scenario Paper, Worked Solution

Q&A Strategy

State your position, give the reasoning, acknowledge the trade-off, and keep answers to 1-2 minutes.

Q1: 413M tracking events in Big Objects - how does an agent look up an 18-month-old shipment, and what about the 200-row sync SOQL limit?

The Shipment record itself is always in standard objects. Tracking events older than 90 days move to a Big Object (Tracking_Event_Archive__b). Key milestone dates are denormalized onto the Shipment record so the agent sees essential information immediately without touching the event archive. Hot-tier events (last 90 days) load instantly on the shipment detail page. A “Load Full History” button is the deeper path.

The 200-row synchronous SOQL limit on Big Objects is a real constraint. The Load Full History UX handles it two ways. For most shipments, 50-150 events cover the 2-year window, so a single synchronous SOQL query on the indexed fields (ShipmentExternalId__c first, EventTimestamp__c second) returns within the 200-row cap in 5-10 seconds with UI-tier paging if needed. For long-tail shipments that exceed 200 events (multi-leg ocean routes with trans-shipment), the button enqueues a Batch Apex job that streams the full result set into a Platform Event; the LWC subscribes via the EMP API and renders the complete timeline when the event arrives — typically under 15 seconds end-to-end. Portal users do not query the Big Object directly; a brokered Apex action enforces account ownership on the Shipment parent before returning events.

Q2: Why Big Objects + S3 instead of Heroku Postgres or Data 360 for warm and cold tiers?

Big Objects stay within the Salesforce platform boundary for the warm tier. They are queryable via standard SOQL on indexed fields and governed by object/field permissions (with the caveat that they do NOT participate in the sharing model — access is brokered via Apex). An external database for the warm tier would create a separate security perimeter and compliance gap. The trade-off is limited query flexibility (first N index fields only); I designed the index with ShipmentExternalId first and EventTimestamp second to cover the primary access pattern.

For the cold tier I explicitly did NOT choose Data 360 even though it offers lakehouse-style storage. Data 360 is Salesforce’s real-time customer data platform for profile unification, segmentation, and activation. Its Salesforce CRM connector does not ingest Big Objects, and credit-based billing for 300M archival tracking events runs an order of magnitude more expensive than AWS S3 at $0.023/GB + Athena at $5/TB scanned for the same workload. The cold tier is S3 + Athena, federated to Salesforce via Salesforce Connect (OData) for on-demand point lookups from the UI and CRM Analytics External Data connectors for historical trend analytics. Data 360 stays in the architecture for its intended role: unified customer profile scoring and Experience Cloud real-time segmentation.

Q3: What about Salesforce Backup or Privacy Center instead of Big Objects?

Salesforce Backup (formerly Backup and Restore) is a backup-and-point-in-time-recovery product, not a queryable archive — records restored from Backup land back in the original object and are not intended for agent lookups or analytics. Privacy Center enforces data retention policies and can delete records on schedule, which is complementary to this architecture. The warm-tier pattern I chose is Big Objects because they are purpose-built for LDV archival with indexed SOQL access at 400M+ scale, and they integrate with CRM Analytics for historical queries. If an alternative with similar indexed-SOQL guarantees emerges with strong production references, the tiering batch logic can swap the destination without changing the hot tier or the agent UX.

Integration

Q4: MuleSoft for 40+ carriers is expensive. Justify it.

Without middleware, GTL maintains 40+ point-to-point Apex integrations across three orgs. The current state costs $4.2M/year in maintenance and incident response. MuleSoft provides: canonical data model reducing 40 contracts to one, centralized monitoring in a single dashboard, and one-system-API carrier onboarding. License cost is ~$300-400K/year against $4.2M in annual savings plus reduced maintenance. ROI is clear within year one.

Q5: What if MuleSoft goes down, and what SLA does CloudHub actually commit to?

MuleSoft CloudHub 2.0 commits to 99.99% uptime on multi-region active-active deployments; a single-region deployment runs closer to 99.9%. GTL’s production MuleSoft deployment uses the primary worker region in AWS Frankfurt with a secondary failover region in AWS Dublin (both within the EU data residency envelope), so the 99.99% SLA applies. Critical pattern: Anypoint MQ queues messages between process and system layers with automatic retry. Platform Events provide guaranteed delivery with replay. For Experience Cloud portal tracking reads, LWC uses wire adapters directly against the Salesforce hot-tier custom objects where the data already lives — inserting a MuleSoft cache between the portal and Salesforce just to read native data is an unnecessary round-trip and an anti-pattern for data that is already in the org. MuleSoft stays on the write path (ingesting carrier events into Salesforce) and on cross-system reads (SAP OData, Descartes SOAP) but not as a cache layer for native Salesforce records.

Q6: How do you handle 720,000 daily FrostGuard readings — windowing, dedup, backpressure?

I do not bring all 720K raw readings into Salesforce. MuleSoft’s MQTT subscriber (QoS 2, persistent sessions) receives the stream and runs two parallel pipelines: a DataWeave streaming transform buckets readings into 5-minute tumbling windows keyed by sensor_id and writes the aggregate (min/max/mean/count) as a Temperature Log record (720K reduced to ~144K/day), and in parallel every raw reading evaluates against its shipment’s threshold profile. Excursion detection dedups using an alert identity key of sensor_id + threshold_type + state_bucket so 5 consecutive above-threshold readings fire one alert (on state transition) rather than five. Once the state changes back, a new state bucket is generated for re-excursions. Backpressure is handled by a bounded Anypoint MQ queue with a 10-minute TTL between the MQTT listener and downstream Salesforce ingestion — if the queue approaches capacity, the listener applies back-pressure on the MQTT subscription and on-call receives a scale-out alert to add CloudHub workers. Failed readings (malformed payload, unknown sensor, timestamp skew) route to a DLQ. Excursion alerts publish a Platform Event via Pub/Sub API; end-to-end latency from MQTT inbound to Apex trigger handler is well under the 2-minute SLA (typically 3-5 seconds). Raw 60-second data stays in FrostGuard for 180-day retention.

Q7: EU SAP ECC to S/4HANA upgrade overlaps with migration. How?

MuleSoft makes this manageable. Salesforce-to-SAP flows through a MuleSoft process API calling a SAP system API. Today that system API speaks BAPI/RFC to ECC. When the upgrade completes, a new system API speaking OData to S/4HANA swaps in. The process API and Salesforce see no change. Sequencing: EU Salesforce migration at month 10, SAP swap at months 16-18. The two never happen simultaneously.

Security

Q8: Performance impact of Enterprise Territory Management at 35K accounts — and why not apply it to Shipment?

Territory assignment rules process on Account create/modify. At 35K accounts with hundreds of daily changes, this is manageable — the single active Territory Model contains 3 regional parent territories and 18 country leaf territories. Sharing recalculation on hierarchy changes runs async; for 35K accounts across 18 territories, it completes within hours. Enterprise Territory Management cannot be applied directly to Shipment even if I wanted to — the platform only supports ETM on Account, Opportunity, Case, and Lead as of Spring ‘26; custom objects like Shipment are not supported. Shipment at 26M rows is sharing-enforced via criteria-based sharing rules matched to the Shipper Account’s territory plus Apex Managed Sharing for the Consignee Account’s territory. Controlled by Parent is explicitly rejected because (a) master-detail to Account at 26M children over 35K parents creates catastrophic parent-child data skew, and (b) Controlled by Parent cannot share a single shipment with two independent territory contexts.

Q9: How do you enforce EU data residency in a single global org — and why is Shield Encryption not the same thing as residency?

Three layers. First, Hyperforce on AWS Frankfurt holds the physical data at rest in the EU for all 16 non-Japan countries. Second, Shield Platform Encryption with tenant-managed keys stored regionally protects confidentiality of specific sensitive fields. Third, Data Classification metadata tags personal data by applicable regulation (GDPR, APPI, PDPA) for automated compliance reporting. Be clear about what Shield does and does not do: Shield encrypts data in place, it does not move data. A Japanese personal data field encrypted with a tenant key stored in Japan is still physically located in Frankfurt. Residency regulations that require in-country physical storage are not satisfied by encryption alone. That is why Decision 1 carries a committed Japan split-org fallback — see Q17.

Q10: German rep should not see Japanese data. But what about a cross-border shipment from a German shipper to a Japanese consignee?

The Shipment object carries two Account lookups: Shipper_Account__c and Consignee_Account__c. A cross-border shipment from a German shipper to a Japanese consignee is a single Shipment record with the German account in the Shipper lookup and the Japanese account in the Consignee lookup. Both the NA/EU Shipper rep (with German account visibility through the EU Territory) and the APAC Consignee rep (with Japanese account visibility through the APAC Territory) see the same Shipment through their respective account contexts. This is implemented via Apex Managed Sharing: a trigger on Shipment save injects two Shipment__Share rows with the appropriate RowCause for Shipper and Consignee. The Shipment OWD is Private (not Controlled by Parent) to support the two-party visibility model. If neither account is in the other’s territory, only the party whose account matches sees the record. Global accounts use the Global_Account_Regions__c field to scope criteria-based sharing to the regions that actually touch the account, so a global account with only NA and EU operations does not leak to APAC.

Migration

Q11: Deduplication strategy for 2,800 FrostLine overlapping accounts?

Three tiers by risk. Tier 1: top 200 by revenue get manual data steward review. Tier 2: remaining 2,600 use automated Informatica matching (Company Name fuzzy + Tax ID exact), GTL record survives, FrostLine fields merge where GTL is blank. Tier 3: 700 FrostLine-only accounts load directly. Pre-merge validation flags matches below 85% confidence for manual review.

Q12: How do you handle NA’s 420 Process Builders?

Check execution logs - expect 30-40% dormant. Deprecated those. Active ones with straightforward logic use the Migrate to Flow tool. Complex Process Builders with multiple criteria nodes get manually rewritten as Flows post-migration. Salesforce still executes Process Builders during migration - conversion to Flow is technical debt scheduled for the first two sprints after NA go-live.

Q13: Rollback plan if NA parallel run fails?

During parallel run, the old org remains system of record. Both systems run; data writes go to both via MuleSoft dual-write. If critical issues surface (discrepancies, integration failures, adoption below 70%), the parallel run extends. There is no cut over. Rollback is simply “stop using the new org.” The sunk cost is the parallel-run period, not the entire migration.

Portal, Cold-Chain, and Governance

Q14: 8,000 concurrent portal users - how does Experience Cloud handle this?

Four measures. CDN caching for static assets (read-heavy app). LWC lazy loading - summary first, full timeline on interaction. Tracking data served by native LWC wire adapters querying the Salesforce hot tier directly — the shipment and tracking event records are already in the org, so routing the read through a MuleSoft experience API as a cache layer just adds a round-trip without benefit. MuleSoft stays on the write path for carrier ingestion and on cross-system reads (SAP, Descartes) where it has a real abstraction role. Account Role Optimization is enabled before portal go-live so the underlying UserRole table stays manageable at 35K accounts × 3 roles. Two-month load testing phase (months 20-22) with k6 simulating 8K concurrent finds bottlenecks pre-launch.

Q15: The FrostLine MD worries about “big company processes” slowing his team. How do you address this?

Tiered governance. GARB only reviews cross-region and schema-level changes. Cold-chain gets its own admin scope with autonomy for cold-chain-specific config: layouts, flows, reports, dashboards. They deploy on the same bi-weekly cadence but their changes are scoped to cold-chain objects and do not require cross-region validation. Direct communication: “Your team keeps its speed for cold-chain changes. Governance only kicks in when changes touch shared objects or integrations.”

Identity and SSO

Q16: Three legacy orgs each have their own identity setup. How do you federate 5,800 users across 18 countries into a single SSO?

Entra ID is the single identity provider. All three orgs’ user directories consolidate into Entra before Salesforce migration begins. SAML 2.0 for authentication, SCIM 2.0 for lifecycle management. FrostLine’s 400 employees get migrated into Entra as part of M&A IT integration. On first login to the new global org, JIT provisioning creates their Salesforce user with the correct profile and permission set groups based on Entra group membership. The critical design point: Entra group-to-permission-set-group mapping drives regional territory assignment, business unit, function, and cold-chain access. No manual profile assignment. User deactivation in Entra automatically deactivates the Salesforce user within the SCIM sync cycle (roughly 40 minutes). For the transition period, old orgs and the new org run in parallel, so users may have SSO sessions to both during the parallel run.

Q17: What if Japan requires physical data residency and FISC mandates data stored in-country?

Decision 1 commits to a decision tree with a pre-budgeted fallback. Legal completes the APPI and FISC review by end of month 6, before Phase 2 design lock. The tree has two branches.

Branch A — APPI contractual safeguards are sufficient (no physical residency requirement): Japanese data stays in the single Hyperforce EU Frankfurt org with BYOK tenant-managed keys stored in Japan. Shield Platform Encryption protects confidentiality for sensitive fields. This is the baseline architecture. Note that Shield does not move the data — the encrypted bytes are physically in Frankfurt and the regulator gets a clear written answer: the data lives in Frankfurt with Japanese-managed key material.

Branch B — FISC or critical-infrastructure classification requires physical residency in Japan: a separate Japan org provisions on Hyperforce Japan (Osaka), generally available since 2023. 1,200 APAC users and Japan-headquartered accounts migrate to the Japan org in month 10 with a month-14 completion. MuleSoft bridges cross-border shipments via bidirectional sync on Account, Shipment, and Tracking Event. CRM Analytics consolidates reporting via federated queries across both orgs. Cost delta: +$420K/year in licensing + $180K one-time integration build, pre-scoped with Salesforce account team during Phase 1 and carried in the contingency budget line. Timeline impact: Phase 2 APAC stretches by 2-3 months, absorbed within the existing 4-month EU+APAC window.

Shield Platform Encryption is a confidentiality control, not a residency substitute. Encrypting Japanese data in Frankfurt leaves the data physically in Germany; if the regulator asks “where is the personal data stored?” the honest answer is Frankfurt. Branch B is the only architecture that says “Osaka.” I validate the feasibility of Hyperforce Japan for GTL with the Salesforce account team in Phase 1 so the option is locked in if Legal’s finding triggers it.

Mobile and Field Operations

Q18: 800 warehouse workers with intermittent connectivity. How does offline work and what happens when two workers update the same shipment?

Field Service with the Field Service Mobile App on company-managed iPads. The choice of Field Service over the standard Salesforce mobile app is driven by the service data model fit, not by offline — the standard Salesforce mobile app also supports offline via Briefcase Builder with a Mobile App Plus license, but warehouse workflows map naturally to Work Order, Service Appointment, Service Resource, Service Territory, and ProductItem, which are first-class Field Service objects. Each worker is modeled as a Service Resource assigned to the Service Territory of their facility. Work Orders are generated from Shipment records on status transitions (received, staged, packed, shipped). Briefcase Builder primes each worker’s iPad with the assigned facility’s open Work Orders, shipment staging records, and inventory counts at shift start, and automatic offline priming keeps assigned records cached continuously. Typical offline scope is 500-2,000 records per device. Sync frequency is every 15 minutes when connected. For conflict resolution: status fields use last-write-wins because warehouse workflows are sequential (pick then pack then ship). Photo and signature captures are append-only. If two workers do update the same record offline, the second sync overwrites the first, and Field History Tracking preserves both versions in the audit log. The supervisor dashboard shows real-time sync status per Service Resource so stale devices are flagged.

Q19: How do 200 BYOD drivers handle proof of delivery offline?

Salesforce Mobile with Field Service on personal iOS and Android devices. Microsoft Intune provides MDM at the container level: Salesforce data lives in a managed app container that can be remotely wiped without touching personal data. Offline scope is the day’s assigned deliveries, route details, and customer contact info, roughly 50-100 records. Proof of delivery captures a photo of the delivered goods and a digital signature on the device screen, stored locally until connectivity restores. These are append-only uploads, so no conflict scenario exists. Session timeout is 4 hours (shorter than office users). If the session expires during a delivery route, the driver re-authenticates via Entra SSO on the next connection. All offline actions queue and sync automatically.

Licensing

Q20: Walk me through the licensing model. 5,800 employees, 800 warehouse, 200 drivers, 35,000 portal accounts. What licenses and what is the cost impact?

Internal users: Sales Cloud and Service Cloud licenses for office-based employees (roughly 4,800). Field Service licenses for 800 warehouse workers and 200 drivers (1,000 total). The Field Service license choice is driven by the native service data model (Service Territories, Service Resources, Work Types, Work Orders, Service Appointments) that matches warehouse and driver workflows, not by offline capability per se — Briefcase Builder is available in the Field Service Mobile App and in the standard Salesforce mobile app with a Mobile App Plus license, so the offline argument alone would not justify the Field Service license premium.

Portal: 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 without role hierarchy support and are not interchangeable with Customer Community Plus. External Apps is NOT a rename of Customer Community Plus; both exist in parallel as distinct license SKUs in Spring ‘26. Since most portal users are occasional (checking shipment status), login-based licensing is more cost-effective than member-based for the long tail. Top-tier enterprise accounts (roughly 300 accounts with daily-active users) get member-based licenses. On the 8K concurrent peak: Experience Cloud concurrent load is a runtime limit, not a licensing dimension. I size login-based pools against a conservative 12-15x concurrent-to-total-user ratio, so 8K concurrent implies an active daily user pool of roughly 100-120K which is covered by the login-based license allocation across 35K accounts.

Shield Platform Encryption and Event Monitoring are org-wide add-ons. CRM Analytics licenses for the reporting users who need dashboard access. The licensing model is a significant cost line in the $14.5M budget; exact pricing is validated with the Salesforce account team during Phase 1 contracting. Account Role Optimization is enabled before portal go-live to mitigate role-table performance issues at the 35K-account scale.

Document Management

Q21: 6 million documents per year. Where do they live and how do clients get document bundles?

Salesforce Files for active shipment documents within the last 12 months. Beyond 12 months, a scheduled MuleSoft batch archives documents to Amazon S3, retaining a Shipment_Document metadata record in Salesforce with an S3 presigned URL for retrieval. This prevents Files storage from growing unbounded. Upload workflow: portal users and internal ops upload via the Shipment_Document related list. MuleSoft handles virus scanning on upload, and file type validation restricts to PDF, JPG, PNG, and TIFF. Download: single documents download directly from the Shipment record. A “Download Document Bundle” button triggers a MuleSoft experience API that assembles all documents for that shipment into a ZIP file. Portal users can only download bundles for their own account’s shipments, enforced by the sharing set. Trade compliance bundles are a special case: grouped per shipment per jurisdiction with regulatory metadata. Retention is 7 years for trade compliance documents per regulatory requirements, 5 years for standard shipping documents.

Multi-Language and Localization

Q22: Seven languages across the org. How do you handle Translation Workbench limitations at this scale?

Translation Workbench handles standard Salesforce metadata: custom labels, field labels, picklist values, validation messages, page layouts. For the seven languages (EN, DE, NL, FR, JA, ZH, KO), each language has a translator assigned in Setup. Custom LWC text IS translatable through Translation Workbench as long as the LWC references Custom Labels (import LABEL from '@salesforce/label/c.LabelName';) rather than hard-coding strings — any LWC built to this convention surfaces its translatable strings in the Translation Workbench Custom Labels list, and translators update the labels per language. The coding standard for this project requires LWC developers to externalize all user-facing strings as Custom Labels. Email template bodies are not translated by Translation Workbench directly; for email templates I use Custom Labels referenced in the template, which ARE translatable. For portal content, Experience Cloud supports multi-language out of the box via language-specific page variants. CRM Analytics dashboard labels use custom metadata-driven translations. Report and dashboard names are not translatable via Translation Workbench — regional teams create region-specific report folders with locally named reports, accepting some duplication to avoid forcing Japanese users to read English dashboard titles. For record-level data (shipment descriptions, exception notes), the system stores the original entry language and does not auto-translate; cross-region agents rely on their own language skills or escalate.

LDV and Reporting

Q23: 395 million historical tracking events. How do you run trend analytics across 5 years without killing transactional performance?

Three tiers with different analytics paths. The hot tier (90 days, ~12M events in standard objects) feeds the operational dashboards with a 4-hour refresh. The warm tier in Big Objects (90 days to 2 years, ~100M events) is queryable via standard SOQL on indexed fields and exposed to CRM Analytics via the Big Object dataflow connector for ad-hoc investigations. The cold tier (2-5 years, ~300M events) lives in AWS S3 as Parquet files partitioned by year/month/shipment-prefix with Athena providing SQL queries; CRM Analytics External Data connectors pull aggregated slices from Athena for historical trend dashboards (on-time rates by carrier over 3 years, seasonal volume patterns, temperature excursion trends by lane). Salesforce Connect (OData) provides on-demand point lookups into the S3+Athena cold tier from the Salesforce UI for audit queries. None of this touches the transactional Salesforce database, so there is zero impact on the sub-3-second page load SLA. Data 360 is not used as the cold tier — its Salesforce CRM connector does not ingest Big Objects and its credit-based pricing is an order of magnitude more expensive than S3+Athena for archival workloads. The trade-off is that historical analytics have a lag (nightly batch from hot to warm, and batch extraction from warm to cold), so cold-tier trend dashboards are T+1 at best.

Q24: Cross-region executive dashboard. How do you consolidate KPIs when each region has different data quality and completeness?

The executive dashboard in CRM Analytics pulls from three data sources: hot-tier tracking events for operational volume and on-time metrics, SAP OData feeds via MuleSoft for financial reconciliation, and the exception management data for risk indicators. Data quality is normalized at ingestion: MuleSoft’s canonical model ensures that regardless of which regional carrier or ERP feeds the data, the canonical schema is consistent. For the transition period while regions migrate sequentially (NA at month 8, EU at month 15, cold-chain at month 22), the dashboard includes a “Data Source” indicator per region showing whether metrics come from the new global org or the legacy org. Post-full-migration, this indicator disappears. Drill-down by region, mode (ocean/air/ground), carrier, and customer tier. The 4-hour refresh maximum (Req 34) is met by scheduling the CRM Analytics dataflow every 4 hours (6 runs per 24 hours), not every 6 hours. A 6-hour interval would violate the SLA — the refresh must run at least as often as the SLA window requires, and 6 runs per day sits well within CRM Analytics dataflow run limits (60 per day for Plus, 120 per day for Growth).

Q25: How do you prevent one portal customer from seeing another customer’s shipments or documents?

Sharing Sets on the Experience Cloud portal grant each portal user access to records whose Account lookup matches the user’s own Account. Specifically, the Shipment sharing set matches Shipper_Account__c = $User.AccountId OR Consignee_Account__c = $User.AccountId. Sharing Sets key off the user’s Account field (or the related Contact’s Account) directly — they do not rely on the AccountContactRelation junction. When a portal user logs in, their session context is locked to their Account. Shipment OWD is Private; sharing set grants the portal user read access only to Shipments tied to their Account through either the Shipper or Consignee lookup. Tracking Event (hot tier), Shipment Document, Temperature Log, and Quote inherit this access via their Shipment lookup. Big Object warm tier access is brokered by Apex that applies the same account-ownership check before returning events. A user at Company A cannot query, report on, or access any record belonging to Company B because the sharing set does not grant access to Company B’s records and the platform enforces the boundary in SOQL, reports, and API responses. For global accounts (4,200 accounts visible to multiple regional teams internally), the portal side is unaffected: the portal user still sees only records tied to their own account. I validate this with a cross-account data isolation test in the EU Partial Copy sandbox (masked data) and Full Copy sandbox before go-live. The test explicitly attempts SOQL injection and URL manipulation to access other accounts’ records.

Question Categorization

Domain	Questions
D1 System Architecture	Q20 (licensing)
D2 Security	Q8, Q9, Q10, Q16, Q17, Q25
D3 Data	Q1, Q2, Q3, Q11, Q23, Q24
D5 Integration	Q4, Q5, Q6, Q7
D6 Dev Lifecycle	Q12, Q13
D4 Solution	Q14, Q18, Q19, Q21, Q22
D7 Communication	Q15

Q&A Survival Rules

1. Answer the question asked. Do not pivot to a topic you prepared better for.
2. State position first, then reasoning: “I chose X because Y. I rejected Z because W.”
3. Name the trade-off proactively. Judges respect honesty over pretending there is no cost.
4. Say “I don’t know” when appropriate: “I would validate that during the design phase”
5. Stay within 1-2 minutes per answer

Related Topics

• Case Study 03 Solution
• Presentation Notes
• Q&A Strategies

---

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.