9.1 Data Mappers (DataRaptors) — Turbo Extract, Extract, Transform & Load

9.1 Data Mappers (DataRaptors) — Turbo Extract, Extract, Transform & Load

Exam Focus: Modern public sector applications require seamless movement of data between public-facing user interfaces and complex government relational databases. On the AP-222 examination, candidates must master OmniStudio Data Mappers (historically documented as DataRaptors). The exam tests your ability to select the optimal Data Mapper type for specific performance constraints, design multi-object relationship mappings without custom code, configure upsert keys to prevent duplicate constituent records, and apply governor-limit-conscious optimization techniques to support high-volume citizen portals.

---

The Architectural Role of OmniStudio Data Mappers in Public Sector Solutions

In Salesforce Public Sector Solutions (PSS), data rarely exists in a flat, uniform format. Citizen intake wizards (OmniScripts), constituent 360 dashboards (FlexCards), and autonomous AI interfaces (Agentforce actions) operate natively on hierarchical, nested JSON payloads. Conversely, Salesforce persists data in strongly typed, relational sObjects such as Account, Contact, IndividualApplication, BusinessLicenseApplication, and DocumentChecklist.

OmniStudio Data Mappers serve as the configurable, declarative Extract, Transform, and Load (ETL) engine bridging this divide. By abstracting object queries, data reshaping, and database persistence into declarative metadata, Data Mappers eliminate the need for boilerplate Apex controllers and SOQL/DML scripts.

+--------------------------------------------------------------------------------+
|                       OmniStudio Data Flow Architecture                        |
+--------------------------------------------------------------------------------+
|  [OmniScript / FlexCard / Agentforce UI]  <--->  [Nested Hierarchical JSON]    |
|                                                             │                  |
|                                                             ▼                  |
|                                                [OmniStudio Data Mapper]        |
|                                                • Turbo Extract (Fast Read)     |
|                                                • Standard Extract (Relational) |
|                                                • Transform (In-Memory JSON)    |
|                                                • Load (DML / Upsert / Link)    |
|                                                             │                  |
|                                                             ▼                  |
|                                                [Salesforce Database Tier]      |
|                                                • Standard PSS Objects          |
|                                                • Person Accounts & Contacts    |
|                                                • Custom Objects & External IDs |
+--------------------------------------------------------------------------------+

Terminology Transition: DataRaptor vs. Data Mapper

Historically introduced as part of the Vlocity platform under the moniker DataRaptor, Salesforce has transitioned the product naming to OmniStudio Data Mapper within core platform documentation. However, on the AP-222 examination, both terms appear interchangeably across questions and answer options:

• DataRaptor Turbo Extract ⟷ Data Mapper Turbo Extract
• DataRaptor Extract ⟷ Data Mapper Extract
• DataRaptor Transform ⟷ Data Mapper Transform
• DataRaptor Load ⟷ Data Mapper Load

Candidates should treat "DataRaptor" and "Data Mapper" as functional synonyms representing the exact same underlying declarative engine.

---

Deep Dive: The Four Data Mapper Types

Choosing the correct Data Mapper type is one of the most frequently tested competencies on the AP-222 exam. Each type is architecturally engineered for a specific data manipulation pattern.

1. Data Mapper Turbo Extract: High-Performance Single-Object Reads

Data Mapper Turbo Extract is engineered specifically for speed and minimal resource overhead. Unlike the standard Extract, Turbo Extract bypasses the multi-object relational engine and directly compiles a streamlined SOQL query against a single Salesforce sObject.

Key Characteristics & Capabilities:

• Single Object Scope: Queries fields exclusively from one primary sObject. However, it can traverse up to two levels of direct parent lookups (e.g., retrieving Contact.AccountId and Contact.Account.Name).
• Zero Formula Overhead: Turbo Extract does not provide a Formulas tab. It extracts field values directly from the database without in-flight algorithmic transformations.
• Simplified Configuration: Configuration consists of selecting the object, defining filter criteria (e.g., Id = inputId or Status = 'Submitted'), and checking the specific fields required.
• Performance Advantage: Because it generates a single, highly optimized SOQL query with zero schema join processing, it consumes significantly less CPU time and platform memory than a Standard Extract.

