Which came first, the Request or the Requested Item?

[christopher_tho]

When ordering an Item through our default Service Catalog process, you will see 2 different types of records get created.

1. One "Request" record.
2. One or more "Requested Item" records (depending on how many Items you place in the order).

Now, as you may want to modify the process and what data gets put into these records, it may be helpful to know which of these records actually gets created and processed first. For example, let's say you wanted to take a value from a Requested Item record and copy it to the work notes of your Request record? When and how would you do this?

Most likely, the logical answer would be to create a Business Rule when the Requested Item is created or updated to do a GlideRecord query for the parent Request it is tied to and then just copy the information over. But, what if the Request record has not yet been created when this Requested Item is created or when your Business Rule is ran?

Since most of the code that actually does this Catalog Checkout process is in our backend code, there is not much we can really look at code-wise to see what all is occurring. However, if you are an admin on your instance, you can do some Server-Side debugging which can help get you a picture of what happens once you order an item.

Below I will go through a very general process of what occurs when ordering a Catalog Item based on our default setup. I will run through some of the steps involved, including some of the Business Rules that control this behavior as well the role that Workflows and Execution Plans play in as well.

First, once you click the "Order Now" or "Checkout" button for your order (depending on if you are using the one-step or two-step checkout), what you will see from the debugging is that the "Requested Item" records will start to get created first.

For example.

11:23:35.2: Execute before insert business rules on sc_req_item:RITM0010005 before engines (order <1000)

11:23:35.3: Global ==> 'Task Active State Management' on sc_req_item:RITM0010005

11:23:35.3: Global <== 'Task Active State Management' on sc_req_item:RITM0010005

As the RITM is being created, if this Item is using a Workflow (based on the Catalog Item record), we don't link a workflow to this Requested Item yet (I will explain on this later). If you are using an Execution Plan, you will see the Tasks for the Execution Plan get created, but they will all be in a "Pending" state at first.

Next, once the Requested Items are all created, then we being creating the Request record.

11:23:35.220: Execute before insert business rules on sc_request:REQ0010005 before engines (order <1000)

11:23:35.220: Global ==> 'Task Active State Management' on sc_request:REQ0010005

11:23:35.221: Global <== 'Task Active State Management' on sc_request:REQ0010005

During the process of creating this REQ record in the "Before" Business Rule phase, our Workflow engine will link a workflow (if existing) to this Request record and start running this workflow. This is different behavior than what occurs for the RITM records, but actually this behavior here is what you would expect for most tables when having a workflow linked to them (Incident, Change Request, etc.).

Below is an example of what a Request Workflow may look like.

Now, as the workflow runs for the REQ record, there may be some activity or activities in this workflow (ex. Wait for Condition, Approval, Task, etc.) that causes it to not get completed automatically and not mark the Request as "Approved." If not marked as approved, it will be left for the workflow to reach that activity and run any remaining Business Rules that would be left for this Request. This would pretty much be the end the Checkout process at that time until the Request gets approved.

However, in the case where you may have your workflow or a process setup where you just "auto-approve" this REQ record (like in the example above), then the following may occur.

If the "approval" field on the Request gets changed to "approved", then this will end up triggering a Business Rule by default called "Cascade Request Approval to Request Item."

11:23:36.154: Execute after insert business rules on sc_request:REQ0010005 after engines (order >=1000)

11:23:36.154: Global ==> 'Cascade Request Approval to Request Item' on sc_request:REQ0010005

11:23:36.176: Execute before update business rules on sc_req_item:RITM0010005 before engines (order <1000)

Now, depending on whether you are using a Workflow or Delivery/Execution Plan, the following will happen.

• Delivery Plan
  • You will call this "getNextStage" function also within this Business Rule that will essentially start the first "Task" that was setup for each of your RITM records.
• Workflow
  • This will mark each RITM record with these values below
    • approval = "requested";
    • stage = "request_approved";

If you are using a Delivery Plan, this is basically the end of this process, as the first task you have will get changed to an "Open" state, and then you would just proceed with working on those tasks as needed. However, if using a workflow, then once those values are set as mentioned above, another Business Rule will get called upon during the update of the RITM with those previously mentioned values called "Start Workflow".

11:23:26.241: Execute before update business rules on sc_req_item:RITM0010005 after engines (order >=1000)

.....

11:23:36.244: Global       ==> 'Start Workflow' on sc_req_item:RITM0010005

11:23:36.307: Execute before insert business rules on wf_context:Procurement Process Flow - Mobile before engines (order <1000)

In this Business Rule, we look up the "cat_item" value from the Requested Item record and find the workflow version linked to that Catalog Item, then we start a new workflow context from this version.

So, it is at this time that we then start to run the Requested Item's workflow to run the necessary activities.

Here is an example Requested Item Workflow and how it may look after ordering the item.

Based on this example, the RITM workflow was able to run to this "Wait for condition" activity, and this is where our Checkout process completes at this time.

Overall, the main takeaways from this article should be the following.

a) Requested Item records are created first before the parent Request record.

b) However, it is the Request record that needs to run its workflow or process to get approved before starting the Workflow or Delivery Plan of the respective RITM records.

c) If using workflows for your Requested Items, these workflows do not get associated to their records until after the parent Request record has been approved and the Business Rules that were mentioned have been ran.

I hope this information is helpful once you start customizing your Service Catalog process to know when to run certain Business Rules and how to configure your workflows accordingly.