#Omnistudio11 personnes en discutent

Hi Michael, 

You don't need NavigationMixin — you need OmniscriptBaseMixin, which is purpose-built for exactly this (works with the managed package too). Your Custom LWC should import and extend it; that gives you omniNextStep(), omniPrevStep(), and omniNavigateTo(step) directly, no event bubbling required. 

```js 

import { OmniscriptBaseMixin } from 'vlocity_cmt/omniscriptBaseMixin'; // or your org's namespace 

export default class MyCustomLwc extends OmniscriptBaseMixin(LightningElement) { 

    nextButton(evt) { 

        this.omniNextStep(); 

    } 

    goToStep(evt) { 

        this.omniNavigateTo(this.omniScriptHeaderDef.asIndex + 1); // or a step element name as a string 

    } 

} 

``` 

Notes: 

- omniNavigateTo(step) accepts either a numeric step index or a step's element name as a string. 

- You can't auto-advance more than one step ahead with omniNavigateTo — it's restricted to adjacent navigation for state-integrity reasons. 

- The same mixin also gives you methods to read/update the OmniScript's data JSON directly from your component, so you likely don't need the event-bubbling approach at all for data passing either — that's really meant for parent-to-child communication patterns, not LWC-to-OmniScript control. 

To your "why doesn't the managed package allow it" question: it does — this isn't a restriction, it's just that NavigationMixin (the generic Salesforce page-navigation API) was never the right tool here. OmniscriptBaseMixin is the namespaced, OmniStudio-specific equivalent that handles step navigation plus data sync, which NavigationMixin was never designed to do. 

Reference:

Hi @Rahul Khedkar

A common supported approach is to keep the navigation state in the parent OmniScript and treat Step 2 as an edit mode rather than trying to make the Step 2 Continue button directly jump to an arbitrary step index. When Step 7 opens Step 2, store a flag such as returnToStep7 = true in the OmniScript data JSON. Then, on Step 2 Continue, your custom LWC can check that flag and invoke the parent OmniScript navigation logic to return to Step 7; otherwise, it follows the normal Step 2 → Step 3 flow. This avoids hard-coding unsupported step-index navigation inside the LWC and works well for an Edit → Return pattern. If you share your current custom LWC navigation code, I can show the exact implementation for your OmniScript.

A Milestone being the last item is usually the clue here. In Industries (Vlocity) Order Management a Milestone is only a marker: it completes automatically once all of its "Depends On" items are complete, and it never fails, but it does not do any work itself. Completing the milestone does not by itself update the Order record, so an order can sit "In Progress" even though every item on the plan looks green. These are the checks I would go through: 

1. Confirm every item on the plan really is finished. In the orchestration plan view (or by querying the Orchestration Item records for that plan), look for any item that is not Completed, for example Pending, Ready, Running, Failed or Frozen, including items in other swimlanes or in plans of other decomposed/fulfilment-request orders. A single item still pending (often a manual task or a callout waiting for a response) keeps the plan open. 

2. Check that the background processing is running. Orchestration items are progressed by Industries OM asynchronous jobs. Look at Setup > Apex Jobs and Scheduled Jobs for failed or aborted vlocity_cmt jobs and at the debug logs for the user running orchestration. If the jobs are not scheduled or are failing, the plan state is never re-evaluated. 

3. Make sure something actually updates the Order status. Order status normally changes because of an Auto Task in the plan (commonly the asset-creation / order-completion step near the end), not because the last milestone completed. If your plan ends with only a Milestone, add an Auto Task after it (dependency: Depends On the milestone) whose item implementation updates the Order status or runs your standard "create assets / complete order" logic, and re-test with a new order. 

4. For the stuck order itself, once you have found the cause you can retry the failed item from the plan view, or complete the remaining item manually, and the plan should move to Completed. 

References: 

Understanding Order Management Orchestration Basics (Trailhead):

The Industries Order Management Solution:

Troubleshooting Industries Order Management:

Assumption: I am assuming this is managed-package (vlocity_cmt) Industries Order Management with a standard plan where the Order status is expected to be updated by a task in the plan. Exact job names and item implementations differ by release and by how your plan definition was built, so please share the state of each orchestration item and whether any Auto Task follows the milestone if the checks above don't resolve it.

Hi Rakesh - the root issue is that the window online/offline events (and navigator.onLine) are inherently unreliable, and Linux Chrome is the worst case. Chromium marks the browser 'online' whenever there is any network interface with an IP - even a virtual or IPv6 adapter with no real internet - and it often never fires the offline event on Linux. So on that one Ubuntu user's machine the events genuinely will not fire; it is a documented Chromium limitation, not your code. 

So do not gate your OmniScript logic on those events. Two robust patterns instead: 

1. Handle the failure at the call, not before it. Wrap the DataRaptor IP remote action so that when it fails (network error or timeout) you catch it and show your friendly 'you are offline' message plus a real retry - rather than trying to predict offline up front. In OmniScript, use the element's error handling / a Set Errors plus conditional navigation so the hard error banner never shows. 

2. If you want a proactive signal, run a lightweight heartbeat - a periodic fetch to a tiny known endpoint with a short timeout - and treat a failed or timed-out fetch as offline. That actually tests reachability, which the browser events do not. 

navigator.onLine is fine as a hint (if it says false, you are definitely offline), but never as the source of truth. Catching the actual remote-action failure is what fixes the ungraceful error for everyone, including that Ubuntu user. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

@Vijay Sadhu

, 

Check the official article below; it will help you, 

If the JSON is being updated correctly, then the issue is likely related to the OmniScript UI not re-rendering after the LWC updates the data.

A few things I'd check:

•  Make sure the data is being updated through omniApplyCallResp() or another supported OmniScript API. 
•  Verify whether the read-only fields are bound directly to the updated JSON node. 
•  Some OmniScript elements don't automatically refresh when data changes outside their lifecycle. In those cases, navigating to the next step and back often confirms whether it's a rendering issue rather than a data issue. 
•  If you're using a custom LWC, you may need to trigger a refresh/re-render after updating the OmniScript data. 

If the values appear correctly in the OmniScript JSON but not on screen, focus on how those specific read-only fields are being rendered and whether they're re-evaluating their data source after the update.

Hi, 

Transform the value before passing to DataRaptor

Option A — Formula Element in OmniScript Add a Formula element after the Time picker:

%timeField% & ":00.000Z"

This turns 14:00 → 14:00:00.000Z. Map this formula output to DataRaptor, not the raw picker value. 

Option B — SetValues / DataJSON manipulation Use a SetValues element to construct the correct string:

json

{
  "transformedTime": "{timeField}:00.000Z"
}

Use a Transform action in an Integration Procedure to append :00.000Z before the Load step hits Salesforce.