Analyzing Omnistudio Dependencies

analyzing-omnistudio-dependencies: OmniStudio Cross-Component Analysis

Expert OmniStudio analyst specializing in namespace detection, dependency mapping, and impact analysis across the full OmniStudio component suite. Performs org-wide inventory of OmniScripts, FlexCards, Integration Procedures, and Data Mappers with automated dependency graph construction and Mermaid visualization.

Scope

• In scope: Namespace detection (Core / vlocity_cmt / vlocity_ins), org-wide component inventory, dependency graph construction, impact analysis, Mermaid diagram generation
• Out of scope: Authoring or modifying OmniScripts (use building-omnistudio-omniscript), building FlexCards (use building-omnistudio-flexcard), creating Integration Procedures (use building-omnistudio-integration-procedure), configuring Data Mappers (use building-omnistudio-datamapper)

Required Inputs

Ask for or infer before starting:

Output Expectations

Each analysis run produces one or more of:

1. Namespace detection result — which namespace is active (Core / vlocity_cmt / vlocity_ins / not installed)
2. Component inventory — counts of OmniScripts, Integration Procedures, FlexCards, Data Mappers (active vs draft)
3. Dependency graph — directed edges between all OmniStudio components with edge type labels
4. Mermaid diagram — copy-pasteable Mermaid graph LR block for documentation
5. JSON summary — machine-readable namespace + components + dependencies + impact analysis
6. Human-readable report — plain-text summary with component counts, edge count, circular references, and most-depended components
7. Circular reference warnings — cycle path and risk statement for each detected cycle

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: analyzing-omnistudio-dependencies → building-omnistudio-datamapper → building-omnistudio-integration-procedure → building-omnistudio-omniscript → building-omnistudio-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+).

1. vlocity_cmt (Communications, Media & Energy): ``soql SELECT COUNT() FROM vlocity_cmt__OmniScript__c ``

1. 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 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 — paginate with LIMIT/OFFSET for large orgs):

SELECT Id, Type, SubType, Language, IsActive, VersionNumber,
       PropertySetConfig, LastModifiedDate
FROM OmniProcess
WHERE IsIntegrationProcedure = false
ORDER BY Type, SubType, Language, VersionNumber DESC
LIMIT 200

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

FlexCards (Core example):

SELECT Id, Name, IsActive, DataSourceConfig, PropertySetConfig,
       AuthorName, LastModifiedDate
FROM OmniUiCard
ORDER BY Name
LIMIT 200

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

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