Salesforce Vlocity Interview Questions On Order Management Updated 2023

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 are primary functions we perform using industry order management?

1) Order decomposition  

2) Order Orchestration

5) What is order orchestration?

Once the order decomposition is completed the next step is the order orchestration.

Orchestration is basically a process of communicating with external systems to send the necessary information needed by the external system to process the order.

Example of external system include billing, network activation, inventory management.

6) Is it necessary to perform order decomposition?

The main purpose of the order decomposition is to accumulate the necessary information from fields/attributes from different commercial products into attributes on technical products and then send the necessary information to external system for provisioning.

order decomposition is optional and is explained using the example below.

Sometime the integration with external system is so complex that it is necessary to break the commercial information from different commercial products or single commercial product into different technical products or single technical product as per the need of external system. In order to achieve this type of integration in simpler way it is necessary to make use of decomposition process  to map the necessary information on technical product and then which can be used to communicate with external system however sometime the integration with external are simple and can be easily achieved based on the information available on commercial product and in this type of scenario we do not need decomposition.

7) Is it ok to map the action parameter from commercial product to technical product in decomposition?

we should avoid mapping the action parameter from commercial to technical product. This is explain using the below example.

Let say you have a commercial product "Bill Plan" which has DATA, MINS and SMS as an attribute. Let say you created a technical product called "Bill Plan TP" which has DATA_TP, MINS_TP as an attribute. 

Note : We are not mapping SMS attribute from commercial to technical product. Let say the downstream system for which technical product is created does not need SMS value.

Let say you map commercial product "Bill Plan" attribute DATA, MINS to technical product "Bill Plan TP" attribute DATA_TP, MINS_TP. In this case initially in base order our order item(Bill Plan) and fulfilment line item (Bill Plan TP) both will have add action and accordingly once order is assetized the asset and inventory would be created.

Now, let say we raised another MACD for bill plan change where we are modifying the attribute SMS on commercial product "Bill Plan".

So in the above case in cart we will be able to see the action Change on "Bill Plan" order item and action on fulfilment "Bill Plan TP" will be still NoChange this is because there is no change that has happened to commercial product "Bill Plan" attribute DATA, MINS which is mapped to "Bill Plan TP" attribute DATA_TP, MINS_TP however if we would have mapped the action parameter as well from order item to fulfilment line item it would have resulted in Modify action on fulfilment line item as well which can result in error if we have callout that need to be executed based on Modify action on fulfilment line item.

8) What are conditions and mapping rules while creating decomposition relationship?

A condition rule places a condition on the decomposition relationship. Order Management initiates decomposition of an order item only if the specified condition evaluates as true. Otherwise, Order Management skips the decomposition relationship.

Note: The conditional rule is optional.

Mapping Rules provide a way to pass the attributes from your commercial products to technical product attributes.

There are three different types of Mapping Rules.

a) Ad-verbatim : Here the value of the source attribute is copied as is to the destination attribute.

b) List : For a given list mapping, the source value is set to the corresponding destination value.

Example : Let say you have 2 values on commercial side on an attribute as Gold, Silver and let say you have 2 values on technical side on an attribute as 100 GB and 50 GB.

Using list mapping type we can map GOLD to 100 GB and Silver to 50 GB.

c) Static : Here we can specify any value on technical product attribute directly.

Note: The mapping rule is mandatory.

9) 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.

10) What are different scope available to set on technical product?

Scope has below picklist values:

a) Account

b) Order Item

c) Downstream Order Item

d) Top Order Item

e) Order

11) Explain what is Account scope?

If we set the Scope for a technical product to Account it creates a single instance of the technical product Fulfillment Request Line. Only one inventory item for the technical product exists for the given account. If there is another order requesting the same bundle, then the decomposition process generates a FRL based on the existing inventory item.

12) Explain what is Order scope?

If we set the Scope for a technical product to Order creates a single instance of the technical product (Fulfillment Request Line) per order. But, unlike the Account scope, for every subsequent order that requests the same bundle, one inventory item fulfillment request per technical product is created.

13) Explain what is Order Item scope?

As we have seen in the above examples if we set the scope to Account or Order then irrespective of the number of time the bundle is added in Order 1 decomposition always resulted in single technical product getting generated however if we want separate technical product to be created for each bundle as shown in image below then we can set the scope to Order Item. 

Let us understand this with an example,

I created a bundle with two child products as shown below. I also a technical product called "Technical Amazon Prime". Then I created decomposition relationship from "Amazon Prime" to "Technical Amazon Prime" and similarly I created one more decomposition relationship from "3G Data Plan" to "Technical Amazon Prime".

Now, I created an order and added bundle product twice as shown below. Have a look at decomposition shown on right side. The decomposition resulted in a separate technical product for each bundle.

14) Explain what is Downstream Order Item scope?

If we set the Scope for a technical product to Downstream Order Item then it results in no merge of a technical product i.e FRL is created for each commercial instance.

15) Explain what is orchestration plan definition?

