Wait for Request Off Hold - Outcomes - context/who by

[Martyn Houghton]

At the moment the Business Process nodes all realte only to the request entity and it related objects, however there is no ability at the moment to determine the 'current context' i.e. who is undertaking the action or operaiton which is completing a step or tiggering the end of suspend operation.

In Support Works you had the field last updated by on the primary table which allowed you do ascertain some form of context, but there is no equivlany field in the Requet Entity.

The reason for wanting this is to be able to branch within a workflow depeding on 'who' completed the last action. For example within our workflow we have a Wait for Request Off Hold suspend node, which when it comes off hold immedialty creates a follow on human task agasint the request owner.

However there are a number of reasons why the request may come off hold, one of these could be that it is being chased by our 1st Tier as we have not had a response from the customer and need to put it back on hold. Inorder for them to send a chasing email to the customer they have take it off hold, which creates an activity for the request owner not the person taking it off hold. Similarly if it has come off hold automatically (i.e. like the old Support Works Off-Hold status) we may want to automate the chasign process in the workflow.

Therefore it would be good if the BPM nodes, in particular the Supped Nodes had Outcomes specified to determine 'what' the outcome was, i.e. Hold Time expired, Manually taken off Hold, and 'who' undertook the operation, i.e. 'System', analystid etc.

This way you could follow the suspend node with a decision branch to automate what happens if the request comes off hold after it expires or if it is taken off hold manually by someone other than the owner we could create a human activity for the analyst who took it off hold rather than for the owner.

In short have the BPM being aware of the 'context' of the update allows a much wider dimension for controlling and routing the workflow, compared to the current request entity only standpoint.

Is there any plans to add on this context type of information into the BPM?

Cheers

Martyn

[James Ainsworth]

Hi Martyn,

I'm not aware of any plans for something like this at the moment. I will look to the developers of the BPM for some feedback.  Not sure if you had seen this post but it too is also an interesting idea for the BPM.  

James

[Martyn Houghton]

James

Thanks, I think both the above and Samuel, post are along the same lines in that currently the BPM is very linear and does not take into account updates made to the request outside the workflow and also the context of actions being picked up in the workflow, with Samuel idea relating more the former rather the later.

I think have both have merit in making the BPM process more dynamic and reactive to real world processing of requests.

Cheers

Martyn