omnistudio-dependencies-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 vlocity_cmt vs vlocity_ins
By forcedotcom · 4,639 installs
npx skills add forcedotcom/sf-skills --skill omnistudio-dependencies-analyze
Source repository · Upstream listing
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 (use omnistudio flexcard generate ), creating Integration Procedures (use omnistudio integration procedure generate ), configuring Data Mappers (use omnistudio datamapper generate )
Required Inputs
Ask for or infer before starting:
Input Default if not provided
Target org alias Ask the user
Analysis scope Full org (all OmniStudio component types)
Specific component to impact analyze None (produce full inventory first)
Output format preference All three: Mermaid diagram + JSON summary + human readable report
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:
omnistudio dependencies analyze → omnistudio datamapper generate → omnistudio integration procedure generate → omnistudio omniscript generate → omnistudio flexcard generate
This 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:
1. Core (Industries namespace) :
If this succeeds, the org uses the Core namespace (API 234.0+ / Spring '22+).
2. vlocity cmt (Communications, Media & Energy) :
3. 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](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):
Integration Procedures (Core example):
FlexCards (Core example):
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):
Data Mapper Items (for object dependency extraction):
IMPORTANT : The foreign key field is OmniDataTransformationId (full word "Transformation"), NOT OmniDataTransformId .
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:
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 :
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), not IntegrationProcedure .
Data Mapper Object Dependencies
Data Mappers reference Salesforce objects via their items:
See : [references/dependency patterns.md](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
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
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](references/namespace guide.md)
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 IsIntegrationProcedure boolean and DataSourceConfig (not Definition ) field names are Core only
CLI Commands Reference
Namespace Detection
Component Inventory (Core Namespace)
Dependency Data Extraction (Core Namespace)
Cross Skill Integration
Skill Relationship How This Skill Helps
omnistudio datamapper generate Provides namespace and object dependency data Data Mapper authoring uses detected namespace for correct API names
omnistudio integration procedure generate Provides namespace and IP dependency map IP authoring uses dependency graph to avoid circular references
omnistudio omniscript generate Provides namespace and element dependency data OmniScript authoring uses namespace correct field names
omnistudio flexcard generate Provides namespace and data source dependency map FlexCard authoring uses detected IP references for validation
external diagram mermaid generate Consumes dependency graph for visualization This skill generates Mermaid output compatible with external diagram mermaid generate styling
platform custom object generate / platform custom field generate Provides sObject metadata for Data Mapper analysis Object field validation during dependency extraction
platform metadata deploy Deployment uses namespace correct metadata types This skill provides the correct metadata type names per namespace
Gotchas
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 sf CLI 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 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.
Related s