A set of tasks grouped logically together in a plan, used to fulfill orders across one or more fulfillment systems.

16) Explain what is orchestration item definition?

Tasks that make up an orchestration plan definition is called as orchestration item definition.

There are 5 types: 

1. Milestone.
2. Auto-Task.
3. Callout.
4. Manual Task.
5. and Push Event.

17) Explain what is orchestration scenario?

Used to determine when an orchestration plan definition should execute. They are tied to a product and an action such as Add, Modify, Disconnect, NoChange, Suspend, Resume.

18) How to configure a callout to send empty attribute values?

In the Details section of the Orchestration Item Definition window for an existing callout, click the pencil icon to the right of Callout Parameters. Now, click Send Empty Values, then click the arrow to move "Send Empty Values" from the Available box to the Chosen box.

19) 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.

20) How to configure task in orchestration plan definition for Staged Assetization?

An orchestration item of type Auto Task with the AssetizeOrderItem implementation must be associated with the order item at the required stage of the orchestration plan to assetize the order item.

AssetizeOrderItem must be associated with a root order item, or with a technical order item that's decomposed from a root order item. Any association to a child order item is ignored, and assetization will not occur for any child order items.

Apex Class to be referred in implementation : XOMAutoTaskStagedAssetizer

21) How is orchestration item associated to fulfillment request lines and order items?

If an orchestration plan definition is associated with a technical product in scenario condition, its orchestration items are associated with a fulfillment request line. If an orchestration plan definition is associated with a commercial product in scenario condition, its orchestration items are associated with an order line item.

22) What are different queue types available?

There are three queue types: 

Attributes-Based, 

Round Robin

Least Loaded. 

We need to choose a queue type when defining manual queues and manual tasks.

Attributes-Based : It assigns tasks based on assignment rules that you set. 

Round Robin : It assigns the task to members of the work group in sequence. 

Least Loaded :  It assigns the task to the person with the fewest number of tasks in their queue. 

23) How to launch an omniscript from manual task?

To launch an omniscript from manual task we need to refer the URL obtained from omniscript in "Custom Task Execution URL".

To obtain the OmniScript launch URL:

1) Click the Vlocity OmniScripts Designer tab. 

2) In the Vlocity OmniScripts page, navigate to the desired OmniScript and, if applicable, expand it to view the latest version.

3) Click the name of the OmniScript to open it.

4) In the top-right corner, click the How to Launch the Activate Script button.

5) Select the OmniScript launch URL in the Standalone section and click the Copy to clipboard button. 

Sample URL : 

https://domainname--vlocity-cmt.vf.force.com/apex/vlocity_cmt__OmniScriptUniversalPage?id={0}&layout=lightning#/OmniScriptType/Contract/OmniScriptSubType/Amend/OmniScriptLang/English/ContextId/{0}/PrefillDataRaptorBundle//true

Remove the org ID and the domain name from the URL. Now, copy and paste this updated URL in  manual task item definition field "Custom Task Execution URL".

apex/vlocity_cmt__OmniScriptUniversalPage?layout=lightning#/OmniScriptType/Contract/OmniScriptSubType/Amend/OmniScriptLang/English/ContextId/{0}/PrefillDataRaptorBundle//true

24) Explain the concept of partial assetization of product attributes?

Partial assetization of attributes can only be used on technical products.

You can control which attributes are assetizable by checking the Not Assetizable field on technical product attributes. 

Order Management gives you the option of assetizing some product attributes and not others.

For example, you can create an order with Personally Identifiable Information (PII), such as customer name and customer phone number. This information is required on a one-time basis to create a billing account, and then is no longer needed. You can define the PII attribute on one of the technical products and flag the PII attributes as Not Assetizable. Avoid creating a mapping for this attribute. Instead populate the value during orchestration instead. Doing so ensures that there's no impact in decomposition from this attribute so Order Management doesn't store PII in internal technical inventory or anywhere else on a permanent basis.

25) What we can do to ensure callouts made to a fulfilment system that is unresponsive due to scheduled maintenance does not fail?

Offline Status:

If a fulfillment system is unresponsive, you can set the relevant system interface to Offline.

If we do so it moves those callouts to the On Hold state. 

Updating status to Online:

When the system goes back online, change the system interface back to Online. The callouts then move to the Ready state where they're picked up and orchestrated as usual.

Integration Retry job:

The Integration Retry job is responsible for changing the state of a callout after its system interface is back online. This job checks callouts in the On Hold state to see whether their associated system interface statuses are set to Online. If so, then the job moves the callout to the Ready state.This job runs every minute by default, but you can edit the custom settings to change that setting, and others. 

Before the Integration Retry job can run the first time, you "schedule" it. Scheduling the job just means clicking the Start button next to the Schedule Integration Retry Job option on the admin panel. 

Note: For Offline and Online status to work, your org must be running in PlatformEvents mode.

26) Explain cancellation of In-flight orders in vlocity order management?

Order that is in the process of fulfillment is referred to as an In-flight order.

