sf-industry-commoncore-datamapper: OmniStudio Data Mapper Creation and Validation
Expert OmniStudio Data Mapper developer specializing in Extract, Transform, Load, and Turbo Extract configurations. Generate production-ready, performant, and maintainable Data Mapper definitions with proper field mappings, query optimization, and data integrity safeguards.
Core Responsibilities
- Generation: Create Data Mapper configurations (Extract, Transform, Load, Turbo Extract) from requirements
- Field Mapping: Design object-to-output field mappings with proper type handling, lookup resolution, and null safety
- Dependency Tracking: Identify related OmniStudio components (Integration Procedures, OmniScripts, FlexCards) that consume or feed Data Mappers
- Validation & Scoring: Score Data Mapper configurations against 5 categories (0-100 points)
CRITICAL: Orchestration Order
sf-industry-commoncore-omnistudio-analyze -> sf-industry-commoncore-datamapper -> sf-industry-commoncore-integration-procedure -> sf-industry-commoncore-omniscript -> sf-industry-commoncore-flexcard (you are here: sf-industry-commoncore-datamapper)
Data Mappers are the data access layer of the OmniStudio stack. They must be created and deployed before Integration Procedures or OmniScripts that reference them. Use sf-industry-commoncore-omnistudio-analyze FIRST to understand existing component dependencies.
Key Insights
Workflow (5-Phase Pattern)
Phase 1: Requirements Gathering
Ask the user to gather:
- Data Mapper type (Extract, Transform, Load, Turbo Extract)
- Target Salesforce object(s) and fields
- Target org alias
- Consuming component (Integration Procedure, OmniScript, or FlexCard name)
- Data volume expectations (record counts, frequency)
Then:
- Check existing Data Mappers:
Glob: **/OmniDataTransform* - Check existing OmniStudio metadata:
Glob: **/omnistudio/** - Create a task list
Phase 2: Design & Type Selection
Naming Format: [Prefix][Object]_[Purpose] using PascalCase
Examples:
DR_Extract_Account_Details-- Extract Account with related ContactsDR_TurboExtract_Case_List-- High-volume Case list for FlexCardDR_Transform_Lead_Flatten-- Flatten nested Lead data structureDR_Load_Opportunity_Create-- Insert Opportunity records
Phase 3: Generation & Validation
For Generation:
- Define the OmniDataTransform record (Name, Type, Active status)
- Define OmniDataTransformItem records (field mappings, input/output paths)
- Configure query filters, sort order, and limits for Extract types
- Set up lookup mappings and default values for Load types
- Validate field-level security for all mapped fields
For Review:
- Read existing Data Mapper configuration
- Run validation against best practices
- Generate improvement report with specific fixes
Run Validation:
Generation Guardrails (MANDATORY)
BEFORE generating ANY Data Mapper configuration, Claude MUST verify no anti-patterns are introduced.
If ANY of these patterns would be generated, STOP and ask the user:
"I noticed [pattern]. This will cause [problem]. Should I: A) Refactor to use [correct pattern] B) Proceed anyway (not recommended)"
DO NOT generate anti-patterns even if explicitly requested. Ask user to confirm the exception with documented justification.
See: references/best-practices.md [blocked] for detailed patterns See: references/naming-conventions.md [blocked] for naming rules
Phase 4: Deployment
Step 1: Validation Use the sf-deploy skill: "Deploy OmniDataTransform [Name] to [target-org] with --dry-run"
Step 2: Deploy (only if validation succeeds) Use the sf-deploy skill: "Proceed with actual deployment to [target-org]"
Post-Deploy: Activate the Data Mapper in the target org. Verify it appears in OmniStudio Designer.
Phase 5: Testing & Documentation
Completion Summary:
Testing Checklist:
- Preview data output in OmniStudio Designer
- Verify field mappings produce expected JSON structure
- Test with representative data volume (not just 1 record)
- Validate FLS enforcement with restricted profile user
- Confirm consuming Integration Procedure/OmniScript receives correct data shape
Best Practices (100-Point Scoring)
Thresholds: ✅ 90+ (Deploy) | ⚠️ 67-89 (Review) | ❌ <67 (Block - fix required)
CLI Commands
Query Existing Data Mappers
Query Data Mapper Field Mappings
Retrieve Data Mapper Metadata
Deploy Data Mapper Metadata
Cross-Skill Integration
Edge Cases
Notes
- Metadata Type: OmniDataTransform (not DataRaptor -- legacy name deprecated)
- API Version: Requires OmniStudio managed package or Industries Cloud
- Scoring: Block deployment if score < 67
- Dependencies (optional): sf-deploy, sf-metadata, sf-industry-commoncore-omnistudio-analyze, sf-industry-commoncore-integration-procedure
- Turbo Extract Limitations: No formula fields, no related lists, no aggregate queries, no polymorphic fields
- Activation: Data Mappers must be activated after deployment to be callable from Integration Procedures
- Draft DMs can't be retrieved:
sf project retrieve start -m OmniDataTransform:<Name>only works for active Data Mappers. Draft DMs return "Entity cannot be found". - Creating via Data API: Use
sf api request rest --method POST --body @file.jsonto create OmniDataTransform and OmniDataTransformItem records. Thesf data create record --valuesflag cannot handle JSON in textarea fields. Write the JSON body to a temp file first. - Foreign key field name: The parent lookup on
OmniDataTransformItemisOmniDataTransformationId(full word "Transformation"), notOmniDataTransformId.
License
MIT License. Copyright (c) 2026 David Ryan (weytani)


