Omniscript(OS)

Find-Components-with-Salesforce-OmniStudio-Explorer

Find Components with Salesforce OmniStudio Explorer

Salesforce OmniStudio Explorer is a critical tool for developers and administrators working with OmniStudio components like OmniScripts, FlexCards, DataRaptors, and Integration Procedures. As Salesforce orgs grow, tracking and managing hundreds of components can become challenging. OmniStudio Explorer solves this problem by providing a centralized interface to locate, analyze, and manage components efficiently. Using OmniStudio Explorer ensures that developers and admins can maintain a clear overview of their org, avoid duplication, and minimize errors when modifying components. For large-scale implementations or projects with multiple developers, this tool becomes indispensable for keeping workflows organized and efficient. Why Use OmniStudio Explorer? OmniStudio Explorer offers several advantages for managing Salesforce components: Quick Component Search: Search across OmniScripts, FlexCards, DataRaptors, and Integration Procedures by name, type, or API name. Find components instantly without manually navigating multiple folders. Analyze Dependencies: View which components are linked to others. Identify dependencies between OmniScripts, DataRaptors, and FlexCards to avoid breaking workflows. Simplify Debugging: Quickly locate the source of errors by tracing components and their connections. Reduces time spent searching for the origin of issues in complex orgs. Maintain Organized Architecture: Track active, inactive, or archived components. Ensure consistent naming conventions and structured organization across the org. Step-by-Step Guide to Find Components Step 1: Access OmniStudio Explorer Log into your Salesforce org with the required permissions. Navigate to OmniStudio Explorer via the App Launcher or Lightning tab. Step 2: Search for a Component Use the search bar to enter the component name, API name, or type. Filter results by component type (OmniScript, FlexCard, DataRaptor, etc.) to narrow down the search. Step 3: Inspect Component Details Click on a component to view details such as configuration, inputs, outputs, and associated dependencies. Check linked components to understand relationships and impact before making changes. Step 4: Verify Dependencies Ensure that changes to a component do not break other connected components. Document any dependencies or modifications for team visibility. Step 5: Maintain Logs and Documentation Keep a record of components accessed and changes made. Use internal documentation to track updates, especially in large projects with multiple developers What It Does This extension supports the development of Salesforce OmniStudio applications by allowing you to easily locate: Cards (AngularJS) FlexCards OmniScripts (AngularJS & LWC) Custom Lightning Web Components How to Use Add the OmniStudio Explorer browser extension. Open any Salesforce or Experience Cloud page. Click the “Find Components!” button in the extension. It will automatically detect all OmniStudio components on the page. Hover over a listed component to highlight it on screen. Benefits Quickly identify OmniStudio components on any page Save time during debugging and development Understand page structure without backend access Best Practices Use Clear Naming Conventions: Ensure component names are descriptive and consistent to simplify search and identification. Regular Cleanup: Periodically review and deactivate unused components to keep the org clean and reduce clutter. Document Dependencies: Track which OmniScripts or FlexCards depend on a particular DataRaptor or Integration Procedure. Version Control: Maintain backups of critical components before making changes. Consider using sandbox environments for testing modifications. Collaboration: Share component updates and changes with the team to ensure alignment and prevent accidental overwrites. Conclusion OmniStudio Explorer is an indispensable tool for managing Salesforce components efficiently. By providing search, dependency analysis, and organization features, it ensures that developers and admins can maintain a high-performing, error-free org. Implementing best practices like naming conventions, dependency documentation, and regular cleanups further enhances productivity and reduces the risk of errors.

Find Components with Salesforce OmniStudio Explorer Read More »

Debugging OmniScripts and FlexCards on site Using Salesforce OmniStudio Network Logger

Debugging OmniScripts and FlexCards on site Using Salesforce OmniStudio Network Logger

