> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kipmox.com/llms.txt
> Use this file to discover all available pages before exploring further.
# OmniStudio
> Change impact, where-used, and reference verification for OmniStudio — DataRaptors, Integration Procedures, OmniScripts, and FlexCards — in the same dependency graph as your Apex and metadata. Deterministic, from the repo, no org required.
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**.
> [!NOTE]
>
> OmniStudio is the layer nothing else verifies. Salesforce's Code Analyzer excludes it; deploy validation doesn't check that a referenced DataRaptor or Integration Procedure actually exists; deployment tools move it but don't verify it. kipmox treats OmniStudio as a first-class part of your dependency graph.
## 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:
| Component | Tracked relationships |
| - | - |
| **DataRaptor** | the SObject fields it reads (Extract) or writes (Load/Post/Turbo) |
| **Integration Procedure** | the DataRaptors, other IPs, and Apex Remote Actions it calls |
| **OmniScript** | the IPs and DataRaptors it runs, through output **aliases** |
| **FlexCard** | the Integration Procedure behind its data source |
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`](https://docs.kipmox.com/agent/tools#analyze-change-impact) walks the field into the OmniStudio chain:
**field → DataRaptor → Integration Procedure → OmniScript → FlexCard**
```mermaid theme={null}
flowchart LR
F["Account.Status__c
the field"]
DR["DataRaptor
AccountExtract"]
IP["Integration Procedure
Customer_Profile"]
OS["OmniScript
Customer_AccountUpdate"]
F -- "Status__c" --> DR
DR -- "alias: CustomerStatus" --> IP
IP -- "key: Customer_Profile" --> OS
```
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.
> [!NOTE]
>
> **The alias trap — why a search can't do this.** A DataRaptor maps `Legacy_Code__c` to an output alias `LegacyCode`; an OmniScript consumes it as `%…:LegacyCode%`. The field name, the DataRaptor name, the IP's procedure key, and the alias are **four different strings in four different files** — none of them the field's API name. A text search for `Legacy_Code__c` finds the DataRaptor mapping and stops. Only the dependency graph connects the field all the way to the OmniScript.
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`](https://docs.kipmox.com/agent/tools#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`](https://docs.kipmox.com/agent/tools#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.
**1. You rename or delete a component**
Say you rename the DataRaptor `AccountExtract`, but three Integration Procedures still call it by its old name.
**2. Your agent runs verify\_omni\_references**
kipmox scans the active OmniStudio layer and finds every unresolved reference — deterministically, in one call.
**3. You fix it before it ships**
It reports all three broken IPs (not just the one you remembered), with the file and the likely fix — before the change deploys clean and fails in production.
verify\_omni\_references in an AI coding agent: one renamed DataRaptor silently broke three Integration Procedures — all would have deployed clean.
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**.
> [!NOTE]
>
> OmniStudio support is **local-first**: it reads the DataPacks in your project. For a team with the full Omni layer in source control, that's complete. A project with piecemeal-retrieved OmniStudio may *under-report* blast radius — connect your org for complete coverage (coming). The results always state their coverage so you know where a human check is still needed.
> **[Tools](https://docs.kipmox.com/agent/tools.md)**
>
> analyze\_change\_impact, analyze\_impact, verify\_omni\_references
> **[Quickstart](https://docs.kipmox.com/agent/quickstart.md)**
>
> Sign in, add the MCP server, run your first analysis
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.