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):

   SELECT COUNT() FROM OmniProcess

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

2. vlocity_cmt (Communications, Media & Energy):

   SELECT COUNT() FROM vlocity_cmt__OmniScript__c

3. 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 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, 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"), 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 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:

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

---

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)

Credits & Acknowledgments

This skill was built upon the collective knowledge of the Salesforce OmniStudio community. We gratefully acknowledge the following tools, teams, and resources whose work informed and shaped this skill.

---

Tools & Projects

sf-explorer/omnistudio-mcp-server

Community OmniStudio dependency analyzer

Key contributions:

• Dependency graph construction patterns for OmniStudio components
• Cross-component traversal algorithms
• Impact analysis methodology for OmniScript, IP, FlexCard, and Data Mapper changes

@salesforce/omnistudio-mcp (Official)

Salesforce official FlexCard MCP server

Key contributions:

• FlexCard Definition JSON schema reference
• Data source type definitions and parsing patterns
• Child card and action configuration structures

---

Salesforce Teams

Salesforce Industries Engineering

OmniStudio platform development team

Key contributions:

• Core namespace object model (OmniProcess, OmniUiCard, OmniDataTransform, OmniProcessElement)
• PropertySetConfig and Definition JSON schema design
• Namespace migration architecture (Vlocity → Core)
• IsIntegrationProcedure boolean discriminator on OmniProcess for distinguishing OmniScripts from Integration Procedures

---

Official Salesforce Resources

OmniStudio Documentation

• OmniStudio Developer Guide: https://developer.salesforce.com/docs/atlas.en-us.omnistudio.meta/omnistudio/
• Industries Data Model Reference: https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/
• OmniStudio Standard Objects: https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_omniprocess.htm

Trailhead Content

• OmniStudio Trailhead Module: https://trailhead.salesforce.com/content/learn/modules/omnistudio-components
• Build OmniScripts Trail: https://trailhead.salesforce.com/content/learn/trails/build-omnistudio-omniscripts
• Build Integration Procedures Trail: https://trailhead.salesforce.com/content/learn/modules/omnistudio-integration-procedures
• Build FlexCards Trail: https://trailhead.salesforce.com/content/learn/modules/omnistudio-flexcards

---

Community Resources

Salesforce Stack Exchange

