How Bizagi calculates case and task due dates considering timezones
When you have users using different timezones, based on the hierarchy, for example, users considering the organization timezone, others using the location timezone, and others with an individual timezone. Bizagi has to calculate case and task due dates. This section explains how it is done.
For example, your organization is based in Bogota which is located in GTM -5 time zone, and a user of your organization is located in Sydney, which is located in the GTM +10 timezone. Continuing with the previous example, a case is created on Monday at 10 GTM -5, considering the organization's time zone. The user assigned to the task is located in Sydney.
Bizagi uses logic for the calculation of the case due date, different than the activity due date. For the case due date, Bizagi leaves the same hour of the case creation, based on the organization's time zone. Therefore, as seen by the user in Sydney, the case creation is Tuesday 1 am. On the other hand, to calculate the task due date, Bizagi shifts the task creation, so it coincides with the assigned user's timezone.
Date-Time attributes shifted by Time Zones in the Work Portal
Users access the Work Portal, therefore Bizagi can always know the time zone of a user, based on the time zone hierarchy. Based on each user's timezone, Bizagi can calculate the difference between the server's and the user's timezone, and display all date-time attributes on the time zone of the user. For example, consider a project with the following configuration:
•Server time zone GMT +0
•Admon user GMT + 0 (same as server)
•User 1 time zone GMT - 5
•User 2 time zone GMT + 10
User 1 creates a case of a case of a process. Bizagi stores the date-time of the case creation based on the server time and sets this time as GMT + 0. Other users seen in the Work Portal the case creation date have the date shifted based on their respective time zones.
The following date-time attributes are shifted by user's time zone:
•Dates displayed in the Inbox, for example Case creation date, Activity due date or Case due date.
•Dates displayed in query forms
•Date-time attributes displayed in forms.
Date time attributes NOT shifted by Time Zones
In Bizagi, there are multiple attributes that are not necessarily seen by end-users, hence there they do not need to be shifted by the time zone. For example, LDAP synchronization is a programmed task that no end-user executes. Therefore, considers the time zone of the server.
Other elements that are not shifted are listed:
•Traces displayed in the Management Console Web
•DateTime.Now expression in business rules.