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), needs impact analysis, or requests dependency diagrams. DO NOT TRIGGER when: authoring OmniScripts (use sf-industry-commoncore-omniscript), building FlexCards (use sf-industry-commoncore-flexcard), creating Integration Procedures (use sf-industry-commoncore-integration-procedure), or configuring Data Mappers (use sf-industry-commoncore-datamapper).
Instrucciones de origen · Vista previa de solo lectura
name
sf-industry-commoncore-omnistudio-analyze
description
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), needs impact analysis, or requests dependency diagrams. DO NOT TRIGGER when: authoring OmniScripts (use sf-industry-commoncore-omniscript), building FlexCards (use sf-industry-commoncore-flexcard), creating Integration Procedures (use sf-industry-commoncore-integration-procedure), or configuring Data Mappers (use sf-industry-commoncore-datamapper).
license
MIT
metadata
{"version":"1.0.0","author":"David Ryan (weytani)"}
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
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:
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:
Core (Industries namespace):
SELECT COUNT() FROM OmniProcess
If this succeeds, the org uses the Core namespace (API 234.0+ / Spring '22+).
vlocity_cmt (Communications, Media & Energy):
SELECT COUNT() FROM vlocity_cmt__OmniScript__c
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.
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:
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:
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)
# 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
Skill
Relationship
How This Skill Helps
sf-industry-commoncore-datamapper
Provides namespace and object dependency data
Data Mapper authoring uses detected namespace for correct API names
sf-industry-commoncore-integration-procedure
Provides namespace and IP dependency map
IP authoring uses dependency graph to avoid circular references
sf-industry-commoncore-omniscript
Provides namespace and element dependency data
OmniScript authoring uses namespace-correct field names
sf-industry-commoncore-flexcard
Provides namespace and data source dependency map
FlexCard authoring uses detected IP references for validation
sf-diagram-mermaid
Consumes dependency graph for visualization
This skill generates Mermaid output compatible with sf-diagram-mermaid styling
sf-metadata
Provides sObject metadata for Data Mapper analysis
Object field validation during dependency extraction
sf-deploy
Deployment uses namespace-correct metadata types
This skill provides the correct metadata type names per namespace
Edge Cases
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: 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.
