#Vlocity16 人がディスカッション中

I got an answer from a salesforce dev that solves this for me.

"Once you are in discovery framework mode all of the supported elements need to be created as questions - i.e. they are no longer available in the omniscript designer since you are building a discovery framework assessment and the supported elements need to be represented as questions."

That totally explains why, just a shame there is no documentation that I could find to tell me that in the first place :/

@Alan Mccarthy DataLakeObjectInstance is the catalog row for the lake object, not the CSV rows. A Data Mapper Extract only queries Salesforce objects, and a DMO is not one of those. That is why the mapper never lists your records.

Read the DMO from an Integration Procedure, with a Data Cloud query, as a user who can query that data space. Map that response into the FlexCard. Leave DataLakeObjectInstance out of it.

If the card sits on a Salesforce record and you only need the rows for that record, relate the DMO back to it with a key you already have, and query with that key. A mapper on the CRM object still will not see the lake.

@Augusto Sigolo that SOQL is a dead end. It returned zero rows, and it already compares dates. The exception is Apex inside the managed checkout, assigning a string into a Date field. You cannot patch CpqAppHandler.

Checkout walks more than the OrderItem to Asset mapper. It also applies attribute-to-field bindings. The usual case is a product attribute whose value type is Text, mapped onto a Date field. The attribute JSON stores the value as text even when it looks like a date.

On a cart that fails, open the line attribute JSON and look for a date-shaped string on an attribute bound to a Date field. Fix the attribute value type, or stop mapping that attribute onto the Date field. A string in that JSON throws this on every checkout path, which matches what you are seeing.

@Mahdi Ahbab the mapper preview updates because your test input has the Quote Id. The OmniScript is not sending that Id, so Salesforce tries to insert a Quote, and a new Quote requires Name.

In the OmniScript preview debug, look at the JSON going into that Post action. If Id is missing, or it sits under a different node than the mapper expects, that is the insert. Map the Quote Id from the script into the mapper input and use it as the upsert key. Do not send Name unless you actually want a new Quote.

The sample Single Doc Core script has its own data JSON. An extra step will not put Id where the mapper looks unless you mapped that node. The mapper itself is fine. You already proved that in its own preview.

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 @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