OmniStudio

kipmox reads your packaged OmniStudio (Vlocity) DataPacks — DataRaptors, Integration Procedures, OmniScripts, and FlexCards — into the same dependency graph as your Apex, LWC, Flows, and fields. So your agent can answer “what does this change break across my OmniStudio components?” and “do all my OmniStudio references still resolve?” — deterministically, from the repository, with no org connection.

​

The problem: OmniStudio references are strings, not code

In Apex, calling a method that doesn’t exist won’t compile — the deploy fails and you find out immediately. References are typed and checked. In OmniStudio, references are just strings inside JSON. An OmniScript step calls a DataRaptor by bundle name ("bundle": "SavePolicyData"); an Integration Procedure calls another IP by procedure key; a FlexCard points at an IP by ipMethod. Nothing validates those strings at deploy time. So this happens constantly:

1. A developer renames or deletes a DataRaptor (or fat-fingers a procedure key).
2. A component elsewhere still references the old name.
3. It deploys clean — green checkmark, ships to production.
4. A user runs that OmniScript, hits that step, and gets a silent runtime error — in production.

That whole class of failure is invisible to a text search and to the standard deploy pipeline. It’s exactly what kipmox’s OmniStudio support is built to catch.

​

What kipmox sees

kipmox parses the real, VBT-expanded DataPack format (a folder per component) and is namespace-agnostic (vlocity_cmt__, vlocity_ins__, or the %vlocity_namespace%__ token). It scans your whole project — including an untracked vlocity/ directory — and links every component into one graph: Because a DataRaptor’s field maps onto the same field node your Apex uses, a field change blasts through both Apex and OmniStudio in a single graph — no separate engine.

​

Change impact: a field change through the Omni chain

Ask your agent “what breaks if I delete / rename / make required Account.Status__c?” and analyze_change_impact walks the field into the OmniStudio chain: field → DataRaptor → Integration Procedure → OmniScript → FlexCard The reference at each hop is a different string — the field API name, then the DataRaptor’s output alias, then the IP’s procedure key — spread across separate files. A text search for Status__c stops at the DataRaptor; only the dependency graph follows it to the OmniScript. All six change types are covered — deleted, renamed, required, picklist-value-removed, type-changed, length-shortened — and impacted components are classified by:

• Write path — components that write the value (through a Load DataRaptor). If the value is removed or the field deleted, these fail at runtime.
• Read path — components that only read / display the value. They won’t error, but logic that branches on the value may silently go stale.

For a compile-breaking field change (deleted / renamed / type-changed), the same call also returns the Apex transitive compile-cascade and the exact tests to run — the Apex classes that break because they depend on the field-touching classes, with no literal reference to the field.

​

Where-used: what depends on an OmniStudio component

Target a DataRaptor, Integration Procedure, OmniScript, FlexCard — or a field — by name with analyze_impact to get its blast radius:

• downstream — everything that would break if you change it (the IPs and OmniScripts that run a DataRaptor, multi-hop through IP → IP chains).
• upstream — everything it depends on.
• cross-object precise — a change to Policy__c.Amount__c does not drag in Payment__c.Amount__c, even though they share a field name. The graph is keyed by object + field; a search isn’t.

​

Reference integrity: “do all my OmniStudio references resolve?”

verify_omni_references scans every active OmniScript, Integration Procedure, and FlexCard and reports each DataRaptor / IP / Apex Remote-Action call whose target does not exist in the project — the silent-runtime breaks described above. Because it’s deterministic and exits with findings, verify_omni_references drops straight into a CI / PR gate or a pre-commit hook — a dangling DataRaptor reference turns the PR red before it can merge. A Salesforce deploy validation can’t be extended to do that; a kipmox check can.

​

What kipmox doesn’t check yet

kipmox is honest about its blind spots, and OmniStudio is no exception:

• Field-level references (a DataRaptor mapping a field that doesn’t exist) — resolving these from local files alone is noisy (standard fields have no metadata; custom fields may live in the org but not be retrieved). This needs an org-connected map and is reported as a coverage note today, not guessed at.
• Dynamic %merge% keys — a procedure key resolved from data at runtime (%NotificationProcedure%) can’t be verified statically.
• Inactive components and references inside them — excluded, because they don’t run.
• Platform/standard OmniStudio metadata (OmniProcess, OmniUiCard) — current support is for packaged Vlocity DataPacks.