Public Sector Best Practice:

Use Turbo Extract when populating OmniScript typeahead elements, populating dropdown picklists from reference tables (such as RegulatoryAuthorizationType), or retrieving a citizen's basic Person Account details upon portal login.

2. Data Mapper Standard Extract: Relational & Multi-Object Queries

When an application requires data spanning multiple related or unrelated objects, the Standard Data Mapper Extract is the requisite tool. It allows architects to construct complex relational extraction trees that navigate both child-to-parent and parent-to-child relationships.

Key Characteristics & Capabilities:

• Multi-Object Navigation: Extracts data from multiple objects in a single execution. For example, it can extract a BusinessLicenseApplication, traverse down to its child DocumentChecklist records (parent-to-child subquery), traverse up to the primary applicant's Account (child-to-parent), and independently extract municipal inspection zoning parameters.
• In-Flight Formulas Tab: Executes built-in formulas before output mapping. Formulas support text manipulation (CONCAT), date mathematics (AGE, FORMATDATETIME), mathematical calculations (ROUND), and conditional evaluations (IF(ISBLANK(...))).
• Hierarchical Output Shaping: Enables developers to restructure relational table outputs into deeply nested JSON structures, rename keys to match frontend component requirements, and aggregate child collections into structured JSON arrays.
• Filtering, Sorting & Pagination: Supports multi-field filter conditions, dynamic sorting parameters, and result limits.

Public Sector Best Practice:

Use Standard Extract when assembling a comprehensive caseworker adjudication view that requires loading the IndividualApplication, all associated AssessmentQuestionResponse records, uploaded document statuses, and related household member details.

3. Data Mapper Transform: In-Memory JSON & XML Manipulation

Data Mapper Transform performs pure, in-memory data conversions without reading from or writing to the Salesforce database. It consumes zero SOQL queries and zero DML statements, making it virtually free in terms of transactional database governor limits.

Key Characteristics & Capabilities:

• Format Conversions: Converts JSON to JSON, JSON to XML, and XML to JSON.
• Payload Restructuring: Reshapes flat incoming payloads into nested arrays, unrolls deeply nested structures, renames attributes, and removes sensitive internal metadata before transmitting payloads externally.
• Formula Processing: Executes mathematical, string, and logical formulas across inbound attributes without touching database records.

Public Sector Best Practice:

Use Data Mapper Transform to convert internal PSS JSON payloads into legacy SOAP/XML request envelopes required by state criminal background check systems or federal DMV registries, and conversely to translate external XML responses back into structured JSON for FlexCard display.

4. Data Mapper Load: Relational Persistence and Upsert Deduplication

Data Mapper Load is the persistence engine of OmniStudio. It takes an incoming JSON structure and creates, updates, or upserts records across one or more Salesforce sObjects in a single, atomic transactional boundary.

Key Characteristics & Capabilities:

• Multi-Object Writes: Can write to multiple disparate objects in a single execution (e.g., updating a Contact, inserting an IndividualApplication, and generating three DocumentChecklist records).
• Matching Keys (Upsert Deduplication): Allows architects to specify one or more fields as a Matching Key. If a record matching the key values exists in Salesforce, the Data Mapper updates that record; if no match is found, a new record is inserted. This prevents duplicate citizen and organization records.
• Parent-Child Relationship Linking: Using the Domain Object Field mapping mechanism, child records can be dynamically linked to parent records created earlier in the exact same Data Mapper execution, eliminating intermediate round-trips.
• Default Values & Formulas: Provides pre-commit formula calculations and the ability to assign default values to fields if the incoming JSON node is null or absent.

---

Designing Optimal Mappings: Formulas, Upserts, and Relational Integrity

Configuring Data Mappers for high-throughput public sector deployments requires strict attention to mapping logic, data types, and transactional relationships.

1. In-Flight Formula Execution Order

In both Standard Extracts and Loads, the Formulas tab executes sequentially before the output or target mapping takes place:

