sf-industry-commoncore-omnistudio-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 jaganpro · 985 installs
npx skills add jaganpro/sf-skills --skill sf-industry-commoncore-omnistudio-analyze
Source repository · Upstream listing
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
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):
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
Complete mapping of OmniStudio objects and fields across all three namespaces:
Primary Objects
Concept Core vlocity cmt vlocity ins
OmniScript / IP container OmniProcess vlocity cmt OmniScript c vlocity ins OmniScript c
OmniScript / IP elements OmniProcessElement vlocity cmt Element c vlocity ins Element c
FlexCard OmniUiCard vlocity cmt VlocityUITemplate c vlocity ins VlocityUITemplate c
Data Mapper OmniDataTransform vlocity cmt DRBundle c vlocity ins DRBundle c
Data Mapper Item OmniDataTransformItem vlocity cmt DRMapItem c vlocity ins DRMapItem c
Key Fields
Concept Core Field vlocity cmt Field vlocity ins Field
Script type Type vlocity cmt Type c vlocity ins Type c
Script subtype SubType vlocity cmt SubType c vlocity ins SubType c
Language Language vlocity cmt Language c vlocity ins Language c
Is active IsActive vlocity cmt IsActive c vlocity ins IsActive c
Version VersionNumber vlocity cmt Version c vlocity ins Version c
Element config PropertySetConfig vlocity cmt PropertySet c vlocity ins PropertySet c
Is Integration Procedure IsIntegrationProcedure vlocity cmt IsIntegrationProcedure c vlocity ins IsIntegrationProcedure c
FlexCard data sources DataSourceConfig vlocity cmt Definition c vlocity ins Definition c
FlexCard layout/states PropertySetConfig (same field) (same field)
DM input object InputObjectName (on Item) vlocity cmt InterfaceObject c vlocity ins InterfaceObject c
DM output object OutputObjectName (on Item) vlocity cmt TargetFieldObjectType c vlocity ins TargetFieldObjectType c
See : [references/namespace guide.md](references/namespace guide.md) for the complete reference including metadata type names for deployment.
CLI Commands Reference
Namespace Detection
Component Inventory (Core Namespace)
Dependency Data Extraction (Core Namespace)
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.
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)