CR spawned from SR not picking-up Workflow, not reporting the RequestID and not accepting Change Type

[Berto2002]

Can anyone help with this mystery, please?

Because we can't log a CR from Routing Rule Templates, I intend to log a SR and have an SR Workflow create a CR and then close. It nearly works; I get the CR but we have 3 important issues. I want to rule out my oversight first, then ask if there is something specifically blocking SRs raising CRs; before moving on to suggesting a defect.

First issue is that the new CR is not picking-up the Workflow.

Create node is this:

The Service Catalog item under Change for Network & Infrastructure Support is:

And that Workflow is active:

The CR gets created but has no Workflow:

I first tried under ServiceDesk Basic User (a Subscriber to the Service) and got the error. I than tried as me (Full User) and full subscriber and still got the error so ruled-out the user being the issue:

Interesting Observations:

The "Raised By" is THIS:

which is this when clicked:

Second issue is that the node that is in workflow to update the timeline with the new requestID (as diagnostics) is reporting no value, despite the "outcome" variable reporting success (so the overall flowcode reference works to refer to the node that spawned the CR):

The node to update the timeline has this config and the red and green match the above (but for the last bit obvs):

And the node that creates the CR has the following outcomes which match the above:

The Third issue is that, despite the node to create the Change Request stating to set the CR type to "Standard" (see first screenshot), the spawned CR has no Change Type set:

Of course, I need workflow and I need a Change Type for this to work.

Any ideas please?

Thanks in advance.

[James Ainsworth]

Hi @Berto2002

You wouldn't happen to have another request catalog item with the exact same name of SYSTEM: Server Patching Standard Change on either a different request type on the same service or on any other service?

[Berto2002]

@James Ainsworth. Good question. I ran the report for this and no, we don't. The report is all services, cat items and subscribers so each cat item has multiple lines for each subscriber. In alphabetical order on cat item only the one in question shows.

Today, I had a thought that the nodes that do this work were pasted (via templates) from another flow and then adjusted (in case you noticed, this is why the Result Reference is "logRequestServiceRequestTest" (not, presumably "logRequestChangeRequestTest") but I assume the value in result ref is incidental as long as it is consistently referred to.

[Berto2002]

I recreated the nodes from within than workflow and still no workflow is picked-up so that rules-out in issue with the template copy.

[Paul Chambers]

@Berto2002  RE: CR spawned from SR not picking-up Workflow
I think a change has been introduced in a recent release which is preventing the workflow from being 'picked up' on the new linked request when the last action on the original request was completed by System Internal Context. If the last action was completed by a human, the workflow is being picked up.
Previously the workflow was being 'picked up' when the last action on the original request was completed by System Internal Context.

 

[Berto2002]

@Paul Chambers interesting. Are you also seeing this issue?

Do you have any idea as to whether that was an intentional 'change' or a consequential 'change'?

That does indeed match my circumstance because my SR is untouched by humans; it's purpose is to overcome the limitation that Routing Rule Templates can't open CRs so I need an intermediary to spin one up....

This is the timeline of my SR:

So I am now going to put a Human Task in there and see if it 'picks up'...

[Paul Chambers]

@Berto2002 I have raised this with HB Support as what I have found so far is that prior to this week, the new linked request was 'picking up' the workflow correctly for each new linked request, whereas since Monday the workflow is not being picked up on the new linked request when the last action/update on the original request was completed by System Internal Context. The workflow still works fine on the new linked request when the last action/update on the original request was completed by a human. 

[Berto2002]

I confirm that adding-in a Human Task just before the create step led to the spawned Request 'picking-up' the prescribed workflow. Thus, the issue appears as you have described @Paul Chambers. For us it is impeding a new development; for you an existing process. Good work, thanks for contributing. I have a workaround to add something to my Outlook calendar to attend to this Human Task once a month but not ideal...

[James Ainsworth]

Hi @Berto2002

I just wanted to let you know that this is currently being investigated.  I'll let you know once I have had some additional feedback from our development team.

[Berto2002]

Thanks, I understand several customers have reported this issue to Premier Support.

I also confirm that when we had the Human Task as the last update, the Change Type was populated OK and the new Request ID was correctly published to the Timeline so all 3 of my symptoms had the same cause.

[James Ainsworth]

@Berto2002

There is a potential fix being included in the next Service Manager update which is currently scheduled for next week. As you mentioned, there were a few other customers with similar issues.  Once the fix is available we hope to confirm with each customer that is has resolved their scenario.

 

 

 

 

[Berto2002]

@Paul Chambers should be fixed in release last night (

2.157.0 (2973)

)