Skip to main content

Notifications

Announcements

Check out the New Agent Creator Community
Announcing new navigation menus and the Engage with the Community forum!
News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / Dynamics 365 FastTrack Blog / Time Zone Identification fo...

Time Zone Identification for Quiet Time Feature in Dynamics 365 Customer Insight

Nikolai Popov Profile Picture Nikolai Popov Microsoft Employee

Introduction: The Challenge of Time-Aware Communication

In the world of customer engagement, timing is everything. Sending communications at inappropriate hours can significantly impact customer experience and potentially violate local regulations. The enhancement of the Quiet Times feature in Dynamics 365 Customer Insights - Journeys (CI-J) provides a powerful mechanism to prevent messages from being sent during unwanted hours following customers’ local regulations and time. However, for this feature to work effectively across global operations, proper customers time zone identification and management are essential.
This technical guide explores various options for implementing time zone identification within your Dynamics 365 CI-J environment. It is designed for implementation partners and customers who need to enhance their quiet time functionality with more accurate time zone handling.

Understanding Quiet Times in Dynamics 365 CI-J

Before diving into implementation options, let's understand what Quiet Times does in Dynamics 365 CI-J.
The Quiet Times feature enables organizations to configure specific periods when automated messages shouldn't be sent to customers. As described in the Microsoft documentation:

"Quiet times enable you to configure specific times when messages won't send to customers to avoid contacting them when it's inappropriate. You might not want to send messages at specific times due to regulations, business policies, or other factors. Typically, quiet times are configured for overnight hours, weekends, or holidays. When quiet times are in place, the system holds the messages until the quiet times end." - Set quiet times to prevent messages from sending during unwanted hours - Dynamics 365 Customer Insights | Microsoft Learn

While the current implementation of quiet time based on the journey time zone works well for certain scenarios, it has limited ability when it comes to comply with local country regulations and ensuring each individual contact's local time is respected. This is where advanced options allow quiet time to be interpreted using recipient’s time zone becomes valuable.

Quiet Time Configuration in CI-J: Core Concepts

Feature Overview

  • Purpose: Prevent messages from being sent during nights, weekends, holidays, or other restricted periods.
  • Time Zone Alignment: As of May 2025, Quiet Times can align with either the journey’s time zone or the recipient’s local time zone via the Time Zone field in Audience configuration.

Configuration

  1. Quiet Time Settings: Configure quiet periods per channel (email, SMS, push) and message type (commercial/transactional) under Settings > Customer Engagement > Quiet Time.
  2. Audience Configuration:
    • Map time zone fields for contacts, leads, or Customer Insights profiles under Settings > Customer Engagement > Audience Configuration.
    • Fallback: If no time zone field is mapped, the system defaults to the journey’s time zone

Time Zone Identification Options

Let's explore five different options to implementing time zone identification for your contacts, leads and Customer Insights - Data profiles. How to implement these options is explained in the next section. In all these discussions “recipient” is used to mean the person who will receive communications and we wish to manage quiet times for them. We assume that you are going to create a new field for these purposes (example: new_timezoneid – Time Zone Format) but you can use either already created custom field or one of the OOB fields.

  1. User Profile Settings
This option leverages the time zone settings specified in the app user's (Owner) profile in Dynamics 365. This option works for situations where app user and recipients are in the same time zone.
Pros and Cons:
Advantages:
  • Simple implementation with minimal development effort
  • Directly tied to existing app user settings
  • No additional costs or external dependencies
Disadvantages:
  • Doesn’t work if app users (owners) time zone are different than recipient’s time zone
  • May not be accurate for global operations where app users (owners) handle recipients across different regions

  1. IP Address Geolocation / Browser Time Zone
This option detects time zones based on the recipient's IP address or browser settings when they interact with your organization.
Pros and Cons:
Advantages:
  • Automatic detection requiring no manual input
  • Captures time zone at point of interaction
Disadvantages:
  • May be inaccurate due to VPNs or proxy servers
  • Only works for recipients who have new interactions or form submissions
  • Potential compliance concerns with IP tracking
  • Additional costs for geolocation services

  1. Longitude/Latitude Time Zone Identification
This option uses address information of recipients in Dataverse to determine their geographic coordinates, then calls mapping APIs to identify the corresponding time zone.
Pros and Cons:
Advantages:
  • High accuracy when address data is correct
  • Leverages established mapping services with reliable time zone data
  • Works well when recipients have fixed locations
