Interview Questions - Salesforce OmniStudio Developer

OmniStudio : OmniScript, FlexCard, DataRaptors and Integration Procedures (IPs)

1. How can we call an Apex class from an Integration Procedure (IP)?

   Answer: To call an Apex class from an Integration Procedure, you use the Remote Action element.

   • Drag the Remote Action element into your IP execution structure.
   • In the properties pane, specify the Remote Class (the name of your Apex class) and the Remote Method (the specific method you want to execute).
   • Pass the input parameters via the Element Parameter or the standard input JSON mapping.

2. Why do we implement an interface in the Apex class to call via Remote Action?

   Answer: OmniStudio requires a predictable contract or hook to interact with Apex dynamically. The Apex class must implement the vlocity_cmt.VlocityOpenInterface (or omnistudio.VlocityOpenInterface depending on your managed package version).

   Implementing this interface forces the inclusion of the standard invokeMethod function:

   global boolean invokeMethod(String methodName, Map<String, Object> input, Map<String, Object> output, Map<String, Object> options)

   This single entry point allows OmniStudio components to seamlessly pass payload data (input), receive data back (output), handle configurations (options), and dynamically route to the correct logic based on the incoming methodName.

3. How can we perform a callout from an IP?

   Answer: You perform a web service callout in an Integration Procedure using an HTTP Action element.

   • Configure the element with the target HTTP Method (GET, POST, PUT, DELETE).
   • Reference a Salesforce Named Credential or a specific endpoint URL.
   • Map your input JSON data to the request body/headers and specify how the response JSON should be merged back into the IP's data tree.

4. If the callout timeout failed, how are you handling it in IP?

   Answer: To handle a callout timeout or general HTTP failures in an IP, use the following strategies:

   1. Check the Node Block: Use a Conditional Block to inspect the response node of the HTTP Action. When an HTTP action fails, it typically returns an error node (e.g., HTTPActionName:errors).
   2. Try-Catch Block: Wrap the HTTP Action inside a Try-Catch Block element. If the action times out or throws an unhandled exception, execution drops to the "Catch" path, allowing you to gracefully log the error or provide default fallback data.
   3. Fail-on-Error settings: You can toggle the Fail on Error property on the action to control whether a failure stops the entire IP execution or allows it to proceed.

5. If you are calling an IP from an OmniScript and the IP execution fails, how are you showing the error in the UI?

   Answer: When an IP encounters an error, it should pass a structured error message back to the OmniScript via a Response Action (for example, passing a key-value pair like {"hasError": true, "errorMessage": "Something went wrong"}).

   In the OmniScript UI designer:

   • Use a Messaging Element (Set Errors / Messaging).
   • Set its type to Requirement or Error.
   • Configure the element's conditional visibility to display only when the IP response contains hasError == true, rendering the errorMessage text dynamically to the end user.

6. In an IP there are 10 elements. The 3rd element failed, but I still want to execute the 9th and 10th elements. How will you do that?

   Answer: By default, if an element fails in an IP, it can halt processing depending on configuration. To ensure execution continues:

   • Clear/uncheck the Fail On Error checkbox on the 3rd element's properties. This instructs the IP to log the failure in the data tree but proceed directly to the next sequential element.
   • Alternatively, wrap the 3rd element inside its own Try-Catch Block so that any failure inside it is safely self-contained without crashing the parent process.

7. What are the best practices for OmniStudio Integration Procedures?

   Answer: Best practices include:

   • Keep Data Minimal: Use Filter Output and trim unwanted JSON blocks to reduce the payload footprint over the network.
   • Cache Intelligently: Utilize Session Cache or Org Cache settings within the IP configuration for relatively static data to drastically boost performance.
   • Server-side Heavy Lifting: Move complex data transformations out of OmniScripts and into IPs because IPs execute entirely server-side.
   • Use Declarative Elements: Avoid resorting to Apex Remote Actions unless a task cannot be handled natively via DataRaptors or HTTP Actions.
   • Proper Error Handling: Always use Try-Catch blocks and clear Response Actions to handle exceptions gracefully.

8. How to call an IP asynchronously?

   Answer: When invoking an Integration Procedure from another component (like an OmniScript, an Action Block, or Apex), you can check the Use Future or Run In Background properties. In an OmniScript, checking Run In Background on the IP Action element fires it asynchronously without locking up the user interface.

9. What is the difference between a synchronous and asynchronous IP, and what is the impact when calling from an OmniScript?

   Answer:

   • Synchronous IP: Executes on the same thread. The OmniScript blocks the UI with a loading spinner and waits for the IP response before moving forward. This is required if the subsequent UI step relies heavily on the data being returned.
   • Asynchronous IP: Runs in its own background thread (via Future methods or Queueable jobs). The OmniScript fires the request and immediately continues to the next step without waiting.
     Impact: Greatly improves user experience for long-running processes (like document generation or external ERP updates) because it prevents browser timeout limitations and helps bypass the standard 10-second Apex transaction limit, though it does not immediately return data to the screen.

10. What is a FlexCard?

    Answer: A FlexCard is a declarative UI component in OmniStudio used to display contextual information and provide quick tracking or actions for a specific record at a glance. They are built with a low-code drag-and-drop designer, are highly responsive, can source data from multiple streams (IPs, DataRaptors, Apex, HTTP REST), and can fire events or launch OmniScripts based on user interaction.

11. In DataRaptor, how will you associate an Account with a Contact while inserting using a DataRaptor Load?

    Answer: In a DataRaptor Load:

    1. Under the Objects tab, add both Account and Contact objects.
    2. Under the Fields tab, map your Account input data first to create the Account record.
    3. To link the Contact to this specific Account, create a mapping for the Contact's AccountId field.
    4. Set its value using the Domain Object Field Link feature referencing the Account created in the first step (e.g., mapping Account:id straight into Contact:AccountId). OmniStudio automatically guarantees that the newly generated parent ID is resolved and injected dynamically during runtime processing.

12. How will you check for a null field in a DataRaptor?

    Answer: You can check for null or empty values under the Formulas tab of the DataRaptor:

    • Use the native functions ISBLANK(var) or ISNULL(var).
    • For example, you can write a formula like: IF(ISBLANK(Contact:LastName), "DefaultLastName", Contact:LastName) and map the formula result to your target field under the mapping section.

13. How many objects can be kept in a DataRaptor? Is there any limit?

    Answer: While there isn't a hard declarative blocking limit built into the tool, best practices dictate that you should restrict a single DataRaptor to 3 to 5 related objects. Squeezing too many objects into a single DataRaptor impacts execution performance and pushes your transaction closer to standard Salesforce governor limitations (such as SOQL query limits or heap size boundaries). For highly complex schemas, it is better to break them up or sequence them inside an Integration Procedure.

14. How to call an Integration Procedure from an LWC?

    Answer: You can import and call the OmniStudio SDK integration runner engine directly within your LWC JavaScript file:

    import { OmniscriptBaseMixin } from 'omnistudio/omniscriptBaseMixin';
    // or import { OmnistudioAdapter } from 'omnistudio/omnistudioAdapter';
    
    // Call using the standard integration runtime method inside your class:
    this.omniscriptInterfaceProcedureRunner(inputMap, ipName, options)
        .then(response => { console.log(response); })
        .catch(error => { console.error(error); });