Skip to main content
Visit Freshworks.com Visit Freshworks

We have a issue using App Orchestrations with Workflow Automations, they break the Workflow Automator from continuing to other automations.

 

The issue is that we currently have 162 Workflow Automations because we have multiple customers, which all require their own automations. Some of these automations have Orchestrations in them, for example, escalating tickets to Pagerduty for on-call agents or sending ticket information to Slack using their respective Orchestrators.

The issue is that if, for example, Automation #10 out of 162 has a Slack Orchestration to send the ticket details to a Slack channel, and it it’s event and conditions are checked as True, the Slack Orchestration is initiated. This is great, so far everything works as expected, however, the following Automations will never run, meaning that 152 Automations are left out, even if they might not even trigger.

Setting a timer for these doesn’t work either, as Workflow Automator goes through the list of automations one by one, if one has a timer, it will wait for it to be finished before continuing on to the next automation on the list.

 

Has anyone else encountered this issue with Freshservice? We’ve created a ticket about this to Freshworks, but it seems this might be by design...?

 

This functionality or bug defeats the purpose of using Orchestrations, everything seemed to work fine without using the Orchestrations, using the legacy Slack or Pagerduty applications. However, those have since been discontinued, and it feels odd to take two steps backwards just to have a working ticketing system.

Seems like the only fix to this currently might be to gather all orchestrations in to a single Automation Workflow, and have it be the last in the list, however, this would be very tedious to maintain, as we would need to have all of our customer integrations in a single workflow.

Hi @joonasv,

can you try the same with two web requests in these two workflows? I assume orch apps have the same behaviour. If two workflows have the same event and the first one getting executed has one more web requests then subsequent workflows with the same event don’t trigger anymore. Known issue and I’m waiting on a bugfix that was promised to us asap.

Best regards
Daniel

Hello @DanielRuff,

 

I can indeed confirm that if one workflow of the same event has more web requests than the subsequent workflows, the Workflow Automator breaks. I have tested the scenarios below:

 

Scenario 1:

Automation #1: Webhook-test-1 (when a ticket is raised, do a web request action)

Automation #2: New ticket created (set status as new, and set custom field “reopen count” as 0)

Automation #3: Webhook-test-2 (when a ticket is raised, do a web request action)

 

While Webhook-test-1 has one web request, and Webhook-test-2 has one web request:

 

Scenario 2:

Automation #1: Webhook-test-1 (when a ticket is raised, do a web request action, and then do a second web request action)

Automation #2: New ticket created (set status as new, and set custom field “reopen count” as 0)

Automation #3: Webhook-test-2 (when a ticket is raised, do a web request action)

 

While Webhook-test-1 has two web request actions:

 

Note that no other workflows are being run if one automation has multiple web request actions.

Hi @joonasv,

This behavior happens when the orchestration node is  returning an unexpected response like failure or 400 error codes.

You can try adding a condition node next to the orchestration node like the one shown below. This will drop the orchestration action and continue the workflow automator actions. If needed, you can add an action for failed app actions so that you can be notified about the same.

 

 

Hi @joonasv,

This behavior happens when the orchestration node is  returning an unexpected response like failure or 400 error codes.

 

Hi @robertromario,

 

It seems that this may not be the case, as when reviewing the Workflow Execution log, it only ever shows success, even when the other workflows are never initiated after: 

 

When looking at the Orchestration app logs, the logs are not so simple to go through anymore it seems. I could swear that the logs were a lot more verbose previously, now there seems to only be very little logs on that side.

 

When testing out the Slack Orch or the Pagerduty Orch, it always returns 200 if the authentication is correct, as the Orch apps fill out the necessary headers and endpoints:

 

However, I’ll definitely try adding the conditions, if it might be a solution. 🙏

This is not depending on the response code. I had a long conversation about that with a lot of employees from freshworks. This is a confirmed bug/behaviour and they plan to roll out a fix for customers that ask for this. At the moment it’s not planned to release this fix for every customer due to possible heavy impact. If needed you should contact support or your CSM.

Right now I’m waiting for that fix. It was promised to me end of last month but got delayed due to additional bugs they wanted to fix first.

 

Instead of checking for the response code in a condition node you can also check my topic about monitoring of web requests. The issue with having this in a condition node is you have to branch the path and duplicate a lot of nodes. This happens when web requests don’t need to be successful to execute everything behind the requests:

 

Also feel free to upvote this idea for monitoring of workflows. 🙂 This would also help you in a lot of use cases with your automations.

 

Thanks, 

Seems like the only thing right now is to wait for a fix for this. The only workaround here is to put all of the Orchestration automations as last on the Workflow Automator order. 

Freshworks did implement something to do with timeout values for the workflows, but after monitoring for two weeks, this was not the fix needed. 

Once I get anything new about that fix I will let you know.

Hi @joonasv,

the bugfix got deployed yesterday in our instance and it looks quite good. Subsequent workflows get executed even after the API requests. Maybe you should contact the support and ask them to deploy that bugfix to your instance as well.

Thanks @DanielRuff, I’ll ask the support to check this on my open ticket to Freshworks.

We discussed this with the Freshservice support, and they implemented the fix to our sandbox, and everything seems to work perfectly now. No nodes are getting stuck (Orchestration/Webhook Requests tested). All subsequent Workflows work exactly as they should.

 

Seems we had the same bug @DanielRuff, thank you!

Hello everyone, 

If you are facing this issue, please reach out to your Freshworks support or CS partner. We will enable the fix.
Soon, we plan to make the fix live for all our customers. 

Post that, if there is a web request or app orchestration node in a workflow - once that entire workflow is completed, all subsequent workflows will get executed. 

Thanks!

Reply


Terms of Use