Can anyone explain how a request could appropriately use request type "XYZ MBS Request" but incorretly use workflow “Bug Request Type Workflow”? Creating a new "XYZ MBS Request" request forces, via an "Assign Workflow" rule, workflow "XYZ MBS Request".
I do not know if the five recently created requests were all created by copying a request or if any were created new. Based on the following information it doesn't seem possible.
The "MBS" request and workflow were created in 2011.
The “Bug” request type was disabled February 13, 2006. (If it were enabled the question could be easily answered.)
Workflow “Bug Request Type Workflow” is still enabled.
Only one request type rule assigns workflow "XYZ MBS Request" when created
No rule exists which assigns the “Bug Request Type Workflow”.
The only requests using workflow “Bug Request Type Workflow” are the five MBS requests.
Request type "XYZ MBS Request" has an "assign workflow" rule specifically assigning workflow "XYZ MBS Request" when created.
Request type "XYZ MBS Request" can only be created by an "XYZ-MBS End User"
Workflow "XYZ MBS Request" is restricted to using request type "XYZ MBS Request"
You have to check if the rule setting the workflow is still enabled.
You also have to check if your "XYZ MBS Request" workflow is still enabled. If not, than the first enabled workflow will be linked to the request as default. And mostly the "Bug Request Type Workflow" will be the first workflow found.
We see this happen occasionally. All of your requests are created via either Create Request pages or with ksc_copy_request. We were seeing this problem once or twice a week with 7.5 before our upgrade. We have seen it once in the last month with 9.12 (50,000 requests were created in that month). We are running 9.12 with a hot fix for a problem with setting the workflow with a Simple Defaults rule.
We saw the simple defaults rules fail consistently when we evaluated 9.12. HP provided a fix to make simple defaults work correctly. It was generating faulty sql that had spurious dependencies on unrelated fields. I don't think this fix was included in SP3 but should be in SP4.
Configuring the workfow with a simple default is needed for the Verify button in the Workflow section of the Workbench to crosscheck status usage between the workflow steps and the request types that use the workflow. When there are a lot of statuses involved, this can save a lot of tedious cross checking.
That request and workflow should have a 1:1 relationship. Of the 21,588 requests created five referenced the same incorrect workflow. That workflow has been around for about six years and has never been used.
That workflow has the lowest non-negative WORKFLOW_ID of all enabled workflows which is probably why it was selected.
The workflow that we have seen used incorrectly is the Bug Request Type Workflow, the one that comes with the product as the default workflow. We have disabled it and we still see requests occasionally start up with it.
We added a notification on the first step of this workflow that goes to the application support team whenever the workflow is used. If appropriate, we then open the request and change the workflow to the correct one. Fortunately, this is currently a very rare event.