Disadvantages:
  • Requires Dynamics 365 Field Service or extra call to Azure Maps for coordinates identification
  • Additional licensing costs for Azure Maps API
  • Depends on accurate and complete address information

  1. Phone Number Time Zone Identification
This option uses the contact's phone number to infer their time zone, particularly useful in countries where area codes correspond to specific regions.
Pros and Cons:
Advantages:
  • Works with existing recipient data without requiring additional input
  • Relatively easy to implement with open-source libraries
  • No additional infrastructure required
Disadvantages:
  • Accuracy varies by country (works best in countries with geographic phone numbering)
  • Mobile numbers may not reflect actual location
  • Requires correctly formatted phone numbers with country codes

  1. Contact and Lead Data Time Zone Identification
This option uses a mapping table to associate contact/lead data (such as country, state/province, zip code) with corresponding time zones.
Pros and Cons:
Advantages:
  • Complete control over the mapping rules
  • No external dependencies or additional costs
  • Can be customized for specific business needs
Disadvantages:
  • Requires manual creation and maintenance of mapping data
  • May become outdated if time zone rules change
  • Complex to handle edge cases like borders between time zones

Comparing different options

OptionAutomatic DetectionUser Input RequiredAccuracyImplementation ComplexityCost (3rd party, Licensing, etc.)
User Profile Settings YesYesHighLowNo
IP Address Geolocation / Browser Time ZoneNoNoMediumHighNo
(Web site)
Longitude/Latitude Time Zone identificationYesYesHighMediumYes
(Azure Map / Field Service)
Phone number Time Zone identificationYesNoMediumMediumNo
(Open-source API)
Contact and Lead data Time Zone identificationNoYesLowMediumNo

Implementing Time Zone Identification options

Selecting the right time zone identification option requires balancing accuracy, maintainability, and dependency on external systems. Three options —User Profile Settings, Longitude/Latitude Identification, and Contact/Lead Data Mapping—stand out for organizations prioritizing control over third-party integrations while leveraging existing Dynamics 365 data. These options minimize reliance on external APIs, reduce licensing costs, and align with Microsoft’s native capabilities, making them ideal for regulated industries or cost-sensitive implementations. Below, we explore their technical implementation in detail, providing actionable steps for integration with the Quiet Time feature.

1. User Profile Settings
Why It’s Preferred: Leverages existing app user's (Owner) profile without external dependencies.
Implementation Steps:

Retrieve Owner Time Zone:

Retrieve the time zone code from the UserSettings linked to the record owner.
 1. // JavaScript function on Contact/Lead form 
 2. function fetchUserTimeZone(userId) { 
 3.     Xrm.WebApi.retrieveMultipleRecords( 
 4.         "usersettings", 
 5.         `?$filter=_systemuserid/value eq '${userId}'&$select=timezonecode` 
 6.     ).then( 
 7.         result => { 
 8.             if (result.entities.length > 0) { 
 9.                 const timeZoneCode = result.entities[0].timezonecode; 
10.                 console.log("User Time Zone Code:", timeZoneCode); 
11.             } 
12.         }, 
13.         error => console.error("Error:", error) 
14.     ); 
15. }

Map Time Zone Codes:

The TimeZoneCode in UserSettings corresponds to entries in the new_timezoneid field. For example:
  • TimeZoneCode=4 maps to (GMT-08:00) Pacific Time (US & Canada) (IANA ID: America/Los_Angeles).

Apply Logic:

Configure a Power Automate flow triggered on record update to apply the app user's (Owner) time zone to the contact/leads’s time zone field:
Flow Steps: 
a. Trigger: When a Contact/Lead is created or owner changes 
b. Action: Retrieve UserSettings for the user
c. Parse TimeZoneCode from UserSettings
d. Update Contact/Lead’s new_timezoneid field


2. Longitude/Latitude Time Zone Identification
Why It’s Preferred: Uses Microsoft Azure Maps and Field Service (if already licensed) and CI-J is used withing the same environment, avoiding third-party vendor lock-in.
Power Automate flow (example execution steps)
1. Trigger: When a contact/lead is created or updated
2. Condition: If address fields are not empty
3. Action: Call Azure Maps Geocoding API to get coordinates
    - Input: Address fields (street, city, country)
    - Output: latitude, longitude
4. Action: Call Azure Maps Time Zone API
    - Request: GET https://atlas.microsoft.com/timezone/byCoordinates/json?api-version=1.0&query={latitude},{longitude}
    - Headers: x-ms-client-id: {your-azure-maps-client-id}
