Skip to main content
Question

Handling timezone-sensitive customer workflows with external date-based tools

  • Aug 26, 2026 1:01 PM UTC
  • 2 replies
  • 50 views
Apprentice

Hello everyone,

I'm currently building a workflow where customers submit information through a web form and the data is later processed through automation rules and notifications.

One challenge I've encountered is handling date- and time-sensitive inputs consistently across different user locations and timezones.

For example, some external tools rely heavily on an exact date, time, and location to generate results. During testing, I noticed that even small timezone differences can lead to different outputs being generated, which makes me concerned about how those values should be stored and processed inside Freshworks workflows.

I've been testing scenarios using tools such as:

https://calcolaascendente.it/

because they make date/time discrepancies easier to identify during validation.

My questions are:

  • Do you recommend storing all incoming values in UTC before triggering automations?
  • How do you handle daylight-saving changes for workflows that may run days or weeks later?
  • Have you experienced inconsistencies between user-submitted local time and workflow execution time?
  • Is there a best practice for preserving the original user-entered datetime throughout an automated workflow?

I'm looking for recommendations from anyone who has implemented timezone-sensitive automations or integrations within Freshworks.

Thanks in advance for your insights.

2 replies

alextaylorone
Community Debut

A practical test would be to submit the same date/time from two different timezones and compare what Freshworks stores, what the automation receives, and what gets sent to the external tool. That should help pinpoint where the timezone conversion is happening.

I’d also preserve the original local time together with the timezone rather than relying only on a fixed UTC offset, especially for workflows affected by daylight saving changes.

Has anyone tested this approach with Freshworks automations?

alextaylorone
Community Debut
  • alextaylorone
  • Community Debut
  • Oct 15, 2026 7:59 AM UTC

I’d recommend storing the datetime in UTC for consistent processing, but also preserving the original local datetime and the user’s IANA timezone, such as America/New_York. UTC alone doesn’t tell you what local time the customer originally intended.

For workflows scheduled days or weeks ahead, daylight-saving changes are especially important. If the requirement is “run at 9 AM local time,” store the local time and timezone, then calculate the corresponding UTC execution time when needed. If it’s a fixed instant, store its UTC timestamp.

I’d also validate the conversion at form submission and keep the original input for troubleshooting. That makes it easier to distinguish a timezone conversion issue from a workflow execution delay or an external integration returning different results.

Terms of UseAccessibility statement