omnistudio-dependencies-analyze: 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
omnistudio-omniscript-generate), building FlexCards (useomnistudio-flexcard-generate), creating Integration Procedures (useomnistudio-integration-procedure-generate), configuring Data Mappers (useomnistudio-datamapper-generate)
Required Inputs
Ask for or infer before starting:
Output Expectations
Each analysis run produces one or more of:
- Namespace detection result — which namespace is active (Core / vlocity_cmt / vlocity_ins / not installed)
- Component inventory — counts of OmniScripts, Integration Procedures, FlexCards, Data Mappers (active vs draft)
- Dependency graph — directed edges between all OmniStudio components with edge type labels
- Mermaid diagram — copy-pasteable Mermaid
graph LRblock for documentation - JSON summary — machine-readable namespace + components + dependencies + impact analysis
- Human-readable report — plain-text summary with component counts, edge count, circular references, and most-depended components
- Circular reference warnings — cycle path and risk statement for each detected cycle
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:
omnistudio-dependencies-analyze→omnistudio-datamapper-generate→omnistudio-integration-procedure-generate→omnistudio-omniscript-generate→omnistudio-flexcard-generateThis 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:
-
Core (Industries namespace):
If this succeeds, the org uses the Core namespace (API 234.0+ / Spring '22+).
-
vlocity_cmt (Communications, Media & Energy):
-
vlocity_ins (Insurance & Health):
If none succeed, OmniStudio is not installed in the org.
CLI Commands for namespace detection:
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 — paginate with LIMIT/OFFSET for large orgs):
Integration Procedures (Core example):
FlexCards (Core example):
IMPORTANT: The
OmniUiCardobject does NOT have aDefinitionfield. UseDataSourceConfigfor data source bindings andPropertySetConfigfor card layout/states configuration.
Data Mappers (Core example):
Data Mapper Items (for object dependency extraction):
IMPORTANT: The foreign key field is
OmniDataTransformationId(full word "Transformation"), NOTOmniDataTransformId.
CLI Command pattern:
Phase 3: Dependency Analysis
Purpose: Parse component metadata to build a directed dependency graph.
Algorithm: BFS with Circular Detection
Element Type → Dependency Extraction
OmniScript and IP elements store references in the PropertySetConfig JSON field. Parse each element to extract dependencies:
Parsing PropertySetConfig:
FlexCard Data Source Parsing
FlexCards store their data source configuration in the DataSourceConfig JSON field (NOT Definition — that field does not exist on OmniUiCard):
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:
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
Color scheme:
Output Format 2: JSON Summary
Output Format 3: Human-Readable Report
Namespace Object/Field Mapping
For the complete object name, field name, and metadata type mapping across all three namespaces (Core, vlocity_cmt, vlocity_ins), read:
references/namespace-guide.md [blocked]
Key discriminators to keep in mind:
- Core uses
OmniProcess/OmniUiCard/OmniDataTransform - vlocity_cmt uses
vlocity_cmt__OmniScript__c/vlocity_cmt__VlocityUITemplate__c/vlocity_cmt__DRBundle__c - vlocity_ins uses
vlocity_ins__OmniScript__c/vlocity_ins__VlocityUITemplate__c/vlocity_ins__DRBundle__c - The
IsIntegrationProcedureboolean andDataSourceConfig(notDefinition) field names are Core-only
CLI Commands Reference
Namespace Detection
Component Inventory (Core Namespace)
Dependency Data Extraction (Core Namespace)
Cross-Skill Integration
Gotchas
Notes
- Dependencies: Requires
sfCLI with org authentication. Optional: external-diagram-mermaid-generate 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. - Related skills:
omnistudio-datamapper-generate,omnistudio-integration-procedure-generate,omnistudio-omniscript-generate,omnistudio-flexcard-generate— install these to enable the full OmniStudio authoring suite
Pre-Delivery Checklist
- Namespace detected before any downstream queries
- Orchestration order followed (this skill runs first in the chain)