5. Parse response to extract time zone information
6. Update contact/lead record with time zone data

Implementation Steps:

Enable Auto-Geocoding:

In Dynamics 365 Field Service:
    • Navigate to Settings > Administration > System Settings > General
    • Enable Auto Geocode Addresses and configure Azure Maps integration.
If Dynamics 365 Field Service is not available, you can leverage Azure Maps Geocoding API to get coordinates:
    • Input: Address fields (street, city, country)
    • Output: latitude, longitude

Retrieve Coordinates:

Latitude and longitude are automatically stored in latitude and longitude fields on Contact/Leads records.

Call Azure Maps Time Zone API:

Create an Azure Function to retrieve time zones:
 1. // C# Azure Function
 2. [FunctionName("GetTimeZone")] 
 3. public static async Task<IActionResult> Run( 
 4.     [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req, 
 5.     ILogger log) 
 6. { 
 7.     if (!double.TryParse(req.Query["lat"], out double lat) ||  
 8.         !double.TryParse(req.Query["lon"], out double lon)) 
 9.         return new BadRequestObjectResult("Invalid coordinates"); 
10.  
11.     string azureMapsKey = Environment.GetEnvironmentVariable("AZURE_MAPS_KEY"); 
12.     using (HttpClient client = new HttpClient()) { 
13.         string url = $"https://atlas.microsoft.com/timezone/byCoordinates/json?api-version=1.0&query={lat},{lon}"; 
14.         client.DefaultRequestHeaders.Add("subscription-key", azureMapsKey); 
15.  
16.         HttpResponseMessage response = await client.GetAsync(url); 
17.         if (!response.IsSuccessStatusCode) 
18.             return new StatusCodeResult((int)response.StatusCode); 
19.  
20.         var result = JObject.Parse(await response.Content.ReadAsStringAsync()); 
21.         return new OkObjectResult(result["TimeZones"][0]["Id"]?.ToString()); 
22.     } 
23. }
 

Batch Processing for Historical Data:

Use Power Automate to iterate through existing records:
Flow Steps: 
a. List all Contacts/Leads with populated latitude/longitude 
b. For each record, call the Azure Function above 
c. Parse response and update new_timezoneid
d. Flag records with errors for manual review
 
For Customer Insights Data Profiles Microsoft’s Customer Insights Data offers Azure Maps enrichment to validate and geocode addresses automatically. As an alternative to rolling your own flow, one could use CI-Data’s data enrichment to populate latitude/longitude on unified profiles, then pass those to Journeys. Reference: Data enrichment (preview) overview - Dynamics 365 Customer Insights | Microsoft Learn , Enrich customer profiles with location data from Azure Maps (preview) - Dynamics 365 Customer Insights | Microsoft Learn , Enrich customer profiles with enhanced addresses - Dynamics 365 Customer Insights | Microsoft Learn


3. Contact and Lead Data Time Zone Identification
Why It’s Preferred: Fully controlled via internal data mappings.
Implementation Steps:

Build a Time Zone Mapping Table - Excel:

  • Structure: Create an Excel file with columns: Country, State/Province, Time Zone ID.
    Example:
CountryState/ProvinceTime Zone ID
USCA4 maps to (GMT-08:00) Pacific Time (US & Canada)
USTX20 maps to (GMT-06:00) Central Time (US & Canada)
CAON35 maps to (GMT-05:00) Eastern Time (US & Canada)
  • Format as Table:
    1. Select the data range.
    2. Click Insert > Table in Excel.
    3. Name the table (e.g., TimeZoneMapping).
  • Upload: Save the file to a SharePoint/OneDrive folder accessible to Dynamics 365.


Create a Power Automate Flow to Query Excel

Build a flow to fetch time zones from the Excel file:
Flow Steps:
a. Trigger: When a Contact/Lead is created or updated

          Add inputs (Use as variables): 
          - Country = TriggerOutputs()?['address1_country']
          - State = TriggerOutputs()?['address1_stateorprovince']

b. List Rows Present in a Table (Excel):

          Location: SharePoint/OneDrive path to the Excel file.
          Document Library: Select the folder.
          File: Choose the Excel file.
          Table: TimeZoneMapping (name of your Excel table).
          List rows in Excel table (with pagination for large datasets)

c. Filter Array:

          @body('List_rows_present_in_a_table')
          ?$filter=Country eq '@{variables('Country')}' and State/Province eq'@{variables('State')}'

d. Condition: Check if any rows match.

          If yes: Return Time Zone ID from the first matching row.
          If no: Return null or a default value.

e. Response: Return the time zone ID as JSON:
          { 
              "TimeZoneID": "@{outputs('Condition')}" 
          }
f. Update the record in Dynamics 365

You can also implement similar logic by creating a new custom table where you could store data to map it to Contact/Lead record.

Why Excel Over a Custom Table?

  • No Schema Changes: Avoids creating/managing custom entities.
  • Easy Updates: Edit mappings directly in Excel without deploying solutions.
  • Cost-Effective: Uses existing SharePoint/OneDrive storage instead of Dataverse capacity.

Trade-offs:

  • Performance: Excel lookups are slower than direct table queries. Mitigate with caching.

Fallback Logic:

Configure a Power Automate flow to flag unmapped regions for manual review.

Why These Three Options?

These options prioritize minimal third-party dependencies:
  1. User Profile Settings and Contact/Lead Data Mapping rely entirely on internal Dynamics 365 data and org data that maintained by your organization and admins.
  2. Longitude/Latitude Identification uses Azure Maps and/or Dynamics 365 Field Service (a Microsoft-native service), avoiding fragmented vendor integrations.
  3. Contact and Lead data mapping from Excel or custom table as a source rely on and fully controlled via internal data mappings
By focusing on these options, organizations maintain control over data flows, reduce licensing costs, and simplify compliance — critical for regulated industries like healthcare or finance.

Implementation Approach and Best Practices

When implementing time zone identification for the Quiet Time feature, consider the following steps:
  1. Evaluate and Select the Appropriate Option
Assess which option best fits your organization's requirements, considering:
  • Available data quality (address completeness, phone number formatting)
  • Budget constraints (paid APIs vs. free solutions)
  • Accuracy requirements
  • Implementation complexity

  1. Implement Time Zone Detection Logic
Develop the detection logic based on your chosen option:
  • For form-based approaches: Implement JavaScript on form load/save
  • For backend approaches: Create Power Automate flows or custom plugins

  1. Utilize the Quiet Time Feature
Once you've identified and stored time zone information, “If you choose the Audience time zone, the quiet times will be interpreted based on the time zone of each individual in your audience. This means that the system will use the time zone information provided for each contact, lead, or Customer Insights profile to apply the quiet time rules appropriately.  Time zone information for each contact point type is predefined under Audience configuration > Contact point type > Time zone field. If necessary, you can update it and select a different time zone format field for each type of Audience (contacts, leads, or Customer Insights profiles) and each Contact point type.  NOTE: If no time zone field is assigned under Audience configuration, the quiet time will default to the journey time zone.” - Set quiet times to prevent messages from sending during unwanted hours - Dynamics 365 Customer Insights | Microsoft Learn

  1. Testing and Validation
Thoroughly test your implementation with contacts/leads in different regions:
  • Verify time zone detection accuracy
  • Confirm that messages respect quiet times in the detected time zones
  • Test edge cases like daylight saving time transitions

Operational Considerations and Maintenance

Regular Audit and Updates

Time zone rules can change due to:
  • Political decisions in different countries
  • Daylight saving time policy changes
  • Changes to geographical boundaries
Implement a regular audit process to ensure your time zone data remains accurate.

Performance Optimization

Some time zone detection options can impact system performance:
  • API calls to external services may introduce latency
  • Complex lookups against large datasets can slow down form loading
  • Consider caching strategies and asynchronous processing where appropriate

Data Quality Management

The effectiveness of your time zone identification depends on data quality:
  • Implement address verification to ensure accurate geocoding
  • Standardize phone number formats for consistent processing
  • Consider data enrichment services to fill gaps in contact information

Conclusion

Implementing accurate time zone identification enhances the effectiveness of the Quiet Time feature in Dynamics 365 CI-J, ensuring that your communications reach customers at appropriate times. While Microsoft provides the foundational Quiet Time functionality, the responsibility for implementing precise time zone identification rests with customers and implementation partners.
By selecting the appropriate identification option and following the implementation guidance provided in this article, organizations can create a more respectful and effective customer communication strategy that honors time zone differences and improves overall engagement.
Remember that no single option works best for all scenarios, and organizations may need to implement multiple options or create a fallback hierarchy to maximize accuracy and coverage. The investment in proper time zone identification pays dividends in improved customer experience and compliance with communication regulations.

Comments

*This post is locked for comments