Skip to main content

As of today, when scheduling rules or rule chains, a user only has the following time zone options to schedule in:

  • Timezone listed in user profile
  • Timezone listed in application settings
  • UTC

In a world of remote working, a given organization may have a business need to schedule in a time zone other than these three options to keep all rules synchronized (ex, application settings are in CST, user operates on IST, all rules synchronized to EST). In this case, the current configuration would not catch all the needs of the company.

 

There should be a way to add additional time zones for scheduling rules from Rules Engine>Rules Settings (or perhaps even just a way to request an option be added on an organization-by-organization basis if nothing else).

 

In cases in which the org would like to schedule rules/rule chains in a timezone other than the one found in their user’s or application’s settings without re-configuring one of those each time they need to schedule something, the only workaround that I have been able to think of this far is to have a “Rule Scheduling” dummy user in the desired ‘scheduling time zone’ (to make that timezone available within the schedule setup window), which the admins could use to schedule the rule after building it out from their own login (to maintain the accuracy of the “created by” field). Downside being that this would effectively occupy a full license, so likely isn’t the ideal solution.

@mmayhall I actually have an open support case about this (208330 if any Gainster see this, for reference). We also had schedules show up with a blank time zone. And somehow our Org Timezone changed inexplicably as well.

@mmayhall I’m very curious to learn more about your business use case for scheduling rules in Timezones not associated with the application or the building user.

I’ve found with Rules, there is so much sequentiality (is that a real word, or one I just made up?) in which rules run in what order, that I like thinking of the Rules Engine schedule in terms of a single Timezone (typically the application settings time zone) for simplicity.

That said, I’m interested in your use case.

@mmayhall I’m very curious to learn more about your business use case for scheduling rules in Timezones not associated with the application or the building user.

I’ve found with Rules, there is so much sequentiality (is that a real word, or one I just made up?) in which rules run in what order, that I like thinking of the Rules Engine schedule in terms of a single Timezone (typically the application settings time zone) for simplicity.

That said, I’m interested in your use case.

We usually run in EST and try and sync with that, but sometimes things are created in Pacific and Central. If I have a rule made in Central and I need to update it, it would be weird for me to need to change the time zone if I’m in Pacific and the org is in Eastern. Or what if I have a data set that makes sense to run on Central, so I want to set it up on that time zone for convenience? Can’t do it.

It’s just kind of awkward how time zones seem all over the place in the platform.

Hi @matthew_lind! Unfortunately, I don’t have a specific use case of my own, per se, just another support rep posting about a situation I happened across in a ticket recently. However, the use case @bradley described is pretty on par with what I was seeing. :)

Terms & ConditionsCookie settingsAccessibility statement