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.