enhancement Wait for Status Change - to trigger when SubStatus is changed

[Martyn Houghton]

Currently the 'Wait for Status Change' node only completes when the primary 'Status' changes i.e. from 'OnHold'  to 'Open'. It does not trigger is the SubStatus is changed within the same parent 'Status', i.e. changes from 'Open->Pending with AM' to 'Open->Pending with Analyst'.

Can the node be extended to have the option to trigger on a change to the SubStatus or can a new Suspend Node be for this. i.e. 'Wait for SubStatus Change'?

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Is this something that could be considered as note being able to suspend awaiting a sub-status change is going to cause some issues with us for new services coming on board.

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Can you advise is there are any plans to address the issue of suspending and awaiting a 'Sub Status' change, as not currently having the ability to suspend the workflow and await the change from one sub-status to another under the same parent status is quite an problem for us for the new services we are bringing online this quarter.

Trying to use suspend and await expiry to check to periodically if the sub status has changed is not efficient on the our instance resources and will quickly  hit the maximum number of steps. 

Cheers

Martyn

[HHH]

+1, we have several sub status within each Status, so the ability to do this would be nice.

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Is there an existing story or development item for this, as not being able to suspend and await a sub-status change means we have to add in manual/additional updates to the request to cause the BPM process to clear the suspend process.

Cheers

Martyn

[James Ainsworth]

Hi @Martyn Houghton

There is a change request that has been raised for this requirement.  The members in this topic discussion have all been added.  This requirement is not currently scheduled for development but we will continue to review and we will update this post once there is some progress.

Regards,

James

[Martyn Houghton]

@James Ainsworth

Thanks for the update. Hopefully this is something that can move forward, because once other customers make more use of Sub Status, they too will need the ability to suspend the workflow awaiting a change in between one sub status to another. 

I wish I could put the on hold when waiting on other internal departments, but from an SLA point of view they have to stay as open and we use the sub status to identify and report those requests waiting on the teams outside of the service desk.

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth

Is there any update on this change request/enhancement? 

Not being able to suspend the workflow to awaiting a Sub Status change is becoming very restrictive and affecting the ability to accurately track the SLA performance.

Cheers

Martyn

[James Ainsworth]

Hi Martyn,

This is still in the backlog.  We did have a technical review which uncovered a technical challenge that we would need to overcome in order to progress.  No time frame as of yet.

Regards,

James

[Martyn Houghton]

@James Ainsworth

Any update on this?

Not being able to suspend between sub statuses is becoming quite an issue in our workflows where we are trying to integrate with other back office teams.

Cheers

Martyn

[James Ainsworth]

This is still in our backlog.  No update at the moment.

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Not having the ability to suspend wait a change in sub status is becoming a significant barrier for us to implement Enterprise ITSM operations where request are being raised through Hornbill as the front end but then need integrations with other departments which is why the request does not change parent status (i.e. go on hold) as the request is will open with us to coordinate and progress the internal processes.

Can this please look at moving this forward, sooner rather than later.

Cheers

Martyn

[Aaron Carter]

Hello @James Ainsworth,

 

I'm raising my hand as another customer who would like this change. It's something the team has requested, I was surprised to find it is not already implemented. It would definitely provide a lot of great business process options!

[James Ainsworth]

Hi Aaron,

Thanks for your post.  I'll add your interest to the change.

Regards,

James

[Guest Paul Alexander]

+1 for us too....being able to move a bpm forward on the update of a substatus would help us....

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Any update on this long running requirement?

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Any update on this, as this is becoming an increasing barrier to being able to properly suspend complex workflows as they pass through multiple sub-statues?

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Any update?

Cheers

Martyn

[Martyn Houghton]

@Harry Hornbill

Any update on this please?

Cheers

Martyn

[Martyn Houghton]

@Harry Hornbill

Any update on this?

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth

Service Manager build 2853 included a change for the 'Wait for Substatus Change' suspend node to consider sub-status, but the parameters and help on the node do not appear to have been updated and on testing this without setting any parameters the suspend node does not pick up the change of the sub-status.

Can you please advise on the specific changes made by CH00157807 and how we configure the node to proceed with the workflow when the sub-status changes within the same parent status?

Cheers

Martyn

 

 

 

[samwoo]

+1 for a node that can be used just Sub-status changes (from and to)

[HHH]

+1 for us as well

[Martyn Houghton]

@Steve Giller @Nanette 

Are you able to assist in clarifying the information for CH00157807 or one it be best to log a support request?

Cheers

Martyn

[Martyn Houghton]

I now logged this as a Support Request - IN00179133

Cheers

Martyn