
sf-industry-commoncore-omnistudio-analyze
Cross-cutting OmniStudio analysis skill for namespace detection, dependency visualization, and impact analysis across OmniScripts, FlexCards, Integration Procedures, and Data Mappers. TRIGGER when: user asks about OmniStudio dependencies, wants namespace detection (Core vs vlocitycmt vs vlocityins), needs impact analysis, or requests dependency diagrams. DO NOT TRIGGER when: authoring OmniScripts (use sf-industry-commoncore-omniscript), building FlexCards (use sf-industry-commoncore-flexcard), creating Integration Procedures (use sf-industry-commoncore-integration-procedure), or configuring Data Mappers (use sf-industry-commoncore-datamapper).
- Installs
- 986
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/jaganpro/sf-skills --skill sf-industry-commoncore-omnistudio-analyze- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads sf-industry-commoncore-omnistudio-analyze automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
sf-industry-commoncore-omnistudio-analyze: OmniStudio Cross-Component Analysis
Expert OmniStudio analyst specializing in namespace detection, dependency mapping, and impact analysis across the full OmniStudio component suite. Perform org-wide inventory of OmniScripts, FlexCards, Integration Procedures, and Data Mappers with automated dependency graph construction and Mermaid visualization.
Core Responsibilities
- Namespace Detection: Identify whether an org uses Core (Industries), vlocity_cmt (Communications, Media & Energy), or vlocity_ins (Insurance & Health) namespace
- Dependency Analysis: Build directed graphs of cross-component dependencies using BFS traversal with circular reference detection
- Impact Analysis: Determine which components are affected when a given OmniScript, IP, FlexCard, or Data Mapper changes
- Mermaid Visualization: Generate dependency diagrams in Mermaid syntax for documentation and review
- Org-Wide Inventory: Catalog all OmniStudio components by type, status, language, and version
CRITICAL: Orchestration Order
When multiple OmniStudio skills are involved, follow this dependency chain:
sf-industry-commoncore-omnistudio-analyze→sf-industry-commoncore-datamapper→sf-industry-commoncore-integration-procedure→sf-industry-commoncore-omniscript→sf-industry-commoncore-flexcardThis skill runs first to establish namespace context and dependency maps that downstream skills consume.
Key Insights
| Insight | Detail |
|---|---|
| Three namespaces coexist | Core (OmniProcess), vlocity_cmt (vlocity_cmt__OmniScript__c), vlocity_ins (vlocity_ins__OmniScript__c) |
| Dependencies are stored in JSON | PropertySetConfig (elements), Definition (FlexCards), InputObjectName/OutputObjectName (Data Mappers) |
| Circular references are possible | OmniScript A → IP B → OmniScript A via embedded call |
| FlexCard data sources are typed | dataSource.type === 'IntegrationProcedures' (plural) in DataSourceConfig JSON |
| Active vs Draft matters | Only active components participate in runtime dependency chains |
Workflow (4-Phase Pattern)
Phase 1: Namespace Detection
Purpose: Determine which OmniStudio namespace the org uses before querying any component metadata.
Detection Algorithm — Probe objects in order until a successful COUNT() returns:
-
Core (Industries namespace):
SELECT COUNT() FROM OmniProcessIf this succeeds, the org uses the Core namespace (API 234.0+ / Spring '22+).
-
vlocity_cmt (Communications, Media & Energy):
SELECT COUNT() FROM vlocity_cmt__OmniScript__c -
vlocity_ins (Insurance & Health):
SELECT COUNT() FROM vlocity_ins__OmniScript__c
If none succeed, OmniStudio is not installed in the org.
CLI Commands for namespace detection:
# Core namespace probe
sf data query --query "SELECT COUNT() FROM OmniProcess" --target-org myorg --json 2>/dev/null
# vlocity_cmt namespace probe
sf data query --query "SELECT COUNT() FROM vlocity_cmt__OmniScript__c" --target-org myorg --json 2>/dev/null
# vlocity_ins namespace probe
sf data query --query "SELECT COUNT() FROM vlocity_ins__OmniScript__c" --target-org myorg --json 2>/dev/null
Evaluate results: A successful query (exit code 0 with totalSize in JSON) confirms the namespace. A query failure (INVALID_TYPE or sObject type not found) means that namespace is not present.
See: references/namespace-guide.md for complete object/field mapping across all three namespaces.
Phase 2: Component Discovery
Purpose: Build an inventory of all OmniStudio components in the org.
Using the detected namespace, query each component type:
OmniScripts (Core example):
SELECT Id, Type, SubType, Language, IsActive, VersionNumber,
PropertySetConfig, LastModifiedDate
FROM OmniProcess
WHERE IsIntegrationProcedure = false
ORDER BY Type, SubType, Language, VersionNumber DESC
Integration Procedures (Core example):
SELECT Id, Type, SubType, Language, IsActive, VersionNumber,
PropertySetConfig, LastModifiedDate
FROM OmniProcess
WHERE IsIntegrationProcedure = true
ORDER BY Type, SubType, Language, VersionNumber DESC
FlexCards (Core example):
SELECT Id, Name, IsActive, DataSourceConfig, PropertySetConfig,
AuthorName, LastModifiedDate
FROM OmniUiCard
ORDER BY Name
IMPORTANT: The
OmniUiCardobject does NOT have aDefinitionfield. UseDataSourceConfigfor data source bindings andPropertySetConfigfor card layout/states configuration.
Data Mappers (Core example):
SELECT Id, Name, IsActive, Type, LastModifiedDate
FROM OmniDataTransform
ORDER BY Name
Data Mapper Items (for object dependency extraction):
SELECT Id, OmniDataTransformationId, InputObjectName, OutputObjectName,
InputObjectQuerySequence
FROM OmniDataTransformItem
WHERE OmniDataTransformationId IN ({datamapper_ids})
IMPORTANT: The foreign key field is
OmniDataTransformationId(full word "Transformation"), NOTOmniDataTransformId.
CLI Command pattern:
sf data query --query "SELECT Id, Type, SubType, Language, IsActive FROM OmniProcess WHERE IsIntegrationProcedure = false" \
--target-org myorg --json
Phase 3: Dependency Analysis
Purpose: Parse component metadata to build a directed dependency graph.
Algorithm: BFS with Circular Detection
1. Initialize empty graph G and visited set V
2. For each root component C:
a. Enqueue C into work queue Q
b. While Q is not empty:
i. Dequeue component X from Q
ii. If X is in V, record circular reference and skip
iii. Add X to V
iv. Parse X's metadata for dependency references
v. For each dependency D found:
- Add edge X → D to graph G
- If D is not in V, enqueue D into Q
3. Return graph G and any circular references detected
Element Type → Dependency Extraction
OmniScript and IP elements store references in the PropertySetConfig JSON field. Parse each element to extract dependencies:
| Element Type | JSON Path in PropertySetConfig | Dependency Target |
|---|---|---|
| DataRaptor Transform Action | bundle, bundleName | Data Mapper (by name) |
| DataRaptor Turbo Action | bundle, bundleName | Data Mapper (by name) |
| Remote Action | remoteClass, remoteMethod | Apex Class.Method |
| Integration Procedure Action | integrationProcedureKey | IP (Type_SubType) |
| OmniScript Action | omniScriptKey or Type/SubType | OmniScript (Type_SubType) |
| HTTP Action | httpUrl, httpMethod | External endpoint (URL) |
| DocuSign Envelope Action | docuSignTemplateId | DocuSign template |
| Apex Remote Action | remoteClass | Apex Class |
Parsing PropertySetConfig:
For each OmniProcessElement:
1. Read PropertySetConfig (JSON string)
2. Parse JSON
3. Check element.Type against extraction table
4. Extract referenced component name/key
5. Resolve reference to an OmniProcess/OmniDataTransform record
6. Add edge: parent component → referenced component
FlexCard Data Source Parsing
FlexCards store their data source configuration in the DataSourceConfig JSON field (NOT Definition — that field does not exist on OmniUiCard):
Parse DataSourceConfig JSON:
1. Access dataSource object (singular, not array)
2. For each dataSource where type === 'IntegrationProcedures' (note: PLURAL):
- Extract dataSource.value.ipMethod (IP Type_SubType)
- Add edge: FlexCard → Integration Procedure
3. For each dataSource where type === 'ApexRemote':
- Extract dataSource.value.className
- Add edge: FlexCard → Apex Class
4. For childCard references, parse PropertySetConfig:
- Add edge: FlexCard → child FlexCard
IMPORTANT: The data source type for IPs is
IntegrationProcedures(plural with capital P), notIntegrationProcedure.
Data Mapper Object Dependencies
Data Mappers reference Salesforce objects via their items:
For each OmniDataTransformItem:
1. Read InputObjectName → source sObject
2. Read OutputObjectName → target sObject
3. Add edge: Data Mapper → sObject (read from InputObjectName)
4. Add edge: Data Mapper → sObject (write to OutputObjectName)
See: references/dependency-patterns.md for complete dependency extraction rules and examples.
Phase 4: Visualization & Reporting
Purpose: Generate human-readable output from the dependency graph.
Output Format 1: Mermaid Dependency Diagram
graph LR
subgraph OmniScripts
OS1["createOrder<br/>English v3"]
OS2["updateAccount<br/>English v1"]
end
subgraph Integration Procedures
IP1["fetchAccountData<br/>English v2"]
IP2["submitOrder<br/>English v1"]
end
subgraph Data Mappers
DM1["AccountExtract"]
DM2["OrderTransform"]
end
subgraph FlexCards
FC1["AccountSummaryCard"]
end
OS1 -->|IP Action| IP2
OS1 -->|DR Action| DM2
OS2 -->|IP Action| IP1
IP1 -->|DR Action| DM1
FC1 -->|Data Source| IP1
style OS1 fill:#dbeafe,stroke:#1d4ed8,color:#1f2937
style OS2 fill:#dbeafe,stroke:#1d4ed8,color:#1f2937
style IP1 fill:#fef3c7,stroke:#b45309,color:#1f2937
style IP2 fill:#fef3c7,stroke:#b45309,color:#1f2937
style DM1 fill:#d1fae5,stroke:#047857,color:#1f2937
style DM2 fill:#d1fae5,stroke:#047857,color:#1f2937
style FC1 fill:#fce7f3,stroke:#be185d,color:#1f2937
Color scheme:
| Component Type | Fill | Stroke |
|---|---|---|
| OmniScript | #dbeafe (blue-100) | #1d4ed8 (blue-700) |
| Integration Procedure | #fef3c7 (amber-100) | #b45309 (amber-700) |
| Data Mapper | #d1fae5 (green-100) | #047857 (green-700) |
| FlexCard | #fce7f3 (pink-100) | #be185d (pink-700) |
| Apex Class | #e9d5ff (purple-100) | #7c3aed (purple-700) |
| External (HTTP) | #f1f5f9 (slate-100) | #475569 (slate-600) |
Output Format 2: JSON Summary
{
"namespace": "Core",
"components": {
"omniScripts": 12,
"integrationProcedures": 8,
"flexCards": 5,
"dataMappers": 15
},
"dependencies": [
{ "from": "OS:createOrder", "to": "IP:submitOrder", "type": "IPAction" },
{ "from": "IP:fetchAccountData", "to": "DM:AccountExtract", "type": "DataRaptorAction" }
],
"circularReferences": [],
"impactAnalysis": {
"DM:AccountExtract": {
"directDependents": ["IP:fetchAccountData"],
"transitiveDependents": ["OS:updateAccount", "FC:AccountSummaryCard"]
}
}
}
Output Format 3: Human-Readable Report
OmniStudio Dependency Report
=============================
Org Namespace: Core (Industries)
Scan Date: 2026-03-06
Component Inventory:
OmniScripts: 12 (8 active, 4 draft)
Integration Procedures: 8 (6 active, 2 draft)
FlexCards: 5 (5 active)
Data Mappers: 15 (12 active, 3 draft)
Dependency Summary:
Total edges: 23
Circular references: 0
Orphaned components: 2 (no inbound/outbound deps)
Impact Analysis (most-depended components):
1. DM:AccountExtract → 5 dependents
2. IP:fetchAccountData → 3 dependents
3. DM:OrderTransform → 2 dependents
Namespace Object/Field Mapping
Complete mapping of OmniStudio objects and fields across all three namespaces:
Primary Objects
| Concept | Core | vlocity_cmt | vlocity_ins |
|---|---|---|---|
| OmniScript / IP container | OmniProcess | vlocity_cmt__OmniScript__c | vlocity_ins__OmniScript__c |
| OmniScript / IP elements | OmniProcessElement | vlocity_cmt__Element__c | vlocity_ins__Element__c |
| FlexCard | OmniUiCard | vlocity_cmt__VlocityUITemplate__c | vlocity_ins__VlocityUITemplate__c |
| Data Mapper | OmniDataTransform | vlocity_cmt__DRBundle__c | vlocity_ins__DRBundle__c |
| Data Mapper Item | OmniDataTransformItem | vlocity_cmt__DRMapItem__c | vlocity_ins__DRMapItem__c |
Key Fields
| Concept | Core Field | vlocity_cmt Field | vlocity_ins Field |
|---|---|---|---|
| Script type | Type | vlocity_cmt__Type__c | vlocity_ins__Type__c |
| Script subtype | SubType | vlocity_cmt__SubType__c | vlocity_ins__SubType__c |
| Language | Language | vlocity_cmt__Language__c | vlocity_ins__Language__c |
| Is active | IsActive | vlocity_cmt__IsActive__c | vlocity_ins__IsActive__c |
| Version | VersionNumber | vlocity_cmt__Version__c | vlocity_ins__Version__c |
| Element config | PropertySetConfig | vlocity_cmt__PropertySet__c | vlocity_ins__PropertySet__c |
| Is Integration Procedure | IsIntegrationProcedure | vlocity_cmt__IsIntegrationProcedure__c | vlocity_ins__IsIntegrationProcedure__c |
| FlexCard data sources | DataSourceConfig | vlocity_cmt__Definition__c | vlocity_ins__Definition__c |
| FlexCard layout/states | PropertySetConfig | (same field) | (same field) |
| DM input object | InputObjectName (on Item) | vlocity_cmt__InterfaceObject__c | vlocity_ins__InterfaceObject__c |
| DM output object | OutputObjectName (on Item) | vlocity_cmt__TargetFieldObjectType__c | vlocity_ins__TargetFieldObjectType__c |
See: references/namespace-guide.md for the complete reference including metadata type names for deployment.
CLI Commands Reference
Namespace Detection
# Probe all three namespaces (run sequentially, first success wins)
sf data query --query "SELECT COUNT() FROM OmniProcess" --target-org myorg --json 2>/dev/null && echo "CORE" || \
sf data query --query "SELECT COUNT() FROM vlocity_cmt__OmniScript__c" --target-org myorg --json 2>/dev/null && echo "VLOCITY_CMT" || \
sf data query --query "SELECT COUNT() FROM vlocity_ins__OmniScript__c" --target-org myorg --json 2>/dev/null && echo "VLOCITY_INS" || \
echo "NOT_INSTALLED"
Component Inventory (Core Namespace)
# Count OmniScripts
sf data query --query "SELECT COUNT() FROM OmniProcess WHERE IsIntegrationProcedure = false" \
--target-org myorg --json
# Count Integration Procedures
sf data query --query "SELECT COUNT() FROM OmniProcess WHERE IsIntegrationProcedure = true" \
--target-org myorg --json
# Count FlexCards
sf data query --query "SELECT COUNT() FROM OmniUiCard" --target-org myorg --json
# Count Data Mappers
sf data query --query "SELECT COUNT() FROM OmniDataTransform" --target-org myorg --json
Dependency Data Extraction (Core Namespace)
# Get OmniScript elements with their config
sf data query --query "SELECT Id, OmniProcessId, Name, Type, PropertySetConfig FROM OmniProcessElement WHERE OmniProcessId = '{process_id}'" \
--target-org myorg --json
# Get FlexCard data sources (for dependency parsing)
sf data query --query "SELECT Id, Name, DataSourceConfig FROM OmniUiCard WHERE IsActive = true" \
--target-org myorg --json
# Get Data Mapper items (for object dependencies)
sf data query --query "SELECT Id, OmniDataTransformationId, InputObjectName, OutputObjectName FROM OmniDataTransformItem" \
--target-org myorg --json
Cross-Skill Integration
| Skill | Relationship | How This Skill Helps |
|---|---|---|
| sf-industry-commoncore-datamapper | Provides namespace and object dependency data | Data Mapper authoring uses detected namespace for correct API names |
| sf-industry-commoncore-integration-procedure | Provides namespace and IP dependency map | IP authoring uses dependency graph to avoid circular references |
| sf-industry-commoncore-omniscript | Provides namespace and element dependency data | OmniScript authoring uses namespace-correct field names |
| sf-industry-commoncore-flexcard | Provides namespace and data source dependency map | FlexCard authoring uses detected IP references for validation |
| sf-diagram-mermaid | Consumes dependency graph for visualization | This skill generates Mermaid output compatible with sf-diagram-mermaid styling |
| sf-metadata | Provides sObject metadata for Data Mapper analysis | Object field validation during dependency extraction |
| sf-deploy | Deployment uses namespace-correct metadata types | This skill provides the correct metadata type names per namespace |
Edge Cases
| Scenario | Handling |
|---|---|
| Mixed namespace org (migration in progress) | Probe all three namespaces; report if multiple return results. Components may exist under both old and migrated namespaces. |
| Inactive components with dependencies | Include in dependency graph but mark as inactive. Warn if active component depends on inactive one. |
| Large orgs (1000+ components) | Use SOQL pagination (LIMIT/OFFSET or queryMore). Process in batches of 200. |
| PropertySetConfig exceeds SOQL field length | Use Tooling API or REST API to fetch full JSON body for elements with truncated config. |
| Circular dependency detected | Log the cycle path (A → B → C → A), mark all participating edges, continue traversal for remaining branches. |
| Components referencing deleted items | Record as "broken reference" in output. Flag for cleanup. |
| Version conflicts (multiple active versions) | Only the highest active version number participates in runtime. Warn if lower versions have unique dependencies. |
Notes
- Dependencies: Requires
sfCLI with org authentication. Optional: sf-diagram-mermaid for styled visualization. - Namespace must be detected first: All downstream queries depend on knowing the correct object and field API names.
- PropertySetConfig is the key: Nearly all dependency information lives in this JSON field on OmniProcessElement records.
- DataSourceConfig for FlexCards: Data sources are in
DataSourceConfig, NOT aDefinitionfield (which does not exist onOmniUiCard). Card layout/states are inPropertySetConfig. - Data Mapper items contain object references: InputObjectName and OutputObjectName on OmniDataTransformItem records reveal which sObjects a Data Mapper reads from and writes to. The foreign key to the parent is
OmniDataTransformationId(full "Transformation"). - IsIntegrationProcedure is the discriminator:
OmniProcessuses a booleanIsIntegrationProcedurefield, not aTypeCategoryfield (which does not exist). TheOmniProcessTypepicklist is computed from this boolean and is useful for filtering reads but cannot be set directly on create. - sf data create record limitations: The
--valuesflag cannot handle JSON strings in textarea fields (e.g., PropertySetConfig). Usesf api request rest --method POST --body @file.jsoninstead for records with JSON configuration. - Install related skills:
/plugin install github:Jaganpro/sf-skills/sf-industry-commoncore-datamapper,/plugin install github:Jaganpro/sf-skills/sf-industry-commoncore-integration-procedure,/plugin install github:Jaganpro/sf-skills/sf-industry-commoncore-omniscript,/plugin install github:Jaganpro/sf-skills/sf-industry-commoncore-flexcard
License
MIT License. Copyright (c) 2026 David Ryan (weytani)
FAQ
What does the sf-industry-commoncore-omnistudio-analyze skill do?
Cross-cutting OmniStudio analysis skill for namespace detection, dependency visualization, and impact analysis across OmniScripts, FlexCards, Integration Procedures, and Data Mappers. TRIGGER when: user asks about OmniStudio dependencies, wants namespace detection (Core vs vlocitycmt vs vlocityins), needs impact analysis, or requests dependency diagrams. DO NOT TRIGGER when: authoring OmniScripts (use sf-industry-commoncore-omniscript), building FlexCards (use sf-industry-commoncore-flexcard), creating Integration Procedures (use sf-industry-commoncore-integration-procedure), or configuring Data Mappers (use sf-industry-commoncore-datamapper).
How do I install sf-industry-commoncore-omnistudio-analyze?
Run npx skills add https://github.com/jaganpro/sf-skills --skill sf-industry-commoncore-omnistudio-analyze in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/sf-industry-commoncore-omnistudio-analyze/ (personal) or .claude/skills/sf-industry-commoncore-omnistudio-analyze/ (project).
Which AI agents can use sf-industry-commoncore-omnistudio-analyze?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is sf-industry-commoncore-omnistudio-analyze safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains sf-industry-commoncore-omnistudio-analyze?
It is published by jaganpro in jaganpro/sf-skills. It has 986 recorded installs.
More from jaganpro/sf-skills
sf-apex
jaganpro/sf-skills
Generates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
sf-lwc
jaganpro/sf-skills
Lightning Web Components with PICKLES methodology and 165-point scoring. TRIGGER when: user creates/edits LWC components, touches lwc//.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use sf-apex), Aura components, or Visualforce.
sf-flow
jaganpro/sf-skills
Creates and validates Salesforce Flows with 110-point scoring. TRIGGER when: user builds or edits record-triggered, screen, autolaunched, or scheduled flows, or touches .flow-meta.xml files. DO NOT TRIGGER when: Apex automation (use sf-apex), process builder migration questions only, or non-Flow declarative config (use sf-metadata).
sf-metadata
jaganpro/sf-skills
Salesforce metadata generation and querying with 120-point scoring. TRIGGER when: user creates custom objects, fields, validation rules, or touches .object-meta.xml, .field-meta.xml, .profile-meta.xml files. DO NOT TRIGGER when: permission set analysis (use sf-permissions), deploying metadata (use sf-deploy), or Flow XML (use sf-flow).
sf-soql
jaganpro/sf-skills
SOQL query generation, optimization, and analysis with 100-point scoring. TRIGGER when: user writes, optimizes, or debugs SOQL/SOSL queries, touches .soql files, or asks about relationship queries, aggregates, or query performance. DO NOT TRIGGER when: bulk data operations (use sf-data), Apex DML logic (use sf-apex), or report/dashboard queries.
sf-debug
jaganpro/sf-skills
Salesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use sf-testing), fixing Apex code (use sf-apex), or Agentforce session tracing (use sf-ai-agentforce-observability).
Popular other skills
hyperframes-cli
heygen-com/hyperframes
The HyperFrames CLI by job - scaffold, check, look at frames, edit the timeline, preview, render locally or in the cloud, publish, project history - plus reading its JSON and recovering from build or render failures.
triage
mattpocock/skills
Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.
ask-matt
mattpocock/skills
Ask which skill or flow fits your situation. A router over the skills in this repo.
to-questionnaire
mattpocock/skills
Turn a decision you can't fully answer into a questionnaire for someone else to fill in.
loop-me
mattpocock/skills
Grill me about specs for the workflows I want to build, within this workspace.