[salesforce.stackexchange.com](https://salesforce.stackexchange.com/)

• OmniStudio namespace detection discussions
• PropertySetConfig parsing techniques
• Cross-component dependency questions and solutions

Salesforce Ben

[salesforceben.com](https://www.salesforceben.com/)

• OmniStudio architecture overviews
• Migration guides for Vlocity to Core namespace

---

Key Concepts Credited

Namespace Detection via SOQL Probing

The pattern of probing SELECT COUNT() FROM OmniProcess (and Vlocity equivalents) to detect the installed namespace is a community-established practice for OmniStudio tooling.

BFS Dependency Traversal

The breadth-first search algorithm for dependency graph construction follows standard graph traversal patterns adapted for OmniStudio's JSON-embedded reference model.

Mermaid Visualization for Dependencies

The use of Mermaid diagrams for OmniStudio dependency visualization follows patterns from the sf-diagram-mermaid skill and the broader documentation-as-code community.

---

Contributor

David Ryan (weytani)

Primary Contributor — GitHub

• Namespace mapping research and validation
• Dependency extraction algorithm design
• Cross-skill orchestration pattern (sf-industry-commoncore-omnistudio-analyze → sf-industry-commoncore-datamapper → sf-industry-commoncore-integration-procedure → sf-industry-commoncore-omniscript → sf-industry-commoncore-flexcard)

---

Special Thanks

To the Salesforce Industries engineering team for the Core namespace migration that unified OmniStudio's object model, and to the OmniStudio community for sharing namespace detection patterns and dependency analysis techniques that made this skill possible.

---

If we've missed anyone whose work influenced this skill, please let us know so we can add proper attribution.

<!-- Parent: sf-industry-commoncore-omnistudio-analyze/SKILL.md -->

OmniStudio Dependency Patterns

Overview

OmniStudio components form a directed graph where each component type can reference others. Dependencies are not stored in lookup fields — they are embedded in JSON configuration fields (PropertySetConfig, Definition, InputObjectName/OutputObjectName). Extracting dependencies requires parsing these JSON structures.

---

Dependency Direction Summary

OmniScript ──→ Integration Procedure (via IP Action element)
OmniScript ──→ Data Mapper (via DataRaptor Action element)
OmniScript ──→ OmniScript (via embedded OmniScript element)
OmniScript ──→ Apex Class (via Remote Action element)
OmniScript ──→ LWC (via Custom Lightning Web Component element)
OmniScript ──→ HTTP Endpoint (via HTTP Action element)

Integration Procedure ──→ Data Mapper (via DataRaptor Action element)
Integration Procedure ──→ Apex Class (via Remote Action element)
Integration Procedure ──→ HTTP Endpoint (via HTTP Action element)
Integration Procedure ──→ Integration Procedure (via nested IP Action element)
Integration Procedure ──→ OmniScript (via OmniScript Action element — uncommon)

FlexCard ──→ Integration Procedure (via data source configuration)
FlexCard ──→ Apex Class (via Apex data source)
FlexCard ──→ FlexCard (via child card reference)
FlexCard ──→ OmniScript (via action configuration — launches OS)

Data Mapper ──→ Salesforce Object (via InputObjectName — read)
Data Mapper ──→ Salesforce Object (via OutputObjectName — write)

---

OmniScript Dependencies

Element Types and Their Dependency Targets

OmniScript elements are stored as OmniProcessElement records (Core) or Element__c records (Vlocity). Each element has a PropertySetConfig / PropertySet__c JSON field containing the configuration.

DataRaptor Transform Action

Calls a Data Mapper to extract, transform, or load data.

PropertySetConfig structure:

{
  "Type": "DataRaptor Transform Action",
  "PropertySet": {
    "bundle": "AccountExtract",
    "bundleName": "AccountExtract",
    "dataRaptorType": "Extract"
  }
}

Extraction rule: PropertySet.bundle or PropertySet.bundleName → resolves to an OmniDataTransform record by Name.

DataRaptor Turbo Action

High-performance variant of DataRaptor Transform Action. Same JSON structure, same extraction rule.

PropertySetConfig structure:

{
  "Type": "DataRaptor Turbo Action",
  "PropertySet": {
    "bundle": "AccountTurboExtract",
    "bundleName": "AccountTurboExtract"
  }
}

Integration Procedure Action

Calls an Integration Procedure.

PropertySetConfig structure:

{
  "Type": "Integration Procedure Action",
  "PropertySet": {
    "integrationProcedureKey": "TypeName_SubTypeName",
    "ipMethod": "TypeName",
    "ipType": "SubTypeName",
    "integrationProcedureVersion": 1
  }
}

Extraction rule: PropertySet.integrationProcedureKey → resolves to an OmniProcess record where Type_SubType matches and TypeCategory = 'IntegrationProcedure'.

OmniScript Action (Embedded OmniScript)

Embeds or launches another OmniScript.

PropertySetConfig structure:

{
  "Type": "OmniScript",
  "PropertySet": {
    "Type": "ChildScriptType",
    "Sub Type": "ChildScriptSubType",
    "Language": "English"
  }
}

Extraction rule: PropertySet.Type + PropertySet["Sub Type"] + PropertySet.Language → resolves to an OmniProcess where TypeCategory = 'OmniScript' and fields match.

Remote Action

Calls an Apex class method.

PropertySetConfig structure:

{
  "Type": "Remote Action",
  "PropertySet": {
    "remoteClass": "MyApexClassName",
    "remoteMethod": "myMethodName",
    "remoteTimeout": 30000
  }
}

Extraction rule: PropertySet.remoteClass → Apex class name. PropertySet.remoteMethod → method name. Dependency is remoteClass.remoteMethod.

HTTP Action

Calls an external HTTP endpoint.

PropertySetConfig structure:

{
  "Type": "HTTP Action",
  "PropertySet": {
    "httpUrl": "https://api.example.com/endpoint",
    "httpMethod": "POST",
    "namedCredential": "MyNamedCredential"
  }
}

Extraction rule: PropertySet.httpUrl or PropertySet.namedCredential → external dependency. If namedCredential is present, it references a Named Credential record.

Custom Lightning Web Component

Embeds an LWC inside the OmniScript.

PropertySetConfig structure:

{
  "Type": "Custom Lightning Web Component",
  "PropertySet": {
    "lwcName": "myCustomComponent",
    "lwcComponentName": "c-my-custom-component"
  }
}

Extraction rule: PropertySet.lwcName or PropertySet.lwcComponentName → LWC component reference.

DocuSign Envelope Action

Triggers a DocuSign envelope.

PropertySetConfig structure:

{
  "Type": "DocuSign Envelope Action",
  "PropertySet": {
    "docuSignTemplateId": "template-uuid"
  }
}

Extraction rule: PropertySet.docuSignTemplateId → DocuSign template (external dependency).

---

Integration Procedure Dependencies

Integration Procedures use the same element types as OmniScripts but are filtered by TypeCategory = 'IntegrationProcedure' (Core) or IsIntegrationProcedure__c = true (Vlocity).

Element Types Available in IPs

Nested IP Pattern

An Integration Procedure can call another Integration Procedure, creating a chain:

IP: OrderValidation
  └── IP Action → IP: CustomerLookup
       └── DR Action → DM: CustomerExtract
  └── IP Action → IP: InventoryCheck
       └── HTTP Action → External inventory API
  └── DR Action → DM: OrderTransform

---

FlexCard Dependencies

FlexCards store their entire configuration in the Definition JSON field on OmniUiCard (Core) or VlocityUITemplate__c (Vlocity).

Data Source Parsing

The Definition JSON contains a dataSources array:

{
  "dataSources": [
    {
      "name": "AccountData",
      "type": "IntegrationProcedure",
      "value": {
        "key": "fetchAccountData",
        "inputMap": { "AccountId": "{recordId}" }
      }
    },
    {
      "name": "DirectApex",
      "type": "Apex",
      "value": {
        "className": "AccountSummaryController",
        "methodName": "getSummary"
      }
    },
    {
      "name": "SObjectData",
      "type": "SObject",
      "value": {
        "sObjectType": "Account",
        "fields": ["Name", "Industry", "Phone"]
      }
    }
  ]
}

Extraction rules by data source type:

Child Card References

FlexCards can embed other FlexCards:

{
  "children": [
    {
      "cardName": "ContactListCard",
      "cardType": "childCard"
    }
  ]
}

Extraction rule: children[].cardName → resolves to another OmniUiCard by Name.

Action References

FlexCard actions can launch OmniScripts:

{
  "actions": [
    {
      "actionType": "OmniScript",
      "actionValue": {
        "type": "editAccount",
        "subType": "step1",
        "language": "English"
      }
    }
  ]
}

Extraction rule: actions[].actionValue.type + subType + language → resolves to an OmniScript.

---

Data Mapper Dependencies

Data Mappers (DataRaptors) reference Salesforce objects through their items.

Object References via Items

Each OmniDataTransformItem (Core) or DRMapItem__c (Vlocity) record contains:

Extract Type Data Mapper Example

DM: AccountExtract (Type: Extract)
├── Item 1: InputObjectName = "Account"
│   InputFieldName = "Name"
│   OutputFieldName = "AccountName"
├── Item 2: InputObjectName = "Account"
│   InputFieldName = "Industry"
│   OutputFieldName = "AccountIndustry"
└── Item 3: InputObjectName = "Contact"
    InputFieldName = "Email"
    OutputFieldName = "PrimaryEmail"

Dependencies: Account (read), Contact (read)

Load Type Data Mapper Example

DM: OrderCreate (Type: Load)
├── Item 1: OutputObjectName = "Order"
│   InputFieldName = "OrderData.accountId"
│   OutputFieldName = "AccountId"
└── Item 2: OutputObjectName = "OrderItem"
    InputFieldName = "OrderData.lineItems[].productId"
    OutputFieldName = "Product2Id"

Dependencies: Order (write), OrderItem (write)

Transform Type Data Mapper

Transform type Data Mappers do not reference Salesforce objects directly — they map between data structures. They have no sObject dependencies but may participate in a chain:

OmniScript → DR Extract (reads Account) → DR Transform (reshapes data) → DR Load (writes CustomObj__c)

---

Circular Dependency Detection

Why Circular Dependencies Occur

Circular references happen when component A depends on component B, which directly or transitively depends back on component A. Common scenarios:

1. OmniScript ↔ IP: OmniScript calls IP via IP Action, IP calls back to OmniScript via OmniScript Action 2. IP ↔ IP: IP A calls IP B via nested IP Action, IP B calls IP A 3. FlexCard → IP → OmniScript → FlexCard: FlexCard sources data from IP, IP triggers OmniScript, OmniScript launches FlexCard

Detection Algorithm

function detectCircularDependencies(graph):
    cycles = []
    for each node N in graph:
        visited = empty set
        path = empty list
        dfs(N, visited, path, graph, cycles)
    return cycles

function dfs(node, visited, path, graph, cycles):
    if node is in path:
        // Circular reference found
        cycleStart = index of node in path
        cycle = path[cycleStart:] + [node]
        cycles.append(cycle)
        return
    if node is in visited:
        return
    visited.add(node)
    path.append(node)
    for each neighbor of node in graph:
        dfs(neighbor, visited, path, graph, cycles)
    path.removeLast()

Reporting Circular References

When a cycle is detected, report it clearly:

CIRCULAR DEPENDENCY DETECTED:
  OS:editAccount → IP:validateAccount → OS:editAccount

Components in cycle:
  1. OmniScript "editAccount" (IP Action → validateAccount)
  2. Integration Procedure "validateAccount" (OmniScript Action → editAccount)

Risk: Runtime infinite loop if not guarded by conditional logic.
Recommendation: Review whether the back-reference is intentional and has
a termination condition.

---

Dependency Graph Construction

Step-by-Step Process

1. DETECT namespace (see namespace-guide.md)

2. QUERY all container objects:
   - OmniProcess (OmniScripts + IPs)
   - OmniUiCard (FlexCards)
   - OmniDataTransform (Data Mappers)

3. QUERY all element objects:
   - OmniProcessElement (for each OmniProcess)
   - OmniDataTransformItem (for each OmniDataTransform)

4. PARSE each element's PropertySetConfig:
   - Identify element Type
   - Extract dependency reference per extraction rules above
   - Resolve reference to a known component record

5. PARSE each FlexCard's Definition:
   - Extract dataSources array
   - Extract children array
   - Extract actions array
   - Resolve references to known components

6. PARSE each Data Mapper's items:
   - Extract InputObjectName / OutputObjectName
   - Resolve to sObject names

7. BUILD directed graph:
   - Nodes = all components + referenced sObjects + external endpoints
   - Edges = dependency references with type labels

8. DETECT circular references:
   - Run DFS cycle detection
   - Record all cycles found

9. COMPUTE impact analysis:
   - For each node, compute transitive closure of inbound edges
   - "If X changes, these components are affected"

Impact Analysis: Reverse Dependency Lookup

To answer "what breaks if I change Data Mapper X?", reverse the dependency direction:

Given: DM:AccountExtract

Direct dependents (components that reference this DM):
  → IP:fetchAccountData (DataRaptor Action)

Transitive dependents (components that reference the direct dependents):
  → OS:updateAccount (IP Action → fetchAccountData)
  → FC:AccountSummaryCard (Data Source → fetchAccountData)

Full impact set: [IP:fetchAccountData, OS:updateAccount, FC:AccountSummaryCard]

---

Property Set Config Parsing Tips

Handling Large JSON

PropertySetConfig can exceed 100KB for complex elements. When querying via SOQL:

• SOQL SELECT returns the full field value
• For very large configs, the Tooling API may be necessary
• Parse incrementally if memory is a concern

Nested Property Sets

Some elements have nested structures. Always check for:

• PropertySet.bundle (top-level reference)
• PropertySet.elementProperties (per-field configs)
• PropertySet.conditionalProperties (conditional logic)
• PropertySet.remoteOptions (additional remote action config)

Common Pitfalls

<!-- Parent: sf-industry-commoncore-omnistudio-analyze/SKILL.md -->

OmniStudio Namespace Reference Guide

Overview

Salesforce OmniStudio exists under three distinct namespaces depending on the org's industry package and migration status. Every OmniStudio operation must target the correct namespace — queries, metadata retrieval, and deployment all use namespace-specific object and field API names.

---

Detection Algorithm

Step-by-Step Probing

Run SOQL queries against each namespace's primary object. The first query that succeeds determines the namespace.

1. Probe Core:
   SELECT COUNT() FROM OmniProcess
   → Success? Namespace = Core. Stop.
   → Failure (INVALID_TYPE)? Continue.

2. Probe vlocity_cmt:
   SELECT COUNT() FROM vlocity_cmt__OmniScript__c
   → Success? Namespace = vlocity_cmt. Stop.
   → Failure (INVALID_TYPE)? Continue.

3. Probe vlocity_ins:
   SELECT COUNT() FROM vlocity_ins__OmniScript__c
   → Success? Namespace = vlocity_ins. Stop.
   → Failure (INVALID_TYPE)? OmniStudio not installed.

CLI Implementation

# Core probe
sf data query --query "SELECT COUNT() FROM OmniProcess" --target-org myorg --json 2>/dev/null
# Check: result.totalSize >= 0 means Core namespace

# vlocity_cmt probe
sf data query --query "SELECT COUNT() FROM vlocity_cmt__OmniScript__c" --target-org myorg --json 2>/dev/null

# vlocity_ins probe
sf data query --query "SELECT COUNT() FROM vlocity_ins__OmniScript__c" --target-org myorg --json 2>/dev/null

Interpreting Results

• Exit code 0 + JSON with `totalSize`: Namespace is present
• Exit code non-zero or `INVALID_TYPE` error: Namespace not installed
• Exit code 0 + `totalSize: 0`: Namespace exists but no components created yet (still valid)

---

Object Mapping

Primary Container Objects

These objects store OmniScript, Integration Procedure, FlexCard, and Data Mapper definitions.

Relationship Fields (Element → Parent)

---

Field Mapping

OmniProcess / OmniScript Fields

Note on TypeCategory vs IsIntegrationProcedure: In Core namespace, TypeCategory distinguishes OmniScripts from Integration Procedures ('OmniScript' vs 'IntegrationProcedure'). In Vlocity namespaces, use the boolean field IsIntegrationProcedure__c instead.

Element Fields

FlexCard / UI Template Fields

Data Mapper / DataRaptor Fields

Data Mapper Item Fields

---

Metadata Type Names for Deployment

When using sf project retrieve start or sf project deploy start, reference the correct metadata type:

Note: Only Core namespace components support standard Salesforce metadata API deployment. Vlocity namespace components require the Vlocity Build Tool (vlocity_build) for migration between orgs.

Retrieve Example (Core)

sf project retrieve start --metadata OmniScript --target-org myorg
sf project retrieve start --metadata OmniDataTransform --target-org myorg

---

Mixed Namespace Scenarios

During Core Migration

Organizations migrating from a Vlocity namespace to Core may temporarily have components under both namespaces. During this transition:

1. Probe both namespaces — if both return results, the org is mid-migration 2. Core components take precedence — runtime uses Core namespace objects when both exist 3. Report the state — alert the user that migration is in progress and both namespaces contain data 4. Do not modify Vlocity-namespace components — they are frozen during migration

Detection of Mixed State

# Check if Core has components
sf data query --query "SELECT COUNT() FROM OmniProcess" --target-org myorg --json 2>/dev/null

# Also check if Vlocity still has components
sf data query --query "SELECT COUNT() FROM vlocity_cmt__OmniScript__c" --target-org myorg --json 2>/dev/null

If both return totalSize > 0, the org is in a mixed namespace state.

Recommended Actions During Mixed State

• Inventory components under both namespaces
• Compare counts to assess migration progress
• Flag components that exist only in the old namespace (not yet migrated)
• Do not create components under the old namespace

---

Data Mapper Type Values

The Type field on OmniDataTransform / DRBundle indicates the mapper's purpose:

---

SOQL Query Templates

Core Namespace — Full Inventory

-- All OmniScripts
SELECT Id, Type, SubType, Language, IsActive, VersionNumber, LastModifiedDate
FROM OmniProcess
WHERE TypeCategory = 'OmniScript'
ORDER BY Type, SubType, Language, VersionNumber DESC

-- All Integration Procedures
SELECT Id, Type, SubType, Language, IsActive, VersionNumber, LastModifiedDate
FROM OmniProcess
WHERE TypeCategory = 'IntegrationProcedure'
ORDER BY Type, SubType, Language, VersionNumber DESC

-- All FlexCards
SELECT Id, Name, IsActive, AuthorName, VersionNumber, LastModifiedDate
FROM OmniUiCard
ORDER BY Name, VersionNumber DESC

-- All Data Mappers
SELECT Id, Name, Type, IsActive, InputType, OutputType, LastModifiedDate
FROM OmniDataTransform
ORDER BY Name

vlocity_cmt Namespace — Full Inventory

-- All OmniScripts
SELECT Id, vlocity_cmt__Type__c, vlocity_cmt__SubType__c,
       vlocity_cmt__Language__c, vlocity_cmt__IsActive__c, vlocity_cmt__Version__c
FROM vlocity_cmt__OmniScript__c
WHERE vlocity_cmt__IsIntegrationProcedure__c = false
ORDER BY vlocity_cmt__Type__c, vlocity_cmt__SubType__c

-- All Integration Procedures
SELECT Id, vlocity_cmt__Type__c, vlocity_cmt__SubType__c,
       vlocity_cmt__Language__c, vlocity_cmt__IsActive__c, vlocity_cmt__Version__c
FROM vlocity_cmt__OmniScript__c
WHERE vlocity_cmt__IsIntegrationProcedure__c = true
ORDER BY vlocity_cmt__Type__c, vlocity_cmt__SubType__c

-- All FlexCards / UI Templates
SELECT Id, Name, vlocity_cmt__IsActive__c, vlocity_cmt__Version__c
FROM vlocity_cmt__VlocityUITemplate__c
ORDER BY Name

-- All Data Mappers (DataRaptors)
SELECT Id, Name, vlocity_cmt__Type__c, vlocity_cmt__IsActive__c
FROM vlocity_cmt__DRBundle__c
ORDER BY Name

vlocity_ins Namespace — Full Inventory

-- All OmniScripts
SELECT Id, vlocity_ins__Type__c, vlocity_ins__SubType__c,
       vlocity_ins__Language__c, vlocity_ins__IsActive__c, vlocity_ins__Version__c
FROM vlocity_ins__OmniScript__c
WHERE vlocity_ins__IsIntegrationProcedure__c = false
ORDER BY vlocity_ins__Type__c, vlocity_ins__SubType__c

-- All Integration Procedures
SELECT Id, vlocity_ins__Type__c, vlocity_ins__SubType__c,
       vlocity_ins__Language__c, vlocity_ins__IsActive__c, vlocity_ins__Version__c
FROM vlocity_ins__OmniScript__c
WHERE vlocity_ins__IsIntegrationProcedure__c = true
ORDER BY vlocity_ins__Type__c, vlocity_ins__SubType__c

-- All FlexCards / UI Templates
SELECT Id, Name, vlocity_ins__IsActive__c, vlocity_ins__Version__c
FROM vlocity_ins__VlocityUITemplate__c
ORDER BY Name

-- All Data Mappers (DataRaptors)
SELECT Id, Name, vlocity_ins__Type__c, vlocity_ins__IsActive__c
FROM vlocity_ins__DRBundle__c
ORDER BY Name