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.
Hi Nadia — happy to help with this! Great question as you're scaling across regions.
FieldPulse handles time zones in a specific way that impacts exactly the scenarios you're describing:
**Company Default Time Zone**
Your account has a single company time zone set at Settings → Account Preferences → Time Zone. This drives:
The dispatch board and scheduler display
Internal notification timing
Report date/time stamps
**User Display vs. Stored Time**
Individual users see times converted to their local browser/device time zone, but the underlying data is always stored in company time. This means when your Eastern dispatcher creates a 9:00 AM appointment, a Mountain technician sees it as 7:00 AM — both refer to the same moment.
**Cross-Regional Scheduling**
The scheduler does not currently block bookings based on "business hours" per region. FieldPulse validates against technician availability windows set in their profile, but those windows are interpreted in company time, not local time. So a technician with an 8:00 AM–5:00 PM availability in Mountain time needs their profile configured to 10:00 AM–7:00 PM if your company is Eastern.
**Recommended Protocol**
1. Standardize on a single company time zone (often the headquarters location)
2. Configure technician availability profiles offset for their actual local working hours
3. Train dispatchers to verbalize times with time zone notation when confirming cross-region assignments
Does this align with what you were expecting? I can also connect you with implementation resources if you'd like to review this setup before go-live.
Pro tip from someone who's lived through this: we put the local time in the work order title. Not elegant, but it saved us more than once when dispatchers were looking at a board full of appointments and losing track of which tech was where.
"HVAC install — 7AM MT / 9AM ET" — something like that. Your technicians see their local time in notifications, but dispatchers need the mental anchor.
Another thing: if you're using customer notifications, double-check your templates. The default SMS doesn't include time zone, and customers absolutely notice when you say "technician arriving at 9:00" and they meant their 9:00, not yours.
Josh, that's a pragmatic workaround I hadn't considered. The work order title convention is something we could implement immediately while we evaluate longer-term solutions.
Your point about customer notifications is particularly relevant — we're currently drafting our notification templates for the rollout. I'll flag this with the team configuring those.
...am I missing something or did this get way more complicated than it needs to be?
We just set everything to UTC in the backend and trained everyone to do the math. Dispatchers know: Mountain is -7, Eastern is -4 (or -5 depending on DST). Takes two days and people stop thinking about it.
The "technician availability in company time" thing Priya mentioned is the real gotcha though. Had a guy show up two hours early for six months because nobody caught that.
Ray's not wrong, but UTC training scales poorly past ~15 people. We've got 40+ dispatchers and field techs across four zones.
What actually worked for us:
Dedicated dispatch boards per region (saved views, not separate accounts)
Technician profiles with "local working hours" noted in the bio field as a visible reference
One person who owns the "time zone sanity check" before any multi-region job gets scheduled
The last bullet is the important part. Someone needs to catch it before it becomes a problem.
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.
sorry jumping in late — does this affect the mobile app too??
techs in mountain time see different job times than dispatchers in eastern??
had a call this morning where a guy insisted his phone said 8am and dispatch said 10am and everyone was confused
Hi Teresa — yes, exactly that scenario can happen. The mobile app displays times in the device's local time zone, so a technician with their phone set to Mountain Time will see 8:00 AM while an Eastern dispatcher sees 10:00 AM for the same job. Both are correct — same moment, different display.
What I typically see cause the confusion you described is when someone's device time zone is set incorrectly, or when a technician is traveling across zones and doesn't update their phone settings. The app doesn't "follow" the technician — it follows the device.
Quick check for your team:
Settings → General → Date & Time → Time Zone (iOS)
Settings → Date & Time → Time Zone (Android)
If the technician's phone is still on Eastern from travel, they'll see your company's time instead of local time. That's usually the culprit in "my phone says different" calls.
Want me to send over a quick field guide you can share with your techs?
