Catalog Requested Item workflow not waiting for end of Service Catalog Request

[Les1]

Mystery anyone?

i'm troubleshooting an issue with our service catalog, specifically an Order Guide.

My understanding:   Service Catalog Request workflow should End before the Service Catalog ITEM request workflow begins, is this accurate? Somehow I or other has made a change that is breaking this expectation. The ITEM workflow is getting triggered despite the Service Catalog Request workflow not being completed, just wondering some ideas for me for investigating. 

our Service Catalog Request workflow is not OOB.  And in it there is a Task creation happening that is meant to be waited on for completion prior to allowing the Service Catalog Request to continue.

Desired state: 

1. Service Catalog Request initiates approval
2. Upon Approval, initiate Task 1 and Wait.
3. Upon Task 1 completion, proceed to end of Service Catalog Request workflow
4. RITM workflows triggered for all rule base catalog items etc.

Current state: 

at step 3. above, the workflow gets to the Wait.

4. while in Wait condition for Service Catalog Request, the subsequent RITM workflows are or have already been triggered (not yet sure about timeline - its possible they triggered right after the Approval step. I know they do not trigger prior to the Approval step)

Thank you for ideas about where i should be looking that would break the requirement for RITM to wait on the Service Catalog Request to complete.

[Allen Andreas]

You said that you made changes to and then this started happening...

"Also, to clarify, this is happening in sub_prod while we were making updates to an onboarding Order Guide & related catalog items."

So...what were those changes? I'm going off what you're saying, so that's where my questions come from.

So you're saying that there's a business rule that is essentially triggered from the workflow by the onboarding status set value activity? So I assume in that activity (which I had asked about above) is setting that to "Pending provisioning". What does this business rule do?

As far as a wait timer, I would suggest to place a 1 second timer activity after the set value activity for the onboarding status, and another 1 second timer activity after the create task activity (so before the wait for condition). This way it gives the system time to catch up to itself. The reason for this because as I also mentioned above, having all those activities slammed together causes the workflow to possibly glitch. Think about it, if that activity is setting the value of that onboarding field to pending provisioning...what was the value before that? Most likely ...--None-- right? And so to run through that and do that update, you then have some BR running on this record and on this table once that value gets set to user provisioning...right? Then...you have a task activity with no wait for completion....then you have wait for condition field that is looking for a specific value or.... --None--...so during all that, technically the none was met and so if everything was still updating/running/processing...the workflow could move on even though the context didn't update to reflect that. You could test this to see by adding another run script after the wait for condition with a system log entry to see if it gets posted and then you'll see that technically it's passed it.

Side note: I'd recommend removing the none...because you aren't looking for none and none usually gets placed there if there was another 'or' condition and that value got removed one day. Once the value gets removed, it sets it back to none...so I think the none could be the issue too.

Anyways...I've provided a few things here, please review this/attempt them and see what happens.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Les1]

its a mess...

the Create AD task has a script within that sets another field called "u_catalog_type" = "user provisioning" 

the business rule has a condition that looks for catalog item.state != pending and within has an IF  u_catalog_type = "user provisioning" then set the onboard status = "User provisioned"

Apparently though the thought here by a developer helping me out,  is that all the RITM tasks are being triggered as soon as the manager approval happens (instead of via that Approval Action situated after the Wait condition). in our prod instance only the Create Ad task gets triggered, and then when it completes, the other tasks trigger but the mechanism that does this we've not found yet.

[Allen Andreas]

Yea, unfortunately, I'm gonna have to start to bow out on this, lol...because I've spent a good bit of time and at the end of the day...only you guys can see what the difference is and why it's doing 'x' in Prod and 'y' in sub-prod.

Something has been changed. Either the approval activity is different (different somehow) or one of the follow-on steps is different...the if activity, the set value activity (or the BR associated to it), the create task activity (and whatever script is with that). As mentioned before, it can seem like it's happening right after the approval activity because everything else is just rolling straight through, it's really just scripts and such running really quick.

I mentioned above that you could place a run script activity with a simply log statement in it down after the wait for condition and see if you see that log statement. The point of that is to show that even though your workflow context may say it's still on the wait for condition step...it's not. Which all indicates that your workflow is just glitching through most likely due to everything stacked together with no break.

I also mentioned adding a few timer activities just to see if that helped slow things down.

At this point, I can assist nor do I think really anyone else can on the community without more tests from you on those things.

We don't know what you all touched or did differently to this, honestly. So we can only speculate.

Take care!

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Les1 · Accepted solution]

So the issue that was discovered by HI was centered on Approval Engines.

System Properties/Approval engines  -- for some reason ours was not set to "Turn engines off - Workflows are managing approvals"  which is the default oob. mystery remains as to how/why this was changed but putting this back to default brought back our expected workflow/approval behavior.