Workflow configuration for reopening tickets when an update occurs once a ticket has been resolved

[Adam Toms]

Hi all,

We have had the ability to reopen tickets, which works very well using the older workflows configuration screenshot attached.

This seems to be using flowcodes, and I believe for newer work flows the flow codes is not available.

Or if it is, I don't seem to be able to find it at all.

I've therefore tried to re-create this, but it doesn't seem to reopen the ticket or function as I expected, it doesn't error but it doesn't reopen in the same way as the flowcode setup.

Please see the newer workflow configuration screenshot attached, for what I've tried to configure to have a similar behaviour to the flow code configuration.

Does anyone have advice on where I'm going wrong or have a better idea, on how to achieve what I'm looking to do?

 

Many Thanks

 

[Steve Giller]

Firstly, I think the value should be "open" rather than "status.open"

Secondly, it's difficult to give any more detail without seeing how you get to the decision node, as that will affect what it's deciding.

[Adam Toms]

Thanks @Steve Giller

For your quick response on this. Apologies that I missed the earlier post in 2021, that you've included.

I've largely followed the same configuration as the flowcodes were set, when which we went live. But as this is for a different customer our HR team, as they require a lot less complex workflows than in IT. I created their workflows from scratch and then ran into this. In my head I couldn't see why this wouldn't work.

To help with this, I have included how the suspend node is configured, as well as a screenshot showing the outcomes.

I note I've used the same configuration in the status is closed. So this must be hitting the no match criteria rather following the two other routes I've created.

With this additional information, do you think if I just change this from status.open to open, that will do it?

Many Thanks

[Steve Giller]

That would probably work, however the Wait for Status Change node itself outputs the new Status:

so it's more efficient to test on that.

[Adam Toms]

Thanks @Steve Giller,

I will do some testing and see how I get on.

Many Thanks.

[Estie]

@Adam Toms - Did you get to the bottom of this?

We have a similar workflow process as yours above with a similar custom expression and I have just noticed that the custom expression box is now blank and when clicking on edit expression the expression is visible and is the same as yours above ie status.open

We have not made any changes to the expression in our workflows since they were created in 2021 so it seems strange that this expression is now blank and is incorrect.

I will be raising a support request for this and wondered if you had changed your expression?

[Victor]

@Estie you can set up the decision paths(s) to check for a request being reopened in two ways:

1. You make use of the output param returned by "Wait For Status Change: newStatus". The condition would use the variable from Wait For Status Change, which should be something like: Hornbill Automations -> Wait For Status Change -> Request Status. The value is status.open when you use the equal (==) operator or you can use open as a value when you use contains operator.

2. You make use of the output param returned by a Get Request Information node (which is what Adam posted in the screenshot). However for this to work you would need to have a Get Request Information node after Wait For Status Change. The condition would use the variable from Get Request Information, which should be something like: Hornbill Automations -> Get Request Information -> Status. The value is open when you use the equal (==) operator or you can use open as a value (same value) when you use contains operator.

[Estie]

@Victor Excellent thank you for the clear explanation.

[Estie]

 

 @Victor

On 22/05/2024 at 13:51, Victor said:

@Estie you can set up the decision paths(s) to check for a request being reopened in two ways:

1. You make use of the output param returned by "Wait For Status Change: newStatus". The condition would use the variable from Wait For Status Change, which should be something like: Hornbill Automations -> Wait For Status Change -> Request Status. The value is status.open when you use the equal (==) operator or you can use open as a value when you use contains operator.

2. You make use of the output param returned by a Get Request Information node (which is what Adam posted in the screenshot). However for this to work you would need to have a Get Request Information node after Wait For Status Change. The condition would use the variable from Get Request Information, which should be something like: Hornbill Automations -> Get Request Information -> Status. The value is open when you use the equal (==) operator or you can use open as a value (same value) when you use contains operator.

Does this mean that expressions which use 'Flowcodes' rather than 'Hornbill Automations' are still valid?  Or do they need updating?

I cannot see 'Flowcodes' option in either of the scenarios you outline.

 

[Victor]

24 minutes ago, Estie said:

Does this mean that expressions which use 'Flowcodes' rather than 'Hornbill Automations' are still valid?  Or do they need updating?

@Estie expressions that display "Flowcodes" should still be valid and they don't necessarily need an update (I'll explain below how and why) and you can update them if you like, it will not break existing configuration.

Historically, workflow nodes didn't incorporate a "Result Reference," which meant that using the same node multiple times in a workflow would update the output parameters for that node each time it was used. Then, we introduced the concept of "Result Reference," allowing for a separate set of values for output parameters when distinct values for the result reference are used (think of it like snapshots of different value sets). For instance, you can place a Get Request Information node at the start of the workflow to capture the request values at that moment. Later in the workflow, you can use another Get Request Information node with a different result reference to capture a new set of request values. This approach enables you to track "historical" request values within your workflow. If the second Get Request Information node uses the same result reference as the first, it will simply refresh the values obtained from the initial run of the node.

 

To address the question you raised, before the introduction of the result reference concept, all output parameters were referenced as "flowcode." With the introduction of result reference, we now reference nodes using "Hornbill Automation." In any newly built workflows, the result reference is automatically filled with a value (for example, Get Request Information has getReqInformation as a default value). However, in older workflows, you might find nodes without a value in this field, because the result reference feature didn't exist when they were created. For backward compatibility, these older nodes are still referenced with a simple "flowcode." This also clarifies why "flowcode" references are no longer an option when building new workflows or updating existing ones.