Welcome to the Vlocity Interview Questions course! If you're aspiring to excel in interviews for roles related to EPC (Enterprise Product Catalog), CPQ (Configure, Price, Quote), XOM (Order Management), or Omnistudio, you're in the right place. This course is designed to equip you with the knowledge and insights necessary to ace interviews in the Vlocity ecosystem, covering a wide array of topics, scenarios, and real-world challenges. Whether you're a seasoned professional looking to refine your skills or a newcomer seeking to break into this exciting field, this course will provide you with the essential tools and expertise to confidently tackle Vlocity related interview questions.
About Me: I am experienced Salesforce/Vlocity developer/solution architect. I hold following certifications and accreditations :
Salesforce Certified Associate
Salesforce Certified Administrator
Salesforce Certified Platform App Builder
Salesforce Certified Platform Developer I
Salesforce Certified Platform Developer II
Salesforce Certified Sales Cloud Consultant
Salesforce Certified Service Cloud Consultant
Salesforce Certified Sharing and Visibility Architect
Salesforce Certified Industries CPQ Developer
Salesforce Certified OmniStudio Developer
Vlocity Certified Professional Communications Developer 2 (Expired)
Vlocity Communications Order Management Developer 1 (Expired)
Salesforce Communication Cloud Accredited Professional
SAMPLE QUESTIONS COVERED IN COURSE ON EPC/CPQ:
1) What is Vlocity CPQ? What are its benefits?
Vlocity CPQ provides extensions to native Salesforce capabilities to support Opportunity, Order, and Quote processing. It is used to validate and capture new orders and it also supports asset-based ordering i.e you can create MACD orders based on customer existing product and services.
The order-capture capabilities of Industries CPQ let you to meet the business challenges by controlling the selling process using the Cart and an asset-based ordering system. Order capture team and sales teams can perform a variety of business tasks through guided selling to capture the perfect customer order by showing only available and eligible products for customer purchase.
CPQ provide below benefits:
• Produce accurate quotes
• Accelerate order capture
• Reduce order fallout
• Improve sales processes
• Expedite time-to-market
• product-complexity challenge
2) How we can restrict certain products from being getting assetized?
You can use the Field Mapper to create a filter that keeps not-assetizable products from being assetized. Field Mapper filter specifies assetization only when the Not Assetizable option is un-selected. As part of the managed package, Salesforce Industries includes a Not Assetizable field on products. However, the same field is absent from Order Products, Because of this, you need to create the Not Assetizable field manually on Order Products if required. In this case, you add the Not Assetizable field to Order Product. Then you use the Field Mapper to ensure that products that are marked as "Not Assetizable" are not created as assets during the order-capture process.
3) Is it possible to assign more than one base price to a product?
You can assign more than one base price to a product by creating price list entries stored in different price lists.
You can create price lists based on the needs of your business. For example, you may wish to separate pricing for one region from another region.
4) How to change the price of a product or child product in a bundle without altering its base price?
You can change the price of any product or child product in a bundle without altering its base price using below options:
• Adjust the price (% or amount of base price)
• Override the price
When you create an adjustment or an override to the base price of a product, you are creating a price list entry that is stored in the same price list as the base price.
You can also manually change a price in the Cart by:
• Adjusting it with a percentage or amount
• Overriding the price
5) What are two rules frameworks provided by salesforce industries?
Salesforce Industries provides two rules frameworks to accomplish your business objectives:
a) Context Rules
b) Advanced Rules
Context Rules qualify products, promotions, price lists, price list entries and pricing adjustments in the Cart.
Advanced Rules is Salesforce Industries is used primarily to create rules for product compatibility or configuration.
The EPC products pass through the Context Rules framework to filter the product list, then through the Advanced Rules framework to further refine the product list, and finally presents available and eligible products and promotions in the Cart.
SAMPLE QUESTIONS COVERED IN COURSE ON XOM:
1) What is decomposition relationships?
Industries Order Management uses decomposition relationships to define these rules that are needed to decompose the commercial order into sub-orders, called fulfillment requests, tailored for specific downstream systems.
Information from fields, attribute from commercial order is copied to attribute on fulfilment requests.
In short, Order decomposition breaks down the original commercial order into technical orders that are custom-designed for fulfillment systems according to use case requirements. The Order Decomposition process does not modify the original order. Instead, the process generates a set of Fulfillment Requests (FR), each containing Fulfillment Request Lines (FRL).
We can interpret FRL is a wrapper for the technical product specification defined in the catalog in a similar manner in which the Order Item is a wrapper for the commercial product specification.
FRL action is identified during the decomposition process based on analysis of the current technical inventory in a similar manner in which the Order Item actions are derived from assets.
2) What are different types of decomposition relationships?
Basically there are three types of decomposition relationships.
a) One-to-One Decomposition:
A common use case for a one-to-one order decomposition involves an offer containing multiple products of the same type that must be activated individually.
b) One-to-Many Decomposition Relationship:
A common use case for a one-to-many order decomposition is an offer containing a product that affects multiple fulfillment systems i.e that needs to be provisioned to multiple systems.
For example: A product which needs to be activated in network and has an OTC or MRC charge that needs to be sent to billing system.
So in the above use case we will need to create two technical products one of which will hold information needed by networking system and the other will hold the OTC or MRC charge for billing system.
c) Many-to-One Decomposition Relationship:
A common use case is a fulfillment system that requires information defined on a different commercial order items in single request. So in this case we will need to decompose multiple commercial products into single technical product.
This type of decomposition is generally achieved by using scope on technical product as “Account” or “Order Item".
For example, let say one of the commercial product hold Data/SMS/MIN value and the other hold the information say SIM details.
In the above use case we will create two decomposition relationship one from first commercial product which will map DATA/SMS/MIN to technical product attributes and other from second commercial product which will map SIM details to technical product attribute and then the information can be send to downstream system from technical product in a single request.
d) Multi-Level Decomposition Relationships:
Lastly, we can also create multi-level decomposition relationships. They are comprised of 1:1, 1:M, and/or M:1 relationships.
The need of multi-level decomposition arise when single level decomposition relationship is not sufficient to decompose commercial product into desired technical product.
As a best practice, a maximum of four levels is recommended.
Multi-Level Decomposition Relationships
3) What is product class and when to use it?
By default, when we create a new product using the Product Console, the Record Type is set to Product however “Product Class” is an abbreviated way to refer to a product with the Record Type as Class.
Product Class is neither a commercial product nor a technical product, simply it's a mechanism used by Industries Order Management to categorize certain products in order to simplify the order decomposition configuration process.
The need of product class arise when there are multiple commercial product and decomposition behavior is same for all i.e all decompose similarly to technical product.
Let say we have 100 commercial product in that case will need to create 100 decomposition relationship to decompose the commercial product to technical product. Isn’t this process time consuming?
Implementing decomposition by Product Class includes three main steps:
1) Create the Product Class.
Create a product and set the record type to Class.
2) Associate similar commercial products with the Product Class.
This is done by setting the commercial product's Parent Class field to a product created in step 1 with a record type of Class.
3) Create a single decomposition relationship from product class to technical product.
4) What is the need of setting product scope on technical product?
Order Management generates Fulfillment Request Lines (FRL) from order items as a result of the decomposition process.
Sometimes there is a need to create one fulfillment request line (FRL) from particular order item which we call as 1:1 decomposition
or Sometimes there is a need to create multiple fulfillment request lines (FRL) from one order item which we call 1:M decomposition
or Sometimes there is a need to create one fulfillment request line (FRL) for multiple order items which we call as M:1 decomposition.
The above behavior is controlled by using scope field on product2 object.
The Scope field appears for all products, whether they are commercial or technical. However, Order Management considers Scope only for technical products because they are used in decomposition results.
5) What is Staged Assetization?
Staged Assetization is a important concept for long running orders that can take hours, days, weeks or months to complete. Using this concept we can assetize top-level order items and their children even when other top-level order items in the same order are still in process.
As an example, a customer has ordered Mobile SIM CARD for mobile phone and WIFI connection. The order for Mobile SIM CARD finishes quickly, but for WIFI connection, the service provider needs to schedule a technician to go to the customer’s home for installation, which could take a week. In that time the customer decides to buy additional SMS pack for Mobile SIM CARD, as the Mobile SIM CARD has been assetized, the service provider can add the additional SMS pack without waiting for the WIFI connection order to finish.
SAMPLE QUESTIONS COVERED IN COURSE ON OMNISTUDIO:
1) What is DataRaptor? What are the different types of DataRaptor? What are the capabilities of DataRaptor?
DataRaptor is a declarative tool that enables you to read, transform, and write Salesforce data. DataRaptors typically supply data to OmniScripts, Integration Procedures, and FlexCards and write updates from OmniScripts, Integration Procedures, and Cards to Salesforce.
There are four different types of DataRaptor:
1. DataRaptor Turbo Extract
2. DataRaptor Extract
3. DataRaptor Load
4. DataRaptor Transform
Below are some of the code capabilities of DataRaptors in Salesforce:
1. Although Apex classes can read, write, and transform data, DataRaptors are recommended as a best practice because they take less time to create and are easier to maintain.
2. It acts as an ETL tool as it enables reading, writing, and transforming JSON and XML inputs.
3. DataRaptor can access external objects and custom metadata as well as sObjects.
2) When should I use a single extract step and when should I use multiple extract steps? What is the sequence in which data is queried under DataRaptor Extract?
How many extraction steps you need depends on how the object types you are extracting from are related. There are three basic scenarios:
1. Extracting data from a single object type, for example, order. This scenario will require only one extraction step.
2. Extracting data from a primary object and one or more parent objects also requires only one extraction step. An example is extracting order items with some order data for each order item.
3. Extracting data from a primary object and one or more child objects requires at least two extraction steps, one for each object type. An example is extracting an order and all the order items associated with that order will require two extraction steps.
The objects are queried in the order that you specify them in the extract steps, which is important for the third scenario, when you need to use data from a previously read object to filter a subsequent object.
3) List some of important actions that we can perform using Omniscript?
Below are different actions that we can perform using Omniscript.
1) DataRaptor Extract Action extracts data from one or more Salesforce objects.
2) DataRaptor Post Action posts data to Salesforce.
3) DataRaptor Transform Action transforms data.
4) DataRaptor Turbo Action extracts data from one Salesforce object.
5) Invoke an Integration Procedure to retrieve Salesforce data and external data.
6) Navigate Action to navigate to objects, records, Aura components, LWC components, etc.
7) HTTP Action to call internal and external web services from OmniScript without coding or making Salesforce API calls.
8) Remote Action to call the apex class.
9) Delete Action to delete one or more sObject records by using the Delete Action.
10) Email Action to either send an email template to the email address of a User, Lead, or Contact or to send an email body defined in the action configuration to any email address using Salesforce Email API.
4) What are the tools developers use to manage and move OmniStudio component changes between environments?
IDX Workbench is commonly used tool to deploy OmniStudio component changes between environments, the other tool is IDX build tool.
a) IDX Workbench:
IDX Workbench is a desktop application that developers use to migrate OmniStudio DataPacks and Salesforce metadata from one environment to another, such as from one org to another or from an org to a Git repository. When you choose a component for migration, IDX Workbench ensures that its dependent components are included. For example, if you migrate an OmniScript that requires a DataRaptor, that DataRaptor is packaged for migration with the OmniScript. In IDX Workbench, you define the source org or repository, the target org or repository, and the components to be migrated. You must create this definition before you can perform a migration. Migration is one way, from source to target. Source components overwrite target components of the same name and type.
b) IDX Build Tool:
IDX Build Tool is a command-line tool that does everything IDX Workbench does but without a UI. Developers using automation in environments like Jenkins may prefer command-line tools as they’re more configurable then UI-based applications.