Catalog and Catalog Item on different Workflows

[matthewwhite]

Greetings!

I have an issue with the Service Catalog. Let me provide you with some information regarding my instance as it may allow for better troubleshooting.

I am running domain sep, but my catalog and catalog items are living in global. I have broken down the catalog by categories, which each category representing the available Service Requests for that domain (with the intent of being restricted by user criteria).

I have created workflows which are domain specific, and assigned them to their respective catalog item. The workflows are on the sc_req_item table when creating the workflow.

From this point, everything is working properly. The Request is created by the user, the workflow fires off and progresses as intended. The issue is when the SCTasks and RITM are closed, the REQ is not closing as it should by the OOB business rule. I began looking into this, and saw that the REQ itself was on a different workflow, which I did not assign. This workflow is one that I created for a different request type, which is also in the same domain, so that began to raise the question of why the REQ was assigned a different, unrelated, workflow. In the below screenshot the request was created using the 'New Service Request' workflow. I progressed through the RITM and SCTasks, closed them, and this is the state of the REQ by clicking the 'show workflow' link on the Request itself.

I double checked the Catalog Item to make sure it is assigned the correct 'New Service Request' workflow, which it is. The above screenshot shows that the REQ is using the incorrect 'Upgrade Service' workflow in case it has hard to read.

So the issue is, why is the REQ inheriting a different workflow? I don't think there is a way to assign a workflow to a REQ, as it should be driven by the RITM and closed via the Business Rule. Any tips would be greatly appreciated!

Thanks.

[DilipKumar DJ]

Hi Matt,

I guess this is to do more with domain. The domain of REQ might be different from that of RITM, due to which the OOB Business rule which closes REQ is unable to do so. You can try sync of domain in business rule before the actual sync logic in business rule.

[matthewwhite]

Thanks Dilip! I ran through this some more and my notes are below:

I found the Business Rule, but it is operating at global so any domain sep shouldn't hinder it. I did as you suggested and copied the business rule to the domain level, and the REQ still isn't closing. I added a few gs.info blocks of code into the business rule script to see if the values are being passed and if the script is running, and they are.

The issue here isn't with the business rule not running correctly, I think the issue is why my REQ is loading an unrelated workflow, and being stuck on it. One thing I found intriguing was the stage of my REQ was set to a stage that is not on the REQ stage table, that incorrect stage is labeled review request (value = ilight_review_request). That stage is defined on the workflow, and if you check the screenshots above, the REQ is sitting at that review request stage of the incorrect workflow it is loading.

From my understanding, the workflow is assigned via the catalog item. There is no way to assign an REQ in itself its own workflow. Am I understanding that relationship correctly?

I have another request called 'Upgrade Service' which I ran through to see what the associated REQ workflow it was loading. In the below screenshot you can see it is running 2 workflows (the 2 RITM 3 workflows are parallel workflows that are initiated from the 'New Service' and 'Upgrade Service' workflows). Another oddity.

[DilipKumar DJ]

Hi Matt,

REQ will not pick the workflow based on catalog item's workflow. By Default RITM will have the workflow which is mapped to Catalog item. Currently whatever workflow is getting picked is due to the conditions getting met with the created request. You can try one thing by going the workflow properties of the workflow being picked currently by REQ and changing the conditions such that your request will not meet that for picking the workflow.

[matthewwhite · Accepted solution]

I figured this out after some more trial and error.

There has to be a workflow, at the domain level, that is assigned to the sc_request table (you set this when creating a new workflow, or in the current workflow properties). I was running into the issue where I had both workflows running on the sc_req_item table, as they should be, but the workflow was never initializing because the REQ was never kicking off with a workflow (which also has to have an approval before the RITM workflow starts).

What made me venture down this road is because when I changed the table of my workflows to sc_request the workflow was kicking off at the RITM level, but the REQ workflow was the same as the RITM and was sticking at the beginning stage. When looking at the REQ workflow it was running both workflows that were assigned to sc_request, but since the tables/fields/stages on the workflow were built for the RITM it was never progressing.

Creating a generic workflow in the domain, assigning it to the sc_request table, and moving my other workflows back to the sc_req_item table fixed the issue.