We're expanding our operations to cover three regions: Eastern, Central, and Mountain time. From an operational perspective, I want to ensure our dispatchers in each region aren't creating scheduling conflicts when coordinating cross-regional technician assignments.
Specifically, I'm trying to understand:
1. How FieldPulse handles time zone display — is it user-local, or tied to a company default?
2. When a dispatcher in Eastern time schedules a job for a technician in Mountain time, which time zone drives the calendar and notification timing?
3. Are there safeguards to prevent double-booking when the "same" time slot spans different actual hours across zones?
We've identified this as a potential friction point before our January rollout and want to establish clear protocols now rather than troubleshoot in production. Any guidance on current behavior or recommended configuration would be appreciated.
In my experience working with multi-region rollouts, what I typically recommend is starting with a clear mapping document before you touch any configuration. The time zone behavior Priya described has been consistent for the past few releases, but what I see cause friction is when operations teams assume the platform will "intuit" regional boundaries.
What I typically recommend is documenting three things upfront:
1. Your source of truth — company time zone, likely Eastern if that's your headquarters
2. Your display strategy — who needs to see what, and where local time matters for coordination
3. Your escalation path — when a technician is pinged at 6 AM because of a math error, who fixes it and how
I've seen organizations spend more time unwinding scheduling conflicts than they spent on initial setup. One client in particular — similar size to what you're describing, three regions, about 85 field technicians — ended up rebuilding their entire technician availability configuration in month three because they hadn't accounted for how recurring schedules would propagate across the DST boundary. The platform handled the time change correctly, but their availability windows were effectively shifted by an hour for two weeks until they caught it.
From an implementation perspective, there's also a consideration around API integrations if you're pulling scheduling data into another system. The API returns ISO 8601 timestamps with offset, but your receiving system needs to handle that correctly. Worth validating if you have any middleware or custom reporting.
Happy to discuss specifics of your setup if helpful — this is the kind of foundational decision that's painful to reverse later.
In my experience working with multi-region rollouts, what I typically recommend is starting with a clear mapping document before you touch any configuration. The time zone behavior Priya described has been consistent for the past few releases, but what I see cause friction is when operations teams assume the platform will "intuit" regional boundaries.
What I typically recommend is documenting three things upfront:
1. Your source of truth — company time zone, likely Eastern if that's your headquarters
2. Your display strategy — who needs to see what, and where local time matters for coordination
3. Your escalation path — when a technician is pinged at 6 AM because of a math error, who fixes it and how
I've seen organizations spend more time unwinding scheduling conflicts than they spent on initial setup. One client in particular — similar size to what you're describing, three regions, about 85 field technicians — ended up rebuilding their entire technician availability configuration in month three because they hadn't accounted for how recurring schedules would propagate across the DST boundary. The platform handled the time change correctly, but their availability windows were effectively shifted by an hour for two weeks until they caught it.
From an implementation perspective, there's also a consideration around API integrations if you're pulling scheduling data into another system. The API returns ISO 8601 timestamps with offset, but your receiving system needs to handle that correctly. Worth validating if you have any middleware or custom reporting.
Happy to discuss specifics of your setup if helpful — this is the kind of foundational decision that's painful to reverse later.
