The setting of the correct time zone for service accounts in Microsoft Dynamics 365 is crucial for accurate business logic execution, particularly when dealing with time-sensitive functionalities like order deadlines. Given your interest in Dynamics 365, eCommerce, and Supply Chain, this topic is indeed pertinent.
Hidden within the user accounts in Dynamics 365, you’ll find service accounts like RetailServiceAccount, which is vital for real-time calls between the Cloud Scale Unit (CSU) and Finance & Operations (F&O). To locate these accounts, navigate to the user section and apply the isMicrosoftAccount = true filter.
Then you get the following list:
Each service account has a default preferred time zone, sometimes set to GMT-8 for RetailServiceAccount. This becomes crucial when you’re building features that rely on date and time calculations. For example, order deadlines for same-day or next-day deliveries are often determined based on the time zone. Within the code, you may encounter instances where DateTimeUtil::getUserPreferredTimeZone() is used, as in the SalesCalcAvailableDlvDate class. This function fetches the time zone from the user executing the code, which for retail calls is typically RetailServiceAccount.
If the time zone isn’t set correctly for service accounts, time-sensitive calculations like order deadlines could be inaccurate. This method appears 430 times in the standard codebase, making its impact substantial. To modify these settings, you can simply add the preferred time zone column to the user account, click ‘Edit,’ and make the necessary adjustments. This is also applicable to other settings like language and number format.
It’s imperative to set the correct time zone for service accounts executing system jobs or batches in Dynamics 365. This ensures that your business logic related to date and time operates as intended. Given the relevance of this topic to your work in eCommerce, Supply Chain, and management consulting, it’s a detail that warrants careful attention.
And then to a question: What should we do if we operate in multiple time zones? Then I think there are more improvements to be made to ensure that time zone calculations are better handled, and is not originating from the preferred time zone on a service account.
Kurt Hatlevik - Dynamics 365 Blog 
Hello Kurt, Thank you for the article!
I had a question, which is a little off topic to the article. Can we create additional service accounts for testing, or is that a big no no, based on the security model and license agreement with Microsoft, since we cannot have any non personal ids.
Do you know if any of the already existing service accounts can be used for testing?
LikeLike
Hello Kurt, Thank you for the article!
I had a question, which is a little off topic to the article. Can we create additional service accounts for testing, or is that a big no no, based on the security model and license agreement with Microsoft, since we cannot have any non personal ids.
Do you know if any of the already existing service accounts can be used for testing?
LikeLike
Hi. I think a Microsoft support case work would be best to answer that. But it is an intriguing question, as the licenses are not cheap 🙂
LikeLike
Dear Daniel Kirk,
Thank you very much for your comprehensive and insightful comment on my blog post. Your input adds significant value to the Dynamics 365 community, and I appreciate the detailed examples you provided regarding the importance of utilizing the Company Time Zone.
I concur with your viewpoint that the Company Time Zone is a more reliable reference point for handling business transactions/data, especially in multi-company setups. Your code samples to implement this approach are particularly helpful and I believe they will serve as a valuable resource for developers and consultants alike.
Your suggestions regarding the potential for more specific time zone configurations within a company are also intriguing. These could serve as an excellent starting point for further discussions and potential enhancements to Dynamics 365 implementations.
Once again, thank you for taking the time to share your expertise. I look forward to your future contributions to the blog and the wider Dynamics 365 community.
P.S. I will definitely consider covering the topic of Company Time Zone versus User’s Preferred Time Zone in a future blog post, and will be sure to credit your insights.
LikeLike
Hello Kurt,
I enjoy your blog!
Thanks for all your posts!
For handling time zones in general I think the Company Time Zone is beneficial.
Using the Company Time Zone is better than the user’s time zone if the user doesn’t have their preferred time zone configured, or if the user posts transactions in multiple companies with different time zones (manually or via batch jobs).
This is the same issue as service accounts.
I believe the User’s Preferred Time Zone should only be used for displaying dates on Forms to the user in their preferred time zone.
It should not be used for saving business transactions/data into the database (which is shared by all users).
In the database, utcDateTime fields should always have no timezone (UTC +0), and Date fields should be converted into the Company/DataAreaId time zone by code before saving.
For most scenarios I believe that the DateTimeUtil::getCompanyTimeZone() is more appropriate than DateTimeUtil::getUserPreferredTimeZone().
Many time zone issues can be prevented by simply replacing getUserPreferredTimeZone() with getCompanyTimeZone() instead.
Here are some examples of how to use the Company Timezone instead of the User’s Preferred Timezone.
Date Example:
journal.PostedDate = CompanyInfo::getCurrentDate();
DateTime Example:
currentDateTime = DateTimeUtil::applyTimeZoneOffset(DateTimeUtil::utcNow(), DateTimeUtil::getCompanyTimeZone());
The company time zone is determined by the ZipCode or State or Country on the Company’s Legal Entity Address.
This code can be conveniently called if you develop a new method on the CompanyInfo table:
public static utcDateTime getCurrentDateTime()
{
return DateTimeUtil::applyTimeZoneOffset(DateTimeUtil::utcNow(), DateTimeUtil::getCompanyTimeZone());
}
currentDateTime = CompanyInfo::getCurrentDateTime();
If you need the time zone to be more specific/granular within a company, then maybe we could use multiple retail service account users for different instances/integrations, or consider developing logic based on the Warehouse Site (InventSite.TimeZone) or the Retail Store (RetailStoreTable.ChannelTimeZone) or the Retail Channel (RetailMCRChannelTable.ChannelTimeZone, RetailChannelTable.ChannelTimeZone).
Hopefully this is useful for the Dynamics community!
Daniel Kirk
Dynamics 365 F&O Developer
New Zealand!
LikeLiked by 1 person