Salesforce OmniStudio provides powerful tools like OmniScripts and FlexCards to automate processes, guide users, and present data in a user-friendly manner. However, as these components grow in complexity, debugging becomes essential to ensure smooth operation. The OmniStudio Network Logger is a key tool that allows administrators and developers to monitor real-time requests, responses, and errors, helping them quickly identify and resolve issues. Using the Network Logger reduces downtime, improves accuracy, and enhances the end-user experience. This is particularly critical in large Salesforce orgs where multiple OmniScripts, FlexCards, and DataRaptors interact with one another. What is the OmniStudio Network Logger? The OmniStudio Network Logger is a browser-based debugging tool that tracks and inspects every network call made by OmniScripts and FlexCards.It lets you see exactly what’s happening behind the scenes — including requests, responses, errors, execution times, and payloads — all in one place. Add this extension- Think of it as Chrome DevTools, but built specifically for OmniStudio developers. Why Use Network Logger? Step-by-Step Guide to Debugging with Network Logger Step 1: Enable the Network Logger Step 2: Access the Component to Debug Step 3: Capture Logs Step 4: Analyze the Logs Step 5: Correct Issues Step 6: Document and Share Best Practices for Using Network Logger Common Issues and Troubleshooting ⚙️ How to Debug an OmniScript or FlexCard Let’s say you have an OmniScript form on your site that creates an Account record using a DataRaptor Load.When you click Save, the DataRaptor executes and creates the record in Salesforce. As soon as you act on your OmniScript — such as clicking Next or invoking a DataRaptor — the Network Logger starts capturing all the related network calls. To access it: 2. Go to the OmniStudio → Network Logger tab. From there, you can monitor everything happening in real time — which actions are triggered on each click or page load, what data is being passed in the request, and what response is coming back from Salesforce. Why It’s Useful Using the Network Logger, you can easily: Practical Example / Use Case Imagine a customer onboarding OmniScript that integrates with multiple DataRaptors and FlexCards to fetch account, contact, and subscription details. Without Network Logger, identifying the root cause would have required hours of trial and error. Conclusion Salesforce OmniStudio Network Logger is an essential tool for debugging OmniScripts and FlexCards. By capturing real-time network activity, it allows administrators and developers to pinpoint issues quickly, ensuring smooth operation and improving the user experience. Following best practices such as testing in a sandbox, filtering logs, and documenting changes will maximize efficiency and reduce errors in complex Salesforce environments.

Debugging OmniScripts and FlexCards on site Using Salesforce OmniStudio Network Logger Read More »

How to count record in omniscript.

OmniScript is a powerful tool used to create guided, dynamic user experiences by integrating data from various Salesforce sources. Often, data fetched through OmniScript comes from DataRaptors, which can return one or multiple records depending on the query. In many real-time scenarios, it becomes important to count how many records are returned and display or use that count within the OmniScript flow. In this article, we will learn how to count records in OmniScript data coming from a DataRaptor using a Formula element. This approach is useful when you need to validate data presence, control screen visibility, or simply display the total number of records to the user. Understanding the Use Case Consider a scenario where an OmniScript fetches account records using a DataRaptor Extract. Based on the result, you may want to: Display how many records were returned Handle situations where no records are found Drive conditional logic in the OmniScript flow Improve user awareness by showing record counts on screen To achieve this, OmniScript provides a Formula element, which can be used to apply functions like COUNT() on the incoming data. Example Overview In this example, we will: Create an OmniScript Use a DataRaptor Extract as a data source Count the number of records returned Display the record count using a Text Block This method works for any object, as long as the data is returned in a node from the DataRaptor.   Step 1: Create an OmniScript and Add a DataRaptor. Start by creating a new OmniScript based on your business requirement. Once the OmniScript is created: Drag a DataRaptor Extract element onto the OmniScript canvas. Configure the DataRaptor to fetch the required records (for example, Account records). Map all the fields that you want to retrieve from Salesforce. Ensure that the DataRaptor is correctly configured and returns data successfully. Next, add the following elements to the OmniScript: A Formula element (to count records) A Text Block element (to display the result) Once added, select the DataRaptor element on the OmniScript page and map the fields properly as required. Step 2: Identify the Data Node Returned by DataRaptor After configuring the DataRaptor, preview the OmniScript to inspect the data structure. To identify the node where records are coming from: Use a Text Block Pass the node name inside double percentage signs (%%) Example: %%Account%% This will render the data on the screen and help you understand the exact node name returned by the DataRaptor. This step is critical because the COUNT function depends on the correct node reference. Step 3: Add a Formula to Count Records Once you know the node name (for example, Account), you can create a Formula to count the records. Add a Formula element and write the following formula: IF(COUNT(%Account%) <= 0, “0”, COUNT(%Account%))   Explanation of the Formula: COUNT(%Account%) calculates the number of records returned in the Account node The IF condition checks whether the count is zero or less If no records are returned, it explicitly displays 0 Otherwise, it displays the actual count This approach ensures that the OmniScript handles both scenarios—when records exist and when no records are returned. Step 4: Preview the OmniScript and Verify the Output After configuring the formula: Preview the OmniScript Run the DataRaptor Observe the count displayed in the Text Block If the DataRaptor returns records, the formula displays the correct count. If the DataRaptor returns zero records, the formula safely displays 0 instead of blank or undefined values. This ensures a clean and user-friendly experience. Why Use a Formula to Count Records? Using a Formula element to count records in OmniScript offers several benefits: Avoids custom Apex logic Improves performance and simplicity Enables dynamic UI behavior Helps in decision-making and validations Works seamlessly with DataRaptor Extract results This method is especially useful in guided flows where data availability affects navigation or screen visibility. Conclusion Counting records in OmniScript using a DataRaptor and Formula element is a simple yet powerful technique. By identifying the correct data node and applying the COUNT() function, you can dynamically determine how many records are returned and use that information throughout the OmniScript. This approach helps improve data handling, enhances user experience, and ensures your OmniScript behaves intelligently based on real-time data. Whether you are displaying information or driving logic, record counting is an essential skill when working with OmniScript and DataRaptors.

