1 of 1 people found this helpful
How about you create a new string attribute on the Request object. Create a window just for this attribute and an action to go with it (and an associated view rule). Mark this window as default temporarily, then edit the process and add the new automatic action just prior to the On-hold status. Using a run-time value, populate the new attribute with the name of the current status.
After the on-hold status, you may be able to have a series of cascading decisions (one for each possible prior status), that check that value of the new attribute, which then branches off to the particular status that comes next.
Not sure if this makes sense or not...
Thanks for this - all was going really well till I try to use a runtime value, keep getting error Object reference not set to an instance of an object, any thoughts??
Sorry Helen, the only thing I can think of here is perhaps as soon as you leave the previous status (on your way to "On Hold"), that the Status value is actually becoming null, and therefore the run-time value is not working. I had hoped it may remain until it reached the new status. It looks like we may not be able to take this path after all.
There may not be an elegant solution after all...
Another solution (not quite as neat) may be to have separate automatic actions after each status to manually set the new attribute you created. Rather than using a run-time value, you could specify the value explicitly...?
I have the best solution that you'll be able to use. It does not require any calculations, but it will create a little bit of chaos on your process diagram if you're anything like me when it comes to having some semblance order on them.
In essence what you need to do is create a new collection that is only ever used by the process and never exposed to the users of the system. You can call this something like 'Status Record'. All it needs is a string attribute and the create date persistence type. Now add this as an automatic action after your 'On Hold' manual action. When the window is displayed you'll need to populate the string attribute with a value type which is Incident/Status/Title. We will use this value in the conditions that will be tested when you take the Incident off hold.
I have attached some screen shots to help.
Thanks, I thought I was maybe going crazy last night, think you must be right about the null value, never thought of that while pulling my hair out shouting at the PC lol.
I'll give this a blast and repost later on how excellently it works
And it will still look so much better than having 6 on hold mini processes hanging off each status!!
Andy - Works like a dream. Thanks
Paul - thanks as well for starting me on the right path, much appreciated
Thanks Andy for supplying this solution. It does work a treat. The only problem I do have is that this results in the ServiceDesk no longer being able to maintain the Split Workspace Actions Panel. All these Optional Actions can technically now result in a status change, so they appear above the line. Anybody got a workaround for that?