Token导航 LogoToken导航TokenDH.com
开发需要联网github未标认证来源可访问许可证需确认审计通过

sf-datamapperSF 数据映射器

Agent Skill

用于辅助数据整理、表格处理、CSV/Excel 分析、指标计算和图表准备。它适合让 Agent 清洗字段、汇总数据、发现异常、生成统计口径或把分析结果转成可读说明。使用时需要确认数据来源、字段含义和时间范围,避免把样本数据当全量事实;涉及敏感数据、导出文件或批量写回时,应先确认权限和脱敏边界。

总安装

634

周安装

17

GitHub Stars

401

下载量

140
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:sf-datamapper(SF 数据映射器)
来源仓库:https://github.com/jaganpro/sf-skills
仓库路径:skills/sf-datamapper
安装命令:
npx skills add https://github.com/jaganpro/sf-skills --skill sf-datamapper
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/jaganpro/sf-skills --skill sf-datamapper

简介

用于辅助数据映射、表格处理和分析准备工作。sf-datamapper 属于开发类 Skill,可作为该场景下的辅助能力补充。

  • 适合清洗字段、汇总数据、发现异常或生成统计口径说明。
  • 使用时需确认数据来源、字段含义和时间范围,避免误用样本当全量。
  • 涉及敏感数据或导出文件时,应先确认权限和脱敏边界。
  • 安装方式:通过 npx 从指定 GitHub 仓库添加技能。

SKILL.md

sf-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

  1. Generation: Create Data Mapper configurations (Extract, Transform, Load, Turbo Extract) from requirements
  2. Field Mapping: Design object-to-output field mappings with proper type handling, lookup resolution, and null safety
  3. Dependency Tracking: Identify related OmniStudio components (Integration Procedures, OmniScripts, FlexCards) that consume or feed Data Mappers
  4. Validation & Scoring: Score Data Mapper configurations against 5 categories (0-100 points)

CRITICAL: Orchestration Order