How to count record in omniscript. Read More »

How to Call Apex Class In FlexCard

FlexCards are a powerful UI component used to display data dynamically in Salesforce OmniStudio. While FlexCards work efficiently with declarative data sources like DataRaptors and Integration Procedures, there are scenarios where custom business logic is required. In such cases, calling an Apex class from a FlexCard becomes essential. This article explains how to call an Apex class in a FlexCard, when it is needed, and how the data flows from Apex to the FlexCard UI. Why Call an Apex Class from a FlexCard? Although OmniStudio provides strong declarative tools, Apex is required in situations such as: Complex business logic that cannot be handled declaratively Data processing across multiple objects Advanced validations or calculations External integrations that require custom handling Performance optimization for large datasets Calling an Apex class allows FlexCards to display processed, real-time data while keeping the UI responsive. High-Level Architecture The typical flow looks like this: FlexCard calls an Integration Procedure Integration Procedure invokes an Apex class Apex processes the logic and returns data Integration Procedure passes the response back FlexCard renders the data on the UI FlexCards cannot call Apex directly, so Integration Procedures act as the bridge. Step 1: Create an Apex Class Start by creating an Apex class that contains the required logic. The class must: Be declared as global Have a @AuraEnabled method Return data in a format supported by OmniStudio (Map or List) Sample Apex Class global class AccountDataService {          @AuraEnabled     global static List<Account> getAccounts() {         return [             SELECT Id, Name, Industry             FROM Account             LIMIT 5         ];     } }   This example fetches basic Account data that will be displayed in the FlexCard. Step 2: Create an Integration Procedure Next, create an Integration Procedure to call the Apex class. Navigate to Integration Procedures Create a new Integration Procedure Add a Remote Action element Select Apex as the action type Enter the Apex class name and method name Example Configuration: Type: Apex Class Name: AccountDataService Method Name: getAccounts This step enables OmniStudio to execute the Apex logic. Step 3: Configure the Response Mapping Once the Apex method executes, it returns data to the Integration Procedure. Ensure the response is correctly mapped Use the Response Node to capture returned data Validate the response using Preview mode This ensures that the data structure is accessible to the FlexCard. On Preview Tab Step 4: Create or Update the FlexCard Now create or update a FlexCard to consume the Integration Procedure. Open the FlexCard designer Set the Data Source Type to Integration Procedure Select the Integration Procedure created earlier Map the response fields to the FlexCard elements At this stage, the FlexCard is connected to Apex indirectly via the Integration Procedure. Step 5: Display Data on the FlexCard Add UI elements such as: Text fields Data tables Icons or conditional styling Bind these elements to the response nodes returned by the Integration Procedure. For example: {{Account.Name}} {{Account.Industry}}   This displays the data retrieved from the Apex class. Step 6: Preview and Test Preview the FlexCard to verify: Apex class is executed successfully Integration Procedure returns data correctly FlexCard displays the expected output No runtime errors occur Testing ensures smooth data flow from Apex to UI. Best Practices for Calling Apex in FlexCards To ensure performance and maintainability, follow these best practices: Keep Apex logic lightweight and efficient Avoid unnecessary SOQL queries Always handle exceptions in Apex Return only required fields Use Integration Procedures for orchestration Test with large datasets to avoid performance issues These practices help maintain scalable and reliable FlexCard implementations. Common Use Cases Calling Apex from FlexCards is commonly used for: Aggregated or calculated data Conditional record processing External API data handling Custom eligibility checks Complex data transformations This approach extends FlexCard capabilities without compromising flexibility. Conclusion Calling an Apex class in a FlexCard is a powerful technique that enables advanced data handling in OmniStudio applications. While FlexCards do not directly invoke Apex, using an Integration Procedure as a bridge ensures a clean and scalable architecture. By combining declarative tools with Apex logic, developers can build dynamic, high-performing FlexCards that meet complex business requirements while maintaining a responsive user experience.

How to Call Apex Class In FlexCard Read More »

How to delete record in OmniScript through Integration Procedures

