Resolved timer

[LawesD]

Good Mornin'

I'm having trouble finding a way of automatically resolving a job in the BPM, and then having it automatically reopen after a period specified in the PCF. (They could be up to a year in dormancy so we wanted them out of the way).

The current workaround is to have it on hold for this time as this is the only node that lets you dynamically link a time mentioned in another field with the little sigma icon.  Everything else is just set to specify days, weeks, months etc. Is this achievable?

Open to other ideas,  as also tried to have it on hold but with no team assigned so it sat in the void, only to be awakened and assigned. But couldn't assign to no team. 

Thanks in advance.  

[Steven Boardman]

Hi @LawesD would it be possible to give a little more detail on what type of requests these are?  what is the significance to having these on hold / resolved for up to a year or a date set in the progressive capture? 

One concern with having these resolved -is that the customer of these requests, via the portal has an option to Accept the resolution which would in turn close the request.

If you could let us know what you are looking to achieve with these request, hopefully we might be able to help if we can understand the full picture?

Steve

[LawesD]

That's a good point Steve, did not think of that. Maybe on hold is the best status then. 

It's for the application of admin rights, for people going off-site for lengthy periods of time or those who require them for their work.

We wanted to limit this for a maximum of a year and then reopen them automatically for review depending on what they choose when completing the form. There may be quite a few people with this running long term so we were looking for a way to hide them out of the on hold queue. 

 

[Steven Boardman]

Ok here's a couple of suggestions or things to try

1. When placing on-hold (as you can set the period based on the progressive capture date), you can use a custom Sub Status to reflect that this is a request of this type on hold for the above given reasons - so it is at least obvious using the sub-status column in the request list.

2. Custom views can be created and shared which can mirror the default-on hold one, but these can have the above requests filtered out using the clause builder and filtering out those in a given sub-status 

3. To alleviate the issue with the no team, could you consider adding a supporting team to the service these requests are raised against,  this team then may have a single member, and this member can then be set to disable assignment.  

This would mean you could assign those requests going on-hold for a long time to this Holding team, which means your agents who belong to the other ream support teams would not see these requests when looking at the default On-Hold option,?

* with the only exception being if they have their view set to All My Services - but again using the sub-status above should mean it will be more obvious in the list which these are.

Because the member of this holding has the assignment disabled it will mean the other agents will not be able to manually assign requests to this user, as they won't appear in the assignment drop down options, although the new team will.

4. if the agents are using their personal views, then they can exclude these requests using the clause builder and a request attribute (such as sub status) so again they don't appear in the on-hold queue

I accept the above may not be a full solution from a visibility perspective but i wanted to offer some possible suggestions to consider. 

Steve

 

[LawesD]

Thanks for the suggestions, Steve.