Request stage displays as in progress even after closure

KB15 · ‎11-10-2015

Is it normal if the request stage displays "Closed Complete" -> "In progress" even though the request itself is complete? Should it visually display close complete as being completed? If not, what would correct it? The request approval workflow is mostly OOB. The modification was made to approve the request regardless of cost.

KB15 · ‎11-30-2015

From SN, they have suggested a couple of options from what I understood it from the back and forth.

Don't use this workflow. This is a legacy workflow and most implementors do not use this OOB because of some jankyness with how this workflow functions. Strange that our implementor didn't say or recommend we modify it.
Change the request workflow to workflow driven. It's set to "Legacy" OOB. Use a custom workflow with stages and define the conditions as needed or modify the OOB workflow.The OOB service request workflow does not contain any workflows so you would need to create stages as needed. This would mean that you may need to modify your notifications accordingly and only fire on request items.
It was suggested that you direct users to RITMs in ESS instead of the REQs however I'm not sure how this would work since I think it would confuse them with REQs and RITMs.

What I don't quite understand is why they keep this workflow in the instance to begin with if they don't recommend using this. It's a little strange that they would do this and keep it in a "not recommend" configuration. They never really addressed this questions the few times I asked.

View solution in original post

theoracle · ‎11-10-2015

Are these workflow stages? You ned to define them

Check these

Workflow Stages - ServiceNow Wiki

Setting the Stage with Stage Sets

KB15 · ‎11-10-2015

If they're not defined for the request workflow, are the stages coming from the request item?

KB15 · ‎11-20-2015

I opened a HI incident to have them take a look.

So far, this issue *might* be a bug in Fuji based on my testing. I tested this in a nightly demo instance and found this occurred there as well. I found this in both builds of our instances Patch 6 and Patch 7 Hotfix 5 the nightly demo build date is 11-19-2015_2230.

I've already replied back to see they can figure out what the issue is.

Interestingly enough they, initially told me that the OOB request workflow was setup wrong because it was using a legacy engine and there were no stages. Don't know how that's possible since this is a brand new instance.

KB15 · ‎11-30-2015

From SN, they have suggested a couple of options from what I understood it from the back and forth.

Don't use this workflow. This is a legacy workflow and most implementors do not use this OOB because of some jankyness with how this workflow functions. Strange that our implementor didn't say or recommend we modify it.
Change the request workflow to workflow driven. It's set to "Legacy" OOB. Use a custom workflow with stages and define the conditions as needed or modify the OOB workflow.The OOB service request workflow does not contain any workflows so you would need to create stages as needed. This would mean that you may need to modify your notifications accordingly and only fire on request items.
It was suggested that you direct users to RITMs in ESS instead of the REQs however I'm not sure how this would work since I think it would confuse them with REQs and RITMs.

What I don't quite understand is why they keep this workflow in the instance to begin with if they don't recommend using this. It's a little strange that they would do this and keep it in a "not recommend" configuration. They never really addressed this questions the few times I asked.