This Article is a synopsis of Time Zone functionality in improveit 360 Lightning. We will discuss how Smarty assigns a Time Zone on the Address record and how improveit 360 uses this Data across various Objects. We will also discuss the Date/Time Fields available for Email and Texting Templates. We will cover the User Experience for different Roles within your organization and what they will see when viewing the Staff Calendar and Scheduling Calendar when Users are in different Time Zones. Lastly, we will discuss some System Best Practices to implore when setting up Time Blocks for Users in different Time Zones.
Establish Time Zone Functionality
We are using Smarty Streets to pull the Time Zone and related Offset (from UTC) and populate those fields based on the Address geolocation from Smarty. Every Address record that has been validated by Smarty will now have three fields filled out: Time Zone, UTC Offset, DST.
Fields on each Object:
- eLead
- Time Zone: Text (255)
- UTC Offset: Decimal (4,2)
- DST: Boolean
- Address
- Time Zone: Text (255)
- UTC Offset: Decimal (4,2)
- DST: Boolean
- Sales Appointment
- Local Appointment Start Date/Time Short (Format - 12/12 at 10:02 AM)
- Local Appointment End Date/Time Short (Format - 12/12 at 10:02 AM
- Local Appointment Start Date/Time Long (Format - December 12, 2023 at 10:02 AM)
- Local Appointment End Date/Time Long (Format - December 12, 2023 at 10:02 AM)
- Project Activity
- Local Appointment Start Date/Time Short (Format - 12/12 at 10:02 AM)
- Local Appointment End Date/Time Short (Format - 12/12 at 10:02 AM
- Local Appointment Start Date/Time Long (Format - December 12, 2023 at 10:02 AM)
- Local Appointment End Date/Time Long (Format - December 12, 2023 at 10:02 AM)
Fields on the Address record are stamped upon Smarty address verification. To see these fields, you will need to add them to the Page Layout and activate a new Lightning Record page:
Time Zone: Represents the Time Zone of the Address (provided by Smarty)
UTC Offset: Number value representing how many hours (+/-) this location is from UTC (based on Time Zone)
DST: Captures whether or not the address respects Daylight Saving Time
Email and Texting Date/Time Fields
When using Email Templates, you may choose to use the Long format Date/Time field, whereas for Texting you will want to use the Short format Date/Time field instead to save character space. Examples of both types of fields on each relative Object are shown below:
Sales Appointment
- Local Appointment Start Date/Time Short (Format - 12/12 at 10:02 AM)
- Local Appointment End Date/Time Short (Format - 12/12 at 10:02 AM
- Local Appointment Start Date/Time Long (Format - December 12, 2023 at 10:02 AM)
- Local Appointment End Date/Time Long (Format - December 12, 2023 at 10:02 AM)
Project Activity
- Local Appointment Start Date/Time Short (Format - 12/12 at 10:02 AM)
- Local Appointment End Date/Time Short (Format - 12/12 at 10:02 AM)
- Local Appointment Start Date/Time Long (Format - December 12, 2023 at 10:02 AM)
- Local Appointment End Date/Time Long (Format - December 12, 2023 at 10:02 AM)
Users in Different Time Zones
The Address record will always determine the Time Zone for the Sales Appointment or Project Activity, regardless of the Time Zone of the person scheduling the Appointment. For example...
Cathy in our Call Center is in Central Time, but she schedules Appointments for Reps in Eastern, Central and Mountain time. When Cathy is scheduling an Appointment for a Rep in Mountain time, the Contact will confirm a 10am Appointment, Cathy will select 10am on the Scheduling Calendar, and Save.
Cathy will see the Appointment Time as 10am once the record is Saved.
Sam the Sales Rep is also in Mountain time (as is the Address) and Sam will see the Appointment at 10am on his Staff Calendar.
Also note that Cathy, being in Central time will see this Appointment at 9am on her Staff Calendar, because her computer's time is one hour behind the Mountain time (the Time Zone of the Address and Appointment).
Setting up Time Blocks for Users in different Time Zones
When creating Time Blocks for a specific Time Zone, the User who creates the Time Blocks will need to be in the same Time Zone as the Rep's the Time Block will be used for. For example, if we are creating a Time Block for our Mountain Time Sales Reps, we will need to create the Time Blocks as a User within Mountain Time.
Note: A Time Block should NOT be used for Reps in more than one Time Zone. For example, you should not co-mingle Reps in Eastern time with Reps in Mountain Time. Time Blocks should be Time Zone specific.
Note: Changing the Owner field does NOT change the Time Zone of a Time Block. Time Blocks will need to be created by a User in the correct Time Zone for the Time Block.
Comments
0 comments
Article is closed for comments.