Skip to main content
New Idea

Allow Workflow Automator "Timer" Node To Accept Shorter Pauses

Related products:Freshservice
  • October 28, 2025
  • 6 replies
  • 91 views
J
Skilled Expert
Forum|alt.badge.img+5

The “Timer” node in workflow automator allows you to choose “seconds” as a unit, but the minimum allowed value is 60 seconds, which makes the “seconds” unit useless. We may as well just specify 1 with a unit of “minutes”. It would be great if you could enable shorter pause timeframes.

For context, I have disabled the “New ticket is created” requester email notification, in favor of a workflow automator that is ordered last in my list of workflows and sends this initial email. I have a few simple workflows that need to execute first (change INC to SR in specific instances, and other ticket property changes), so my last-executing workflow has a timer that pauses for 1 minute before sending the new ticket email. Sixty seconds is a bit too long I think. As a requester, I would wonder if something didn’t work right, if I sent an email to a help desk and didn’t receive a “new ticket” notification within 15-30 seconds.

Thanks for your consideration!

- Jack C.

6 replies

Daniel Söderlund
Top Contributor ⭐
Forum|alt.badge.img+14

The “Timer” node in workflow automator allows you to choose “seconds” as a unit, but the minimum allowed value is 60 seconds, which makes the “seconds” unit useless. We may as well just specify 1 with a unit of “minutes”. It would be great if you could enable shorter pause timeframes.

For context, I have disabled the “New ticket is created” requester email notification, in favor of a workflow automator that is ordered last in my list of workflows and sends this initial email. I have a few simple workflows that need to execute first (change INC to SR in specific instances, and other ticket property changes), so my last-executing workflow has a timer that pauses for 1 minute before sending the new ticket email. Sixty seconds is a bit too long I think. As a requester, I would wonder if something didn’t work right, if I sent an email to a help desk and didn’t receive a “new ticket” notification within 15-30 seconds.

Thanks for your consideration!

- Jack C.

Why do you need it ?
All workflows run in order from to bottom as long as you don’t have a pause in any of the flows above you last workflow should run after all of you changes are done. 

Synerity | Your Nordic Freshworks Partner | Seamless Support & Solutions | www.synerity.eu
J
Skilled Expert
Forum|alt.badge.img+5
  • Jack_C
  • Author
  • Skilled Expert
  • October 29, 2025

Hey Daniel,

Because while I was testing, execution order did not seem to be honored. I put this workflow at the very bottom of the order, without a timer, and it still ended up sending the “new ticket” email out before my other workflow (which is 1st in the order, and converts INC to SR based on email subject keywords) was able to do the conversion. Meaning the new ticket email referred to INC-123, and then replies would reference SR-123, since type conversion happened after the initial email sending.

I added a timer to the last-executing workflow, and everything worked.

I do have another workflow (#3 in execution order) that does have a 1 minute timer at the start, but it only executes after my ticket type conversion workflow, so it shouldn’t have any affect on the email sending process.

Daniel Söderlund
Top Contributor ⭐
Forum|alt.badge.img+14

Hey Daniel,

Because while I was testing, execution order did not seem to be honored. I put this workflow at the very bottom of the order, without a timer, and it still ended up sending the “new ticket” email out before my other workflow (which is 1st in the order, and converts INC to SR based on email subject keywords) was able to do the conversion. Meaning the new ticket email referred to INC-123, and then replies would reference SR-123, since type conversion happened after the initial email sending.

I added a timer to the last-executing workflow, and everything worked.

I do have another workflow (#3 in execution order) that does have a 1 minute timer at the start, but it only executes after my ticket type conversion workflow, so it shouldn’t have any affect on the email sending process.

Timer nodes tells the WFA engine to pause and let next WFA in order to start. So it’s not pausing all WFA’s coming after. 

Synerity | Your Nordic Freshworks Partner | Seamless Support & Solutions | www.synerity.eu
J
Skilled Expert
Forum|alt.badge.img+5
  • Jack_C
  • Author
  • Skilled Expert
  • October 30, 2025

Ah, this I was not aware of, but it makes total sense. That is a very helpful tidbit of info, thank you :)

    Daniel Söderlund
    Top Contributor ⭐
    Forum|alt.badge.img+14

    But still shorter down to 30 sec would be nice. I have had several flows where I use both actions and web requests with API and sometimes the action node is to slow. 

    Synerity | Your Nordic Freshworks Partner | Seamless Support & Solutions | www.synerity.eu
      C
      Community Debut
      • cal
      • Community Debut
      • February 6, 2026

      The “Timer” node in workflow automator allows you to choose “seconds” as a unit, but the minimum allowed value is 60 seconds, which makes the “seconds” unit useless. We may as well just specify 1 with a unit of “minutes”. It would be great if you could enable shorter pause timeframes.

      For context, I have disabled the “New ticket is created” requester email notification, in favor of a workflow automator that is ordered last in my list of workflows and sends this initial email. I have a few simple workflows that need to execute first (change INC to SR in specific instances, and other ticket property changes), so my last-executing workflow has a timer that pauses for 1 minute before sending the new ticket email. Sixty seconds is a bit too long I think. As a requester, I would wonder if something didn’t work right, if I sent an email to a help desk and didn’t receive a “new ticket” notification within 15-30 seconds.

      Thanks for your consideration!

      - Jack C.

      Why do you need it ?
      All workflows run in order from to bottom as long as you don’t have a pause in any of the flows above you last workflow should run after all of you changes are done. 

      I’m finding instances where this isn’t (quite) the case, such as the trigger on a new ticket being created, the execution order shows the system creating the ticket first, then the trigger after as expected

       

      We want to run a query against Entra that gets their actual department to ensure the correct value is set by the system

       

      However, as you can see in the execution log, when assessing the logic, the {{ticket.department}} at the time of the run is blank (after the != operateor is {{ticket.department}}

      This would be a perfect use case for a 5 second pause, so values can be set on a ticket prior to logic being run on the ticket 

      Terms of UseAccessibility statement