Skip to main content
Visit Freshworks.com Visit Freshworks

I am relatively new to FreshService so I apologize if this has been answered clearly elsewhere. Long story short,  I am trying to sequence multiple tasks and workflows in order to automate some processes, but I am having trouble getting them to reliably trigger from one another. I have discovered this thread here:

In which it is stated that, according to Support, ‘System’ events do not trigger workflows, so I have been trying to use webhooks within the Workflows to the API to get around this limitation. However, it doesn’t seem to be able to get me where I am trying to go. To illustrate what I am attempting to accomplish:

  1. The API is used to create a Task, for example Task_One
  2. There is a Workflow, Workflow_One, which is supposed to trigger when Task_One is created, and it does trigger correctly. 
  3. Within Workflow_One, there is an API Webhook to create Task_Two, which is successful and Task_Two is created as expected. The workflow also continues past the point and completes the rest of the things it is expected to do successfully.
  4. There is a second Workflow, Workflow_Two, which is supposed to trigger when Task_Two is created, and it does *not* trigger in this scenario. There are no events/evidence of failures or attempts to run in the parent ticket, tasks, or the log.
  5. If I run the API call to create Task_Two directly within the workflow editor as a test, or even remotely using the API through Powershell, Workflow_Two does trigger correctly and performs exactly as expected so this should hopefully rule out simple typos in the workflow trigger condition.
  6. Both/All of the API calls in this example are performed using the same User API credentials, and successful events do show as the expected user (not ‘System’).
  7. Both workflows are “Task created” event triggers and use “Title contains uTask_Num]” conditions to know when to trigger.
  8. For purposes of this example, Workflow_One and Workflow_Two are independent of each other as far as completion of their functions; although I say ‘sequence’ I don’t mean  I require them to perform literally in a serial manner. I don’t need Workflow_One to wait on Workflow_Two to complete or anything like that, I just want want Workflow_Two to be reliably triggered by Workflow_One creating Task_Two.

The reason I am trying to sequence tasks and workflows is because I am trying to avoid the enormous spaghetti that I’ve seen some workflows turn into due to things like basic conditions creating hard forks in the workflow path, which seems to lead to a dozen or more end-paths within the same workflow that are all nearly identical and that just doesn’t seem tenable long-term, see here:

So I guess really my questions is, given the lack of clear documentation on how this is supposed to/expected to behave and the threads I have found of others having similar problems sequencing tasks and workflows, is it even possible to create tasks for purposes of triggering workflows in this way? And if so, how is it being done? If not, is everyone else out there just using a bunch of external scripting via Python or Powershell (or whichever favorite flavor) to do it all?

In general, webrequests(webhooks) from automation do not trigger another automation. I my best guess is to prevent loops. 

If the API call would come from a external system it should trigger the next flow.

There will come a function to call other WFA’s this year. How it will look like I don’t know. 
 

Thanks, Daniel. That’s more or less what I was afraid of, considering the comments about ‘System’ not being able to trigger automations, I was just hoping there was a more straightforward way around it than to use remote triggers. 

I think what I may investigate is leveraging the Powershell feature. Instead of using API calls directly through webhooks in the workflow, call a custom Powershell script in the workflow that can accept and then pass along the required inputs to the API. This way, the API calls are all being performed by Powershell instead of a Workflow directly, and so perhaps it might just be crazy enough to work. I haven’t fully fleshed out the idea so there might be an obvious flaw in it, but it’s worth a shot after a cup of coffee I suppose.

If anyone else out there has any other suggestions or discussion about how they’ve seen this done, I’m curious to know what else others have come up with. Perhaps I just need to reconceptualize how I think about these processes in order to make them work more seamlessly within this product.

 

Thanks, Daniel. That’s more or less what I was afraid of, considering the comments about ‘System’ not being able to trigger automations, I was just hoping there was a more straightforward way around it than to use remote triggers. 

I think what I may investigate is leveraging the Powershell feature. Instead of using API calls directly through webhooks in the workflow, call a custom Powershell script in the workflow that can accept and then pass along the required inputs to the API. This way, the API calls are all being performed by Powershell instead of a Workflow directly, and so perhaps it might just be crazy enough to work. I haven’t fully fleshed out the idea so there might be an obvious flaw in it, but it’s worth a shot after a cup of coffee I suppose.

If anyone else out there has any other suggestions or discussion about how they’ve seen this done, I’m curious to know what else others have come up with. Perhaps I just need to reconceptualize how I think about these processes in order to make them work more seamlessly within this product.

 

Can you show me a bit more what the process flow is with tasks are I can maybe come up with a solution :) 

There may be a better way to go about this, but the solution I’ve come up with is as follows in case anyone in the future wants to consider whether or not it would be appropriate for them, or if someone else wants to come in and offer critique. I created an ‘API Helper’ in the form of a Powershell script for testing then recreated the functionality using Power Automate so this can live entirely in the cloud.

This ‘API Helper,’ in the case of the Power Automate version of the solution, accepts an API call as a trigger, which I call from a Web hook in my FS Workflow. This is always a POST action to the Power Automate workflow. The Body of the request configured in the FS Web hook is a simply JSON that is like a request-in-a-request, as illustrated here:

{

  "API_URI": ""The URI of the FreshService API endpoint needed goes here]”,

  "API_Method": ""The method (post, get, put) that is needed for the FreshService API goes here]",

  "API_Request_Body": {RThe body for the FreshService API request goes here, it must be in the curly brackets]}

}

 

 

The Fresh Service credentials are stored within Power Automate for this, so they don’t need to be passed in.

From there, the Power Automate workflow will perform either a GET, POST, or PUT based on what is included in the “API_Method” to the URI that is passed in as the “API_URI” and simply passes along whatever is in the “API_Request_Body” for the Body of the Request. I then have it Return whatever response it gets as the Response to the endpoint that called it, so you get the same complete response back to the original FS Workflow Web hook as if you called its API directly.

(For those who are curious, the Switch is used because a GET will fail if a body is included at all, even if it is empty, so there needed to be a way to either include or not include a Body based on the Method instead of just using the same thing for all of them. I also haven’t tested this for anything except GET, POST, and PUT so any other type of request just kicks back a 400.)

The FS Workflow is none the wiser that there’s an intermediary, you can reference all the same fields in the response (such as if you create a task, you can get the Task ID) exactly as you normally would, but because it’s being performed by an “external source” it does indeed trigger any and all subsequent automations and workflows that one might expect (for creations, updates, etc) without issues.

 

Could you create an infinite loop with this? Yeah, but you can also disable the Power Automate workflow on the PA side which would kill it, so just be cautious. It does also slow things down a bit since it’s basically making a call that creates another call that then has to complete and respond to the first call, but we’re still talking <1 second on average so it’s not exactly problematic.

Although it’s a bit of a roundabout way of doing it, it’s generic and workflow-agnostic so it can be used in place of any future API calls to FreshService that I might want a workflow to make. There probably isn’t any benefit to strictly querying data (a GET) this way, but it does work so I can stick to it for the sake of consistency.

Reply


Terms of Use