• Replies 19 replies
  • Subscribers 2 subscribers
  • Views 25 views
  • Users 0 members are here
Options
Related

Anyone managing a team across multiple time zones in FieldPulse?

Marcus Webb (Staff)

We are exploring how distributed field service organizations are navigating the complexities of multi-timezone operations within FieldPulse. This is an area where we see significant growth in customer needs, and your insights directly inform our roadmap.

Key Questions for the Community

  • How are you currently configuring technician availability across time zones?
  • What friction points have you encountered with dispatch scheduling when your team spans regions?
  • Are you leveraging any integrations or workflows to streamline coordination across boundaries?
  • How do you handle customer-facing communications (SMS, email) when appointment windows may shift relative to local time?

We have observed that organizations with 15+ technicians distributed across three or more time zones often develop sophisticated operational patterns. Your real-world experiences will help us unlock more seamless multi-timezone capabilities.

Please share your current approach — whether polished or works-in-progress. We are particularly interested in edge cases that have required creative problem-solving.

Thank you in advance for your contributions to this discussion.

  • Quick addition on the technical side — we've had success with a lightweight middleware approach:

    • Zapier catches new job creation
    • Custom Python script (hosted on AWS Lambda) converts timestamps based on geofenced technician location
    • Updated times write back to a custom field

    Setup took about 4 hours. Maintenance is minimal. YMMV if you're not already using the API.

    Happy to share the Lambda code if anyone wants it.

  • in reply to Sylvia Chen

    Sylvia — heads up, we've seen rate limiting issues with that write-back pattern if you're creating more than ~200 jobs daily. Worth batching the updates or using the bulk API endpoint instead.

    Also worth noting: the webhook payload doesn't include the technician's timezone, so you're probably geocoding from address or user profile. Make sure you're handling technicians who live in one zone but work another — we hit that edge case and it threw off our conversions.

    Still a solid approach though. The 4-hour setup is realistic if you've done Lambda before.

  • This shouldn't require middleware in 2025.

  • in reply to Mike Dolan

    Sorry if this is a silly question, but I'm new to FieldPulse and trying to follow along — when you say "middleware" do you mean like a separate program that sits between FieldPulse and something else? And is the Lambda thing something we'd need a developer for, or could our IT person handle it?

    We're a smaller company (8 techs, just in two time zones so far) and I'm trying to figure out if this discussion is relevant to us or if we should wait for the native feature. I don't want to waste anyone's time if this is over our heads!

    Thanks in advance for any guidance — I really appreciate how generous everyone is with their knowledge here.

  • in reply to Lindsey Park

    Lindsey — with 8 techs in 2 zones, skip the middleware. Manual conversion or the job-title trick Ray mentioned will serve you fine until native support ships.

    Lambda = requires developer. Not worth the overhead at your scale.

  • so i've been doing this basically since we expanded to denver and honestly the thing that messed me up most was not the time zones themselves but like the way fieldpulse handles "end of day" for reporting

    so basically we have techs in denver and chicago and when they both mark jobs complete on the same calendar day, the report groups them differently depending on which server's midnight hit first or something? i never fully understood it but basically our "jobs completed today" number was always wrong until we realized we needed to run reports at like 2am chicago time to catch both zones

    not sure if this helps anyone but that was the gotcha that took us longest to figure out

  • in reply to Connor Burke

    Connor — this is exactly the edge case we encountered. We resolved it by standardizing report generation on a single timezone (ET in our case) and accepting that "today" means "today in ET" for all operational purposes. Field technicians understand this; finance and leadership require the consistency.

    The 2 AM report run you describe is functionally similar, just with a different reference point.

  • anyone else having issues with the mobile app showing wrong times after the 3.3 update. my tech in phoenix says his schedule is off by an hour now. was fine before

    is this related or separate bug

  • in reply to Teresa Lund

    Teresa — this appears to be a separate issue. The Settings > Timezone configuration in the mobile app now respects device location by default, which can override the user profile setting in certain conditions.

    Please advise your technician to:

    1. Open FieldPulse > Settings > General
    2. Toggle "Use Device Timezone" to Off
    3. Verify the "Timezone" dropdown displays America/Phoenix

    If the issue persists after these steps, please open a support ticket with the technician's device model and app version (visible in Settings > About).