We have the automation activated where tickets go back to in progress after there is an acitivity in the ticket.
Somehow tickets keep going back after we’ve send an e-mail and changed the status to waiting on customer. It looks like there is some delay in sending the mail and we’re to fast in changing the status. Now we have to change the status for each ticket twice, which doesn’t work for us. Also waiting a minute after sending an e-mail is not the best solution.
Is there any way to set a delay here or fix this another way?
Hi @KBrouwer,
Can you check the ticket status property history? View a record's property history
This will show you a timeline of what’s happening and whether you’re too fast for a workflow.
If you are, then unfortunately there’s nothing you can do but wait a moment. HubSpot workflows are fast but they’re not that fast and there aren’t any ways to speed them up, unfortunately.
Best regards
Thank you for the (very fast) resonse!
The e-mail is send at exactly the same time as we changed the status. It only shows minutes, not seconds. Is there any way to make Hubspot look at the seconds as well? I think that might solve the issue for us.
@KBrouwer could you please check the history of the ticket status property only (see KB article), not the history of all property changes?
This is the overview i’m getting when following the instructions.
@KBrouwer this is for all properties on a record, please follow the instructions from this section: View a record's property history
@KBrouwer correct – I’m not sure which change exactly was not what you wanted to happend. But, in the second row, you can a see a workflow kicking in after Kimberly made a change. If the workflow was supposed to update the stage before that manual update, that won’t be possible, as I said. Workflow can’t made to be run faster. You’ll have to either adjust the workflow to run in these scenarios or teach the team to wait a moment.
This is an example of a ticket that went back to CS Turn without any activity…
@KBrouwer this, again, looks like the manual update was simply too fast and the workflow ran later, slightly. See my previous reply: “You’ll have to either adjust the workflow to run in these scenarios or teach the team to wait a moment.”
And an exampe of the ticket jumping back at the same time as the e-mail being send.
So we have 2 kind of issues to give us double work.
It would be great if we can update the workflows. What changes do I have to make to do this.
@KBrouwer I can’t say from a distance, without accessing workflow action logs, knowing the exact process steps and seeing the workflow enrollment criteria and actions.
Generally, you want to implement a logic that stops the workflow from running when you “lock” a ticket, preventing any further workflow updates. This can bring its own set of problems, however.
Alternatively, configure the workflows so that they’re putting the tickets into the right status directly.