1. Input Payload Ingestion: The mapper accepts the input JSON context.
2. Formula Evaluation: The engine computes all formula expressions sequentially. A formula can reference input JSON paths (e.g., ApplicantBirthDate) or the results of preceding formulas.
3. Target Mapping Execution: The mapper maps both the raw input attributes and the newly calculated formula results into the destination schema (Output JSON for Extracts, sObject fields for Loads).

Common Formula Examples in Public Sector Solutions:
---------------------------------------------------------------------------------
Formula Expression:               AGE(ApplicantBirthDate)
Formula Result Path:             ApplicantAge
Business Purpose:                Determines statutory adulthood eligibility for licensing

Formula Expression:               CONCAT(FirstName, " ", LastName)
Formula Result Path:             LegalFullName
Business Purpose:                Constructs constituent display name for official certificates

Formula Expression:               IF(ISBLANK(MailingState), BillingState, MailingState)
Formula Result Path:             PrimaryJurisdiction
Business Purpose:                Ensures address completeness during intake processing

2. Default Values and Null Handling

When capturing constituent data via self-service portals, users frequently omit optional fields. Data Mapper Load provides explicit controls to maintain database cleanliness:

• Default Value Property: Hardcodes fallback values directly on the mapping line (e.g., setting Status to "Submitted" or ApplicationType to "Initial").
• Overwrite Target Nulls Toggle: If set to false (the default and recommended setting), an empty or null value in the incoming JSON payload will not overwrite an existing non-null value in the target Salesforce record during an update. This protects established CRM constituent profile data from being accidentally wiped out by partial form submissions.

3. Deduplication via Matching Keys

In citizen portals, duplicate record proliferation is a severe compliance hazard. When a resident submits an application, the system must recognize returning constituents rather than creating duplicate Account or Contact records.

Configuring Matching Keys in Data Mapper Load:
Step 1: Map Input [ApplicantSSN]   --> Target Field [Contact.Social_Security_Number__c]
Step 2: Check the "Matching Key" checkbox on this mapping line.
Step 3: Map Input [ApplicantEmail] --> Target Field [Contact.Email]
Step 4: Check the "Matching Key" checkbox on this mapping line.

When multiple fields are designated as Matching Keys, the Data Mapper treats them as a logical AND condition: a record is updated only if both Social_Security_Number__c AND Email match an existing database record. If no match is found, an INSERT is executed.

4. Relational Linking via Domain Object Fields

A classic exam scenario involves creating a parent record and multiple child records simultaneously. In standard Apex, a developer must insert the parent, capture the generated Salesforce ID, assign that ID to the child foreign key fields, and execute a second DML insert.

Data Mapper Load accomplishes this declaratively within a single execution:

1. Object Step 1 (Account): Maps constituent organization details. Target Object: Account.
2. Object Step 2 (BusinessLicenseApplication): Target Object: BusinessLicenseApplication.
3. Linkage Mapping: On the BusinessLicenseApplication mapping tab, map the parent reference using the syntax:
   • Domain Object Field: AccountId
   • Linked Object Field / Domain Object: Account:Id (referencing the Account generated in Step 1).

The Data Mapper engine automatically captures the newly committed parent ID and injects it into the child relationship field prior to committing Step 2.

---

Performance Optimization, Governor Limits, and Architectural Best Practices

Public sector portals regularly experience unpredictable traffic surges—such as opening dates for commercial cannabis licenses, seasonal hunting permits, or disaster relief grants. Poorly designed Data Mappers can quickly exhaust Salesforce multi-tenant governor limits, resulting in severe portal slowdowns or complete application crashes.

Comparing Turbo Extract vs. Standard Extract Performance

+-----------------------------------------------------------------------------------+
|              Architectural Decision Matrix: Turbo vs. Standard Extract            |
+-----------------------------------------------------------------------------------+
| Characteristic            | Turbo Extract             | Standard Extract          |
+---------------------------+---------------------------+---------------------------+
| Target Objects            | Exactly 1 sObject         | Multiple sObjects         |
| SOQL Queries Consumed     | Exactly 1 SOQL query      | 1 to N SOQL queries       |
| Relational Traversal      | Parent lookups only (2 lvl)| Child subqueries & Parents|
| Formula Support           | None (Zero overhead)      | Full Formulas Tab         |
| Output JSON Shaping       | Flat or basic tree        | Deeply custom hierarchy   |
| Relative CPU Time         | Minimal (~10-25ms)        | Moderate to High (50-300ms)|
| Best Architectural Fit    | Lookups, Typeaheads,      | Dossier loads, complex    |
|                           | Profile prefill           | adjudication bundles      |
+-----------------------------------------------------------------------------------+

