Sf Industry Commoncore Omnistudio Analyze

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

1. Namespace Detection: Identify whether an org uses Core (Industries), vlocity_cmt (Communications, Media & Energy), or vlocity_ins (Insurance & Health) namespace
2. Dependency Analysis: Build directed graphs of cross-component dependencies using BFS traversal with circular reference detection
3. Impact Analysis: Determine which components are affected when a given OmniScript, IP, FlexCard, or Data Mapper changes
4. Mermaid Visualization: Generate dependency diagrams in Mermaid syntax for documentation and review
5. 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-flexcard

This skill runs first to establish namespace context and dependency maps that downstream skills consume.

Key Insights

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:

1. Core (Industries namespace):

   soql

   SELECT COUNT() FROM OmniProcess

   If this succeeds, the org uses the Core namespace (API 234.0+ / Spring '22+).

2. vlocity_cmt (Communications, Media & Energy):

   soql

   SELECT COUNT() FROM vlocity_cmt__OmniScript__c

3. vlocity_ins (Insurance & Health):

   soql

   SELECT COUNT() FROM vlocity_ins__OmniScript__c

If none succeed, OmniStudio is not installed in the org.

CLI Commands for namespace detection:

# Core namespace probesf data query --query "SELECT COUNT() FROM OmniProcess" --target-org myorg --json 2>/dev/null
# vlocity_cmt namespace probesf data query --query "SELECT COUNT() FROM vlocity_cmt__OmniScript__c" --target-org myorg --json 2>/dev/null
# vlocity_ins namespace probesf 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 [blocked] 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, LastModifiedDateFROM OmniProcessWHERE IsIntegrationProcedure = falseORDER BY Type, SubType, Language, VersionNumber DESC

Integration Procedures (Core example):

SELECT Id, Type, SubType, Language, IsActive, VersionNumber,       PropertySetConfig, LastModifiedDateFROM OmniProcessWHERE IsIntegrationProcedure = trueORDER BY Type, SubType, Language, VersionNumber DESC

FlexCards (Core example):

SELECT Id, Name, IsActive, DataSourceConfig, PropertySetConfig,       AuthorName, LastModifiedDateFROM OmniUiCardORDER BY Name

IMPORTANT: The OmniUiCard object does NOT have a Definition field. Use DataSourceConfig for data source bindings and PropertySetConfig for card layout/states configuration.

Data Mappers (Core example):

SELECT Id, Name, IsActive, Type, LastModifiedDateFROM OmniDataTransformORDER BY Name

Data Mapper Items (for object dependency extraction):

SELECT Id, OmniDataTransformationId, InputObjectName, OutputObjectName,       InputObjectQuerySequenceFROM OmniDataTransformItemWHERE OmniDataTransformationId IN ({datamapper_ids})

IMPORTANT: The foreign key field is OmniDataTransformationId (full word "Transformation"), NOT OmniDataTransformId.

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 V2. 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 Q3. 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:

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), not IntegrationProcedure.

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 [blocked] 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:

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

Key Fields

See: references/namespace-guide.md [blocked] 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 OmniScriptssf data query --query "SELECT COUNT() FROM OmniProcess WHERE IsIntegrationProcedure = false" \  --target-org myorg --json
# Count Integration Proceduressf data query --query "SELECT COUNT() FROM OmniProcess WHERE IsIntegrationProcedure = true" \  --target-org myorg --json
# Count FlexCardssf data query --query "SELECT COUNT() FROM OmniUiCard" --target-org myorg --json
# Count Data Mapperssf data query --query "SELECT COUNT() FROM OmniDataTransform" --target-org myorg --json

Dependency Data Extraction (Core Namespace)

# Get OmniScript elements with their configsf 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

Edge Cases

Notes

• Dependencies: Requires sf CLI 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 a Definition field (which does not exist on OmniUiCard). Card layout/states are in PropertySetConfig.
• 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: OmniProcess uses a boolean IsIntegrationProcedure field, not a TypeCategory field (which does not exist). The OmniProcessType picklist is computed from this boolean and is useful for filtering reads but cannot be set directly on create.
• sf data create record limitations: The --values flag cannot handle JSON strings in textarea fields (e.g., PropertySetConfig). Use sf api request rest --method POST --body @file.json instead 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)