"Raise New" problems

[chrisnutt]

Hi,

I have noticed a significant issue in our instance and I am unsure if it is because of my configuration or not.

Basically, when the request is raised via the raise new button it follows a progressive capture that has to be generic because of all the different departments using the tool. Details are entered and then the request type is chosen, lets say incident. It launches a separate progressive capture for incident and the service is chosen.

For some of our services, we have many catalog items, that have a different progressive capture, are set to "Both" and should therefore follow the same set of questions as they do in the portal. This does not happen. Instead, the questions that are for the incident progressive capture we are now on are followed instead of jumping to the progressive capture associated with the catalog item.

For clarity, if no catalog item is chosen, just the service, the incident progressive capture should be followed. If a catalog item is chosen, it should use the progressive capture associated with that catalog item. Except it does not, it just stays on the incident progressive capture.

I realise the above may be hard to follow. I have made a video demonstrating the issue but can't upload it here. Happy to share if asked.

Thanks

Chris

 

[Martyn Houghton]

@chrisnutt

As I understand it the logic is that if you raise via the service and not a catlog option the default progressive capture is obtained from the Service Manager Settings based on the request type being raised.

• app.itsm.progressiveCapture.newIncident
• app.itsm.progressiveCapture.newKnownError
• app.itsm.progressiveCapture.newProblem
• app.itsm.progressiveCapture.newRelease
• app.itsm.progressiveCapture.newServiceRequest

Of if the request type is not set then it use the setting below.

• app.itsm.progressiveCapture.newRequest

I know when we used to allow logging of request at the Service Level, there was confusion sometimes depending on whether the analyst had pre-selected the request type.  Might be worth checking that these settings are what you are expecting to happen as a starting point.

This is why we went down the route of using the setting to enforce the selection of a catalog item and disabled logging at the Service Level.

Cheers

Martyn

 

[chrisnutt]

Thanks @Martyn Houghton

Each of those settings is as I want at the moment. They each launch the correct Progressive Capture. The trouble occurs when we launch, for example, app.itsm.progressiveCapture.newRequest which includes a node to choose a request type and then launch another progressive capture based on the request type chosen. The new progressive capture includes a node for "Select Service". When they, at that node, choose a catalog item with it's own progressive capture it is ignored and the node I'd expect if they just chosen the service itself comes next. It makes me wander if Hornbill struggles with multiple progressive capture jumps.

Does that make sense!?

Chris

[Martyn Houghton]

@chrisnutt

If they choose the request type from the drop down to log the request rather then in the progressive capture, i.e. raise new incident, does it then work as expected?

Like you say it could be that it does not like the two jumps, first on request type and then on catalog.

Do you have the 'Switch Capture' node in all of the default progressive captures?

Cheers

Martyn 

[chrisnutt]

@Martyn Houghton

Thanks for your help with this, btw!

The same thing happens when choosing an item from the "Raise New" drop down, on incidents. Not on Service Requests (which I just tried)... which, lends weight to my theory of not being able to handle multiple switches.

It does happen for Service Requests on the "Raise New" button (not the drop down), which also makes sense looking at my documentation if Hornbill can't handle multiple switches because when going via that route the progressive capture triggered has another switch which is not included when logging a Service Request via the drop down for the reason below.

The only "Switch Capture" nodes I have are in the "Raise New" button "app.itsm.progressiveCapture.newRequest" and in the incident and Service Request progressive captures. Attached is some of the documentation I keep on it which might help. Note, my Progressive Captures for directly logging an incident etc. (i.e. from the drop down) are slightly different because they include the Customer Search and Request Details nodes, and for Service Requests excludes a switch.

Any chance someone can confirm or deny the multiple capture switch issue?

Chris

[chrisnutt]

Just for completeness, here is the mapping of the progressive captures via the drop down options.

The reason they are different is because when this was set up, we encountered problems using the same progressive captures for both, and in order to keep what I felt at the time was a useful feature (the ability to choose a request type of recording details) we had to find a way to accommodate both methods and all users. A decision which I do now wish we hadn't made! But they we are... we are where we are...

[Miro]

hi @chrisnutt, 

Could you please share your video you mention in the first post in PM? Or send it to support@hornbill.com and put in the subject "For Miro" and in the body link to this thread.

Thank you,
Miro

 

[chrisnutt]

Thanks @Miro, I have sent you a link where you can download it.

Chris

[Miro]

Thanks @chrisnutt, I got your message.

Will investigate and when will have any news I will posted it here.

Thank you,
Miro

[Bob Dickinson]

Hi @chrisnutt

I've had a look at your video, and I think I can potentially see the issue (it took me a few watches!). 

From what I understand; if the Estates Service is selected, along with a Catalog Item - you would then like to Switch to the Progressive Capture related to the Catalog Item. You have a number of catalog items, some with their own captures (for example Lock and Key). 

However from what I can see - after the decision to establish whether the Estates Service has been made - you have specifed a specific capture that will ALWAYS been switched to next in this scenario - called Estates Incident. 
Estates Incident contains two forms - the Site and the Details. This means, that even if you select Lock and Key, it is always switching to Estates Incident....and never your Lock and Key specific one:

 

What I believe you need to do, is change this Switch Capture node to dynamically be switching to the Progressive Capture asociated to your Estates Catalog Item that was selected. To do this, change the Switch Capture node above, to be configured as per below:

 

Give that a try, and raise some requests against a few catalog items, including Lock and Key. Hopefully this will Switch as you expect. 

I may have misunderstood this - so if it fails for whatever reason, please switch it back to the current set up and let us know and we will take another look. 

Kind Regards

Bob

 

 

[chrisnutt]

Thanks @Bob Dickinson, I'll look into this. But my immediate question is what if they don't choose a catalog item? Just select "Estate Services" and then click next? That's why I have the generic "Estates Incident" progressive capture there.

Thanks

Chris

[Bob Dickinson]

Hi @chrisnutt

I'd suggest  best practice would be to enforce catalog item selection, as it genuinely makes the layout and structure of BPMs far easier to understand and maintain. However I do appreciate that is easier said than done if a configuration has been performed in a particular way already and you are live.

So in your example I'd have another decision node - after the Estates service decision, that is look to see if a Catalog Item has actually been selected or not. 
If yes - dynamically switch as per my example in the last post.

If no - switch to the defined progressive capture (as you have it set up right now)

 

That would cover all eventualities I believe.

Let me know how it goes and if this works for you

[chrisnutt]

Thanks @Bob Dickinson will have a look

[Bob Dickinson]

Hi @chrisnutt

Did you have any luck with fixing this?

Kind Regards

Bob

[chrisnutt]

2 minutes ago, Bob Dickinson said:

Hi @chrisnutt

Did you have any luck with fixing this?

Kind Regards

Bob

Hi Bob,

Yes. Put it on today, coincidentally. It works, but I have an issue still with the raise new button (as opposed to drop-down). That launches a select request type node - which we recently put in place to simplify things. However, because that directs to progressive captures depending on the choice (the same ones associated with the drop down request types) it still doesn't work there as that first switch takes precedence.

As I'm leaving my role, I've been undertaking a program of tidying up and simplification. To try and resolve this now will introduce more complexity and I have precious little time. Hence 

 

[chrisnutt]

@Bob Dickinson, I think I was over-thinking it. Have made the same change on the other progressive captures (For Service Requests and so on) and it works.

Many thanks for the solution to this!

Chris