Key Optimization Guidelines for AP-222 Candidates:

1. Adhere to the Single-Object Rule: Whenever an intake step or FlexCard requires fields from only one object, always select Turbo Extract. Never use a Standard Extract for a single-object query.
2. Trim Extraction Fields (Eliminate SELECT *): Only extract the specific fields displayed or evaluated in downstream steps. Extracting unused text or formula fields inflates heap size, slows JSON serialization, and degrades browser rendering speed.
3. Leverage Indexed Fields in Extract Filters: Ensure that the fields used in filter criteria (e.g., External_ID__c, LicenseNumber__c, National_ID__c) are defined as External IDs or indexed custom fields. Filtering on non-indexed text fields causes full table scans that fail in Large Data Volume (LDV) environments.
4. Avoid Traversal in High-Frequency Loops: Never invoke a Standard Extract inside an Integration Procedure Loop Block. If multiple related records must be fetched, extract them in bulk prior to entering the loop, or utilize indexed parent-child relationship subqueries.
5. Bulk & Batch Mode for Data Migration: When importing thousands of legacy public records, configure the Data Mapper Load in Batch / Bulk Mode to execute bulk DML statements rather than single-record transactional operations.

---

💡 Real-World Exam Scenarios & Case Analysis

Scenario 1: High-Volume Citizen Permitting Portal Status Lookup

A municipal department of transportation launches a public portal where citizens check the real-time status of their residential parking permits by entering their Vehicle Identification Number (VIN). The portal anticipates handling over 250,000 inquiries per week. The development team implements a Standard DataRaptor Extract that queries the Vehicle object and formats the returned status string using an in-mapper formula.

During peak morning traffic, the portal experiences severe latency, with users reporting 8-second page load times and intermittent 10,000ms Apex CPU timeout errors.

What is the recommended architectural remediation?

• Root Cause: The Standard Extract introduces unnecessary query-parsing overhead and CPU formula evaluation cycles for a simple, single-object query.
• Remediation: Replace the Standard Extract with a Data Mapper Turbo Extract querying the Vehicle object directly, filtering on the indexed VIN__c field. Move any required status formatting to the client-side FlexCard using a basic conditional display or an expression property. This reduces server CPU consumption by over 70% and consumes exactly 1 SOQL query per request.

Scenario 2: Multi-Tier Commercial Licensing Intake Submission

A state commercial licensing bureau implements an OmniScript for retail cannabis license applications. Upon submission, the system must: (1) verify if the applicant business exists and update it, or create a new Business Account if not; (2) create a BusinessLicenseApplication linked to that Account; (3) create four DocumentChecklist placeholders for required security blueprints and background checks linked to the application; and (4) create an onboarding Task assigned to the intake queue.

The lead developer proposes writing a custom Apex REST controller to handle the multi-object DML and ID assignments, citing that declarative tools cannot handle multi-tier relational inserts.

How should the Enterprise Architect guide the team in accordance with AP-222 standards?

• Architectural Correction: Reject the custom Apex controller. OmniStudio Data Mappers natively support multi-object relational persistence without code.
• Implementation: Configure a single Data Mapper Load:
  • Object Step 1 (Account): Define Federal_Tax_ID__c as the Matching Key to handle update-or-insert logic.
  • Object Step 2 (BusinessLicenseApplication): Link AccountId to Account:Id using the Domain Object Field.
  • Object Step 3 (DocumentChecklist): Link ParentRecordId to BusinessLicenseApplication:Id using the Domain Object Field.
  • Object Step 4 (Task): Link WhatId to BusinessLicenseApplication:Id and set default priority and queue ownership.
• This declarative pattern ensures atomic transactional execution, reduces technical debt, and adheres strictly to Salesforce public sector best practices.