You can cancel a submitted order if it has not passed the point of no return (PONR). A task in an executing orchestration plan reaches PONR when it advances to any of the following states: Completed, Running, Failed, Fatally Failed.

Once order is submitted and accepted by order management for order fulfillment. If you want to cancel the whole order or a few order line items within the order, you can send a cancellation request to the order management system if the order or order items have not passed PONR. 

Supplemental orders are automatically generated by CPQ after an order cancel request has been issued and validation is completed by order management. Supplemental orders are automatically decomposed as well.

Cancellation is at the order-level or order-item depending on what is selected on the order and PONR configurations.

Original Order Status:

The original order transitions from Cancel Requested to Superseded.

Supplemental Order Status:

If all goes well during cancellation process the state transitions from Cancel In Progress to Cancelled.

Initial state during order cancellation:

                                 Status(Salesforce)      Vlocity Order Status

Original Order                Draft                     Cancelled Requested

Supplemental Order        Draft                     Ready to Submit

If everything goes well:

                                    Status(Salesforce)   Vlocity Order Status   Fulfilment Status

Original Order               Draft                        Superseded                   Superseded 

Supplemental Order      Activated                 Cancelled                      Activated                 

 If there is some error in cancellation process:

                                      Status(Salesforce)   Vlocity Order Status

Original Order               Draft                        In Progress

Supplemental Order      Activated                 Rejected

27) Explain amendments of In-flight orders in  order management?

Using the amend feature, you can add, modify, or delete the cart line items or you can also modify, add, or cancel a promotion and discount that applies to a line item after the order is submitted. It helps you modify your order before order management completes its fulfillment.

You can amend a submitted order if it has not passed the point of no return (PONR).

A task in an executing orchestration plan reaches PONR when it advances to any of the following states: Completed, Running, Failed, Fatally Failed.

After you submit an amended order, The supplemental order status changes to In-Progress and the original order is superseded.

28) Explain the difference between Amendment plans and Rollback plans?

An amendment plan is an orchestration plan that is generated when an order item is amended. A rollback plan is the orchestration plan used for canceling orders or order items.

29) What are supplemental orders?

As soon as we clicks the Amend or Cancel button a supplemental order is created. This order looks like the original order, but can be amended by the operator. Once submitted, the supplemental order supersedes the original order.

30) What are frozen orders?

Order Management freezes the original order as soon as the Amend or Cancel button is clicked, except that running items are allowed to finish. If you'd prefer that running items become frozen as well, you can do so by marking the checkbox "Smart Freeeze" on item definition to true.

31) Explain the workflow for amending the order?

As soon as we clicks the Amend button on an order, the following things happen:

1) Order Management freezes the original order. By default, items that are running continue to run. If you'd prefer that running items become frozen as well, you can do so by marking the checkbox "Smart Freeeze" on item definition to true.

2) A supplemental order is created, and you can amends it as required, then submits it.

3) Order Management compares the supplemental order to the original order. If any proposed amended item has already reached PONR, then the amendment is rejected.

4) If the proposed amended items are accepted, then a new decomposition is created, with supplemental actions compensating for the original actions.

5) The orchestration plan is updated with necessary amendments.

6) The fulfillment status of the original order is marked Superseded.

32) What is the relation between original order orchestration plan and supplemental order orchestration plan?

Order Management associates the original orchestration plan with the supplemental order, updates the orchestration plan, and then follows the workflow in the rollback or amendment plans.

33) How the decomposition for supplemental order works?

As soon as we clicks the Amend button or Cancel order button on an order Vlocity creates a new supplemental order and decompose it.

Order management compares the new decomposition plan to that of the original order. A difference between the two decomposition plans indicates the need for a supplemental action. When there are changes, OM creates a supplemental action to supersede the original one.

For example, let's say that a customer orders a Mobile phone and order is decomposed and orchestration is in progress. Let say the customer cancels the order, in this case order management maintains the original "Add" action, but adds a supplemental "Cancel" action to supersede the original action.

    

34) Explain how the decomposition works during amendment?

Figure 1 shows the Mobile Phone product which has several attributes (Colour, Delievery, Back Cover and so on), two of which have conditions. The Memory Card product also has an attribute with a condition.

                                                            FIGURE 1

Figure 2 shows the original order. 

The customer has ordered Mobile Phone and Memory Card, but has not ordered the Back Cover. Let's assume the scope is set to Account on "Technical Product Mobile", thus two order items result in a single, combined fulfillment request.

                                                                   FIGURE 2

Now, we will raise an amend order to add Back Cover. This supplemental order will have the following effects:

1. A new downstream fulfillment request is added for Back Cover with vlocity action as Add.
2. The fulfillment request Technical Product Mobile gets a supplemental action of Amend because it's the parent of the new fulfillment request.
3. The Mobile Phone order item has changed, so gets a supplemental action of Amend.
4. The memory card order item is carried forward as is, so has supplemental action of No Change.

                                                                FIGURE 3