sf-omnistudio-analyze -> sf-datamapper -> sf-integration-procedure -> sf-omniscript -> sf-flexcard (you are here: sf-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-omnistudio-analyze FIRST to understand existing component dependencies.


Key Insights

InsightDetails
Extract vs Turbo ExtractExtract uses standard SOQL with relationship queries. Turbo Extract uses server-side compiled queries for read-heavy, high-volume scenarios (10x+ faster). Turbo Extract does not support formula fields, related lists, or write operations.
Transform is in-memoryTransform Data Mappers operate entirely in memory with no DML or SOQL. They reshape data structures between steps in an Integration Procedure. Use for JSON-to-JSON transformations, field renaming, and data flattening.
Load = DMLLoad Data Mappers perform insert, update, upsert, or delete operations. They require proper FLS checks and error handling. Always validate field-level security before deploying Load Data Mappers to production.
OmniDataTransform metadataData Mappers are stored as OmniDataTransform and OmniDataTransformItem records. Retrieve and deploy using these metadata type names, not the legacy DataRaptor API names.

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:

  1. Check existing Data Mappers: Glob: **/OmniDataTransform*
  2. Check existing OmniStudio metadata: Glob: **/omnistudio/**
  3. Create a task list

Phase 2: Design & Type Selection

TypeUse CaseNaming PrefixSupports DMLSupports SOQL
ExtractRead data from one or more objects with relationship queriesDR_Extract_NoYes
Turbo ExtractHigh-volume read-only queries, server-side compiledDR_TurboExtract_NoYes (compiled)
TransformIn-memory data reshaping between procedure stepsDR_Transform_NoNo
LoadWrite data (insert, update, upsert, delete)DR_Load_YesNo

Naming Format: [Prefix][Object]_[Purpose] using PascalCase

Examples:

  • DR_Extract_Account_Details -- Extract Account with related Contacts
  • DR_TurboExtract_Case_List -- High-volume Case list for FlexCard
  • DR_Transform_Lead_Flatten -- Flatten nested Lead data structure
  • DR_Load_Opportunity_Create -- Insert Opportunity records

Phase 3: Generation & Validation

For Generation:

  1. Define the OmniDataTransform record (Name, Type, Active status)
  2. Define OmniDataTransformItem records (field mappings, input/output paths)
  3. Configure query filters, sort order, and limits for Extract types
  4. Set up lookup mappings and default values for Load types
  5. Validate field-level security for all mapped fields

For Review:

  1. Read existing Data Mapper configuration
  2. Run validation against best practices
  3. Generate improvement report with specific fixes

Run Validation:

Score: XX/100 Rating
|- Design & Naming: XX/20
|- Field Mapping: XX/25
|- Data Integrity: XX/25
|- Performance: XX/15
|- Documentation: XX/15

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)"
Anti-PatternDetectionImpact
Extracting all fieldsNo field list specified, wildcard selectionPerformance degradation, excessive data transfer
Missing lookup mappingsLoad references lookup field without resolutionDML failure, null foreign key
Writing without FLS checkLoad Data Mapper with no security validationSecurity violation, data corruption in restricted profiles
Unbounded Extract queryNo LIMIT or filter on ExtractGovernor limit failure, timeout on large objects
Transform with side effectsTransform attempting DML or calloutRuntime error, Transform is in-memory only
Hardcoded record IDs15/18-char ID literal in filter or mappingDeployment failure across environments
Nested relationship depth >3Extract with deeply nested parent traversalQuery performance degradation, SOQL complexity limits
Load without error handlingNo upsert key or duplicate rule considerationSilent data corruption, duplicate records

DO NOT generate anti-patterns even if explicitly requested. Ask user to confirm the exception with documented justification.

See: references/best-practices.md for detailed patterns See: references/naming-conventions.md 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:

Data Mapper Complete: [Name]
  Type: [Extract|Transform|Load|Turbo Extract]
  Target Object(s): [Object1, Object2]
  Field Count: [N mapped fields]
  Validation: PASSED (Score: XX/100)

Next Steps: Test in Integration Procedure, verify data output, monitor performance

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)

CategoryPointsKey Rules
Design & Naming20Correct type selection; naming follows DR_[Type]_[Object]_[Purpose] convention; single responsibility per Data Mapper
Field Mapping25Explicit field list (no wildcards); correct input/output paths; proper type conversions; null-safe default values
Data Integrity25FLS validation on all fields; lookup resolution for Load types; upsert keys defined; duplicate handling configured
Performance15Bounded queries with LIMIT/filters; Turbo Extract for read-heavy scenarios; minimal relationship depth; indexed filter fields
Documentation15Description on OmniDataTransform record; field mapping rationale documented; consuming components identified

Thresholds: ✅ 90+ (Deploy) | ⚠️ 67-89 (Review) | ❌ <67 (Block - fix required)


CLI Commands

Query Existing Data Mappers

sf data query -q "SELECT Id,Name,Type FROM OmniDataTransform" -o <org>

Query Data Mapper Field Mappings

sf data query -q "SELECT Id,Name,InputObjectName,OutputObjectName,LookupObjectName FROM OmniDataTransformItem WHERE OmniDataTransformationId='<id>'" -o <org>

Retrieve Data Mapper Metadata

sf project retrieve start -m OmniDataTransform:<Name> -o <org>

Deploy Data Mapper Metadata

sf project deploy start -m OmniDataTransform:<Name> -o <org>

Cross-Skill Integration

From SkillTo sf-datamapperWhen
sf-omnistudio-analyze-> sf-datamapper"Analyze dependencies before creating Data Mapper"
sf-metadata-> sf-datamapper"Describe target object fields before mapping"
sf-soql-> sf-datamapper"Validate Extract query logic"
From sf-datamapperTo SkillWhen
sf-datamapper-> sf-integration-procedure"Create Integration Procedure that calls this Data Mapper"
sf-datamapper-> sf-deploy"Deploy Data Mapper to target org"
sf-datamapper-> sf-omniscript"Wire Data Mapper output into OmniScript"
sf-datamapper-> sf-flexcard"Display Data Mapper Extract results in FlexCard"

Edge Cases

ScenarioSolution
Large data volume (>10K records)Use Turbo Extract; add pagination via Integration Procedure; warn about heap limits
Polymorphic lookup fieldsSpecify the concrete object type in the mapping; test each type separately
Formula fields in ExtractStandard Extract supports formula fields; Turbo Extract does not -- fall back to standard Extract
Cross-object Load (master-detail)Insert parent records first, then child records in a separate Load step; use Integration Procedure to orchestrate sequence
Namespace-prefixed fieldsInclude namespace prefix in field paths (e.g., ns__Field__c); verify prefix matches target org
Multi-currency orgsMap CurrencyIsoCode explicitly; do not rely on default currency assumption
RecordType-dependent mappingsFilter by RecordType in Extract; set RecordTypeId in Load; document which RecordTypes are supported

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-omnistudio-analyze, sf-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.json to create OmniDataTransform and OmniDataTransformItem records. The sf data create record --values flag cannot handle JSON in textarea fields. Write the JSON body to a temp file first.
  • Foreign key field name: The parent lookup on OmniDataTransformItem is OmniDataTransformationId (full word "Transformation"), not OmniDataTransformId.

License

MIT License.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

32.56%
按下载量换算46

Claude

30.84%
按下载量换算43

Cursor

19.83%
按下载量换算28

Gemini CLI

9.12%
按下载量换算13

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills