recently enaabled the app.experimental.multipleRequestsAction

[Rohit Govind]

Hi,

 

We recently applied new update to Service Manager and decided to use the app.experimental.multipleRequestsAction but I'm not sure its working properly. Just wondering if anyone else has used it and has got the same issue or I've just not set it up correctly or 2 is the limit that you can simultaneously can select?

This is the behaviour I get is as follows:

First of all I'm only able to select 1or 2 incidents/requests only for the actions/assign request option to appear

 

If I select more than 2, the option disappears as you can see below.

 

Thanks,

Rohit.

 

[Guest Chaz]

The requests need to of the same time and need to be associated to the same Service. This is so that we can be sure that the assignments do not go a person or team that cannot then work on the request. Hope that makes sense?

[nasimg]

Hi @Chaz

While I appreciate some customers may want this, I would say more customers would want this restriction removed.

This is a real issue for us as we manage multiple organisations with the same resources, so I need more flexibility in this area.

If you want to restrict this with toggle on/off or a special role please look into this again. Great we can do things with multiple tickets - but when I need to use it I don't want the restrictions (Service or Type).

Regards

Nasim

[Steve Giller]

@nasimg As Chaz mentions they logically have to be the same Service, otherwise you're going to "lose" Requests - the simplest scenario to illustrate that is that you select 6 Requests, assign to an Owner, that Owner can only see one of the 4 different Services, all the calls not of that Service are now orphaned.

[Rohit Govind]

Hi @Chaz

Sorry, but I don't understand your response, can you clarify please?

Thanks,

Rohit,

 

 

[Rohit Govind]

All I'm trying to do is be able to close multiple resolved ticket in one go.

Thanks,

Rohit

[nasimg]

@Rohit Govind in your request list make sure you can see the Service and Type column. When selecting multiple tickets they have be the same (eg. IT Support and Incident).

Thanks @DeadMeatGF but you don't know which services the owner can see (so you could lose them all)  - as I mentioned previously I'm happy for this to be a toggle on/off or a special role but I need to be able to ignore Services and Types.

I my situation I need more flexibility as I have the same analysts supporting multiple organisation.

Regards

Nasim

[Guest Chaz]

@Rohit Govind the best thing to do here would be to create a View that returned Requests just for a specific Service, or order by Service, and then the multi-select should work as you want it to. The restriction is there purely to prevent the loss of Requests if you were to assign them to the wrong team. Maybe an example around resolution is more relevant here as that's what you're trying to do: If you have different resolution categories in use for each Service, if we didn't have any restrictions in place, you'd be free to get around the correct selection by doing it here.

This is the first thing we've done here for a while so feedback is appreciated

[Martyn Houghton]

@Chaz

For some actions such as closing the restriction on Service does not need to apply, so it would be good if the selection then determined what you could do in terms of actions buttons enabled based on the selection.

We too would want to assign this as a application right to certain users via a role, rather than having it turned on for all service manager user.

Cheers

Martyn

[Martyn Houghton]

@Chaz

One thing we have also noted is that when attempted to page through and do a large selection using the shift key, the UI behaviour is not consistent. Sometimes it will do the multiple select, sometime it will just select the current record and other times it will not even select the one you are click on.

On the UI front as well, it would be good for the selection column on the left to remain in the pane when scrolling sideways through the columns, as this will make it easier to do your selections.

Cheers

Martyn

[Martyn Houghton]

@Chaz

Ok, sorted out why the selection is erratic, as I suspect you can only select a maximum of 50 records? Can this be increased by a setting?

It would be good to have a selection count on the request list so you know how many you current have. 

Cheers

Martyn

[Rohit Govind]

Hi All,

l thanks for the feedback, shame its not flexible in its configuration. 

Regards

Rohit.

[nasimg]

I've run a test of resolving multiple tickets and while they did resolve, the resolution email did not get sent out.

The Service Portal shows the tickets as resolved with my resolution text - but no email, is this expected behaviour?

Regards

Nasim

[Guest Chaz]

@nasimg the request itself will be resolved, but depending on your process there may be other factors deciding whether the process continues through to the end or gets paused waiting for other interaction.

[Guest Chaz]

@Martyn Houghton Not aware of any settings around this but I'll feed your comments back to the relevant team.

[Steven Boardman]

@nasimg

In regards to the question on the non sending of the resolution emails, as @Chaz highlights this is likely because this feature will not progress the Business Processes of the requests which you are on mass resolving.  There are many good reasons not to do this, but one primary reason, is because we can't know where they sit in their processes, what needs to happen next etc.  Is it a human tasks with multiple outcomes, is it suspend wait for category, priority etc again we can't guess any of this, as we don't know what has been build into branches which follow them. 