OmniScript is widely used to build guided, interactive user experiences in Salesforce. While OmniScript handles user interaction effectively, actions such as deleting records are executed using Integration Procedures. This approach ensures secure, controlled, and reusable logic for data manipulation. In this article, we will learn how to delete a record in OmniScript using Integration Procedures, step by step, with a practical example. Why Use Integration Procedures for Deleting Records? Integration Procedures provide a structured way to perform backend operations from OmniScript. Using them to delete records offers several advantages: Centralized business logic Better security and control Reusability across multiple OmniScripts Clear separation between UI and data operations Improved error handling OmniScript does not directly delete records; instead, it triggers Integration Procedures that perform the delete action. Use Case Overview In this example, we will: Create an Integration Procedure Use a Delete Action to remove a record Pass the record ID from OmniScript Trigger the delete operation from the OmniScript UI Step 1: Create an Integration Procedure Start by creating a new Integration Procedure. Open Integration Procedures Create a new Integration Procedure Drag a Delete Action element onto the canvas Configure the Delete Action In the Delete SObject configuration: Type: Enter the object API name (for example, Account) Path to Id: Provide the path where the record ID will be received This ID will be passed from OmniScript during runtime. Delete Action an Integration Procedures  Note:– We use Response Action for send data an omniscript.   – Drag a response action for send data in response an omniscript. Activate the Integration Procedures. Response Actin in Integration Procedures Step 2: Add a Response Action To send a response back to OmniScript, add a Response Action. Drag a Response Action element onto the canvas Configure it to return success or status information Important Note The Response Action is required so OmniScript can: Confirm whether the delete action was successful Handle UI behavior after deletion After completing the configuration: Activate the Integration Procedure Integration Procedures An OmniScript On preview tab.  – In Context Id – we pass AccountId for send id  an Integration Procedures for delete               account record. Click on Button. On Preview Tab Step 3: Create an OmniScript Now create a new OmniScript. Open OmniScript Designer Create a new OmniScript Drag an Integration Procedure Action element onto the canvas Select the Integration Procedure created earlier. Step 4: Pass Record ID from OmniScript To delete a specific record, OmniScript must send the record ID to the Integration Procedure. In the Integration Procedure Action element Navigate to Remote Properties In Extra Payload, pass the record ID This ID is used by the Integration Procedure to identify which record to delete. Step 5: Test the OmniScript Preview the OmniScript and test the functionality. In the Context ID, pass the AccountId (or relevant record ID) Click the action button to trigger the Integration Procedure Once executed: The Integration Procedure receives the ID The Delete Action deletes the record The Response Action sends confirmation back to OmniScript Best Practices for Deleting Records via OmniScript Always confirm user intent before deleting records Use Response Action for success or error messages Validate record ID before passing it Avoid hardcoding IDs Implement proper access control Test thoroughly in a sandbox environment These practices help prevent accidental data loss and ensure secure operations. Common Use Cases Deleting records via OmniScript is commonly used in: Guided record cleanup flows Customer self-service portals Admin or support workflows Conditional record deletion scenarios Data maintenance processes Conclusion Deleting records in OmniScript through Integration Procedures is a clean and efficient approach that separates UI logic from backend operations. By using a Delete Action within an Integration Procedure and triggering it from OmniScript, you ensure better control, security, and reusability. This method is especially useful when building guided user flows that require controlled data deletion while maintaining a smooth user experience.

How to delete record in OmniScript through Integration Procedures Read More »

How to know Difference between Use Of DataRaptor And Integration Procedures In Omniscript.

