#Vlocity14 discussing

Hi @Madeline Knecht

- OmniscriptBaseMixin only works inside an OmniScript runtime. If you access omniJsonData in connectedCallback, the preview hangs  

• Use the LWC only inside an OmniScript
• Don’t use connectedCallback
• Access data in renderedCallback instead
• Make sure the OmniScript type is LWC and you’re previewing the OmniScript, not the LWC

import { LightningElement } from 'lwc';
import { OmniscriptBaseMixin } from 'omnistudio/omniscriptBaseMixin';
export default class TestOmniMixin extends OmniscriptBaseMixin(LightningElement) {
    renderedCallback() {
        console.log('omniJsonData:', this.omniJsonData);
    }
}

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.

Hii  

   Ritik, 

Please try these in order: 

1. Reset the component. In Experience Builder, set Type, SubType and Language again by hand. By default the component picks the first active OmniScript. Then publish.
2. Redeploy. Deactivate and activate the OmniScript. On the managed package designer with standard runtime, click Deploy Standard Runtime Compatible LWC. Publish the site again.
3. Isolate the cause. Clone the OmniScript and remove the first prefill Data Mapper or Integration Procedure. If the clone renders, the problem is access for those calls.
4. Check user-context access. With DefaultRequiredPermission set in OmniInteractionConfig, Data Mappers run as the user and need the required custom permission. The community user needs Read access to all objects and fields used, sharing access to the records, and Apex class access for any classes called.
5. Find the real error. Use "Log in to Experience as User" on the live site, then check the Network tab and a debug log for that user.
6. If the site is LWR, confirm OmniStudio standard runtime is enabled. If it still fails, open a case with Salesforce Support.

Is your site Aura or LWR, and are the users logged in or guests?

https://help.salesforce.com/apex/HTViewHelpDoc?id=xcloud.os_add_your_omniscript_to_an_experience_page_19992.htm

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 Eli,

The ContentDocumentId error usually indicates that the DataRaptor Load is trying to create a ContentDocumentLink record without receiving a valid ContentDocumentId from the file upload response.

Since the first four uploads are working with the same approach, I would compare the JSON output and DataRaptor mapping for the working and non-working upload elements, especially the ContentDocumentId value and the array structure when multiple files are uploaded.

Also check that the file upload element's response is being passed to the DataRaptor before the ContentDocumentLink records are created. Making the upload optional only prevents the field from being required; it won't resolve a ContentDocumentLink being created with a blank ContentDocumentId. 

If you're still seeing the issue, could you share the JSON for one working upload and one of the failing uploads, along with the relevant DataRaptor Load mapping? That would make it easier to identify the difference.