As you say requests will be marked as resolved when using this functions and any timers which are running will be stopped - in order to ensure your Service Level reports are correct.

There are a few options here.

1. If requests are in a 'suspend await resolution' state, then on the multi-select and resolving, the processes will continue and any resolution emails which are mean't to be sent after resolution will be sent and the processes will continue. 

2. Instead of using the 'multi-select' option on the request list, if you opt to use the Business  Process operation to do the same thing - by building this into your Major Incident, Problem or Change processes, then you can ensure a resolution email is sent to the customers of the child Incidents, or other requests by choosing this attribute when configuring the BP node.  So on resolving the parent ticket, the linked tickets will be resolved, timers stopped, owners notified and customers informed. 

3. A variant of the above, but if requests are in a 'suspend awaiting resolution' state when they are linked to a parent ticket, then on the resolution of the parent ticket, they would be marked as resolved, and if they have a resolution email option configured in their business processes, after they are resolved, then their business processes would take care of sending the resolution emails rather than from the parent. 

As this is new functionality is new, it will take a little adjusting to and possibly some re-jigging of business processes to fully utilise the,  but i hope you agree these are great features compared with having to do this manually on each ticket.

As @Chaz also said we are happy to take feedback and enhance this where we can.

Steve

 

 

[nasimg]

I'm happy to rejig our BPM if it will allow emails to be sent when we use the multi-select action - are you able to post an example of a working BPM?

Nasim

[Steven Boardman]

Hi @nasimg

In my examples in my Major Incident, Problem and Change Processes i have a number of actions which are performed once the ticket has been resolved - in the example below you will see i am doing the following:

* Get Resolution Info

* Resolve Linked Requests

* Remove from Change Board

* Update Change Management Workspace that the Change has been resolved

* Add to a Hot Topics Board (let the analysts know that a Change has been deployed -  in case we start to receive new Incidents as a result of the Change, which we can then link to this change)

* Automate the removal of the Change from the Hot Topics Board after either 72 hours elapsed time or when manual task to do so is complete.

In relation to the specific Resolve Linked Requests this is the configuration i have in place for this example:

So the following applies:

Request Type: I have left this blank, so any request linked to this change (which is not already resolved), will be resolved when this is invoked.  I could have chosen to limit this to a specific request type (Incident or Problem)

Status: The Linked Requests will be moved into Resolved (could be closed if you prefer)

Stop Timers: I have chosen to stop any timers which are running on the linked requests

Notify Owner: This is set to Yes, and the type of notification they will receive is controlled by this setting:  

Email Customer: Yes, this will send an email to the customer of the linked requests

Mailbox Name: The Mailbox from which the customer's email will be sent

Email Template: The email template to send to the customer's of the linked requests

Hopefully this explains how this can be invoked. 

There are considerations for the linked requests to:

The BPM of the linked requests

As mentioned earlier in the thread, we can't progress the BPM's of the linked requests through this operation as we simply don't know what stage, state etc the linked requests are in, what tasks, approvals etc are pending or what outcomes / directions to take.

As such we leave the BP of the Linked Request as is.

One approach you could consider is in your linked request processes, is the use of a task during your investigation stage - with outcomes of:

* Issue Resolved - analyst has fixed the issue and they resolve the Incident themselves with appropriate branches to send email resolution email etc

* Awaiting Fix - Choosing this option, you could follow this with a Suspend - Wait for Resolution option, once the linked request is resolved, this will cascade down the resolution to the linked request, and because it is in a Wait for Resolution state, this will be met, and the next action after that in the  linked BP will be invoked.

In this scenario three things can happen:

1. If the Analyst who is working on say the Incident, fixes the issue themselves - they resolve the issue and maybe you have your BP linked to this Incident, send the resolution email to the customer, and this BP controls the stopping of timers etc - and the BP completes as expected

2. The request (again assume Incident) has been marked as 'Awaiting Fix' from the task, and as such moves onto the suggested 'Awaiting Resolution' state - now if the Linked request is resolved, the resolution will be cascaded down to this request, adding the resolution, and it is the Linked request's BP which stops the timers and sends the resolution email to the customer - As the BP is waiting for resolution, when this is cascaded down, the Business Process of the (Incident) will move onto the next BP action in it's BP flow.

3. The request (again assume Incident) is in a state where the above task has not been completed, but has been linked to the Major Incident, Problem, or Change - when the Linked request is then resolved, the resolution will be cascaded down to this request, as well as stop it's timers and send the resolution email to it's customer but the BPM will not be progressed 

Apologises if this is a little long winded but i hope it helps clarify some of the behaviour and give you somethings to consider, albeit i expect you may other several different use cases or requirements but hopefully this gives food for thought

Steve