Here we see difference between use Of dataraptor And integration procedures in omniscript. Data Raptor in omniscript :-  When working with Salesforce OmniStudio, especially while building OmniScripts, two components are used most frequently for backend operations: DataRaptors and Integration Procedures (IPs). Although both are used to fetch, transform, and send data, their purpose and usage are quite different. In this article, we will clearly understand when to use DataRaptor and when to use Integration Procedures in OmniScript, along with real use-case explanations. Understanding DataRaptor in OmniScript DataRaptor is primarily used for simple data operations such as extracting, inserting, updating, or transforming Salesforce records. It directly interacts with Salesforce objects and is lightweight in nature. DataRaptor Extract Action in OmniScript The DataRaptor Extract Action is used when we want to fetch data from Salesforce objects and display it in OmniScript. Key Characteristics: In Input Parameters, the data source comes directly from OmniScript. Multiple input nodes can be sent from OmniScript to DataRaptor. You can send all Step Data or selected fields. In Response Transformation, the Response JSON Path is used to map extracted data back to OmniScript. Use Case: When you want to retrieve account, contact, or custom object data without any complex business logic, DataRaptor Extract is the best choice. In OmniScript DataRaptor Post Action in OmniScript The DataRaptor Post Action is used to insert or update records in Salesforce. Key Points: You can send specific fields or entire step data. Ideal for simple create or update operations. No complex conditional logic is supported. Example: Submitting a form in OmniScript to create or update an Account or Case record. In DataRaptorPostAction DataRaptor Transform Action The DataRaptor Transform Action is mainly used for data mapping and transformation. Highlights: You can send either all step data or a single field using the Send JSON Path. Useful when the output format needs to be modified before saving or displaying. Example: Transforming user input into a structure required by another OmniScript step. DataRaptorTransformAction DataRaptor Turbo Action DataRaptor Turbo is an optimized version of DataRaptor that works faster but with some limitations. Important Characteristics: Only specific data can be passed in Input Parameters. Works only with single Salesforce objects. Does not support complex mappings or formulas. When to Use: When performance is critical and the data structure is simple. DataRaptorTurboAction DataRaptorTurboAction Response Understanding Integration Procedures in OmniScript Integration Procedures (IPs) are used for complex data orchestration. They are more powerful than DataRaptors and support advanced logic, multiple data sources, and external system integrations. Integration Procedure Action in OmniScript In OmniScript, Integration Procedures are invoked using the Integration Procedure Action. Key Features: In Remote Properties > Extra Payload, only specific data is passed to the Integration Procedure. In Send/Response Transformation, you can send all Step Data or only required fields. Integration Procedures use a Response Action to send data back to OmniScript or FlexCard. Example: Fetching data from Salesforce, applying conditional logic, calling an external API, and returning a combined response. IntegrationProcedureAction Why Integration Procedures Are More Powerful Integration Procedures support: Multiple DataRaptors inside one flow Conditional logic Looping mechanisms External REST API calls Response aggregation Because of these capabilities, Integration Procedures are preferred when business logic becomes complex. When to Use DataRaptor in OmniScript Use DataRaptor when: You need quick data access Logic is minimal Only Salesforce objects are involved Performance is a priority Simple CRUD operations are required When to Use Integration Procedures in OmniScript Use Integration Procedures when: You need to combine data from multiple sources Business logic is complex External systems are involved Data transformation is extensive Error handling and orchestration are required Conclusion Both DataRaptor and Integration Procedures are essential building blocks of OmniScript, but they serve different purposes. DataRaptors are lightweight and perfect for straightforward operations, while Integration Procedures provide flexibility and power for complex integrations. Choosing the right tool not only improves performance but also keeps your OmniScript scalable and easy to maintain. Understanding this difference is critical for building efficient OmniStudio solutions.

How to know Difference between Use Of DataRaptor And Integration Procedures In Omniscript. Read More »

How To Enable Flex Card in OmniStudio(Vlocity) Salesforce

“We will explain in this blog how to enable Flex Cards. Step1: Open OmniStudio in App Manager Step2: As you unfold the Flex Card, a thoughtful message emerges, gently reminding you that the creation of this card awaits resolution of the associated warning. To fix this warning, go to the warning tab and find two links. Click on each link, and it will take you to Remote Site Settings. Before that, go to setup. You need to set up the remote site before making a flex card; otherwise, there might be an error when creating the flex card. I hope you understand how to Enable Flex Card in Salesforce.

How To Enable Flex Card in OmniStudio(Vlocity) Salesforce Read More »

How To Use Messaging Input In OmniScript

Create an Omniscript. Messaging elements can be used to display success, warnings, comments, or requirements based on the validation expression. /*! elementor – v3.18.0 – 20-12-2023 */ .elementor-widget-image{text-align:center}.elementor-widget-image a{display:inline-block}.elementor-widget-image a img[src$=”.svg”]{width:48px}.elementor-widget-image img{vertical-align:middle;display:inline-block} Create A Omniscripts First I am Drag & Drop Text Field in Canvas and Messaging Function. Expression=If Name<> NULL than Show the message “Thanks” . And expression == NULL So display Show “Please Fill The Tab”. Messaging Add to Omniscript Same thing on message display Whichever Condition is given in validate expressions. When the validate  expression is true then it follow true expression and if it is false then it follow false. This validate expression is displayed only when the active checkbox is checked. Note- If requirement is selected in validate expression then navigation is not possible without validating. Lets Preview it See the JSON See The JSON Expression Is True & False To display the message, select the type of message to be displayed when the validation expression returns true or false and add the message to be displayed. I hope you understand the use of messaging function.

How To Use Messaging Input In OmniScript Read More »

Scroll to Top