Suspend node not recognising customer update

[Will Darley]

We have a "customer chase" node in our workflow that sends an email to the customer 3 working days in a row, advising that we've tried to get hold of them.

When the Customer Chase sub-status is selected on the request, it sends an email to the customer and will then pause for 1 working day before sending the next chaser email. The Customer Chase sub-status is a sub-status of the overall On Hold status.

Whilst the request is on hold, the request waits for status change from on hold:

If this node expires it will send the next chase email and wait again until the next working day. If the request is resolved it goes down a different path and resolves the ticket. If the status changes to Open it loops back round to the start and waits until the ticket is put on hold or resolved again.

I've noticed a bug whereby, if the customer posts an update on the ticket, even though this takes the ticket off hold and changes the status to open, the workflow doesn't recognise this and remains on the suspend node shown in my screenshot above.

Strangely though, if the customer responds to the ticket via the chase email they receive from us, it works fine and loops back round to the start. It's only when they respond via the portal that the workflow doesn't seem to recognise that the status has changed to open.

The service looks to be configured correctly in terms of taking the ticket off hold when a customer responds:

Any help would be greatly appreciated!

[Berto2002]

I haven't got experience of this case but on observation, you are waiting for a status change but the customer is providing an update.

The status change is only as a result of an update. I wonder if this secondary act is the issue.

Firstly, alternatives:

1. Have you considered suspend for "request update"? Then when the customer updates it, it should move on
2. Part of this functionality is built-in to the Resolve feature.
   1. set the status to Resolved (with an update that we tried to get hold of you etc)
   2. have a Suspend Await Status Change with a 1 day expiry
   3. if expired, send email and go to another Suspend Await Status Change with a 1 day expiry
   4. if this third attempt fails to rouse the customer, this expiry sets status to Closed
   5. If any of the Suspend Await Status Change nodes are triggered by a customer Update, you can revert back to normal processing

Secondly, have a look at this. It's a call for an enhancement I made in this (which I would welcome your support on if you agree ) and in that Steve Giller seems to make a point that the secondary status change should still trigger; so maybe that helps you report this to support as a possible defect if it does not?