ServiceWorks is a full capacity-based scheduling platform, while ServicePower is a dispatch eligibility system. Because of this, ServiceWorks does not simply “sync your schedule.” Instead, it safely translates your schedule into the limited availability signals that ServicePower understands.
This document explains exactly:
• what we send to ServicePower
• when we send it
• what we intentionally do NOT send.
ServiceWorks synchronizes availability to ServicePower in two ways:
- Nightly configuration sync (Process – once a day)
- Real-time exception sync (Time off / block tech)
ServicePower is built around a model where technicians are available by default (per Tech+Zone, day-of-week, and time band) until an exception makes them unavailable.
1) Nightly Updates (Process – once a day)
These items are updated nightly.
A. Technician (Tech) updates
Add Technician (ServicePower)
ServicePower allows only one zone per technician record. Because a ServiceWorks technician may work in multiple zones, ServiceWorks creates a separate technician entry in ServicePower for each zone the technician is assigned to.
When a technician is given capacity in a new zone in ServiceWorks, we automatically create a corresponding TechZone technician in ServicePower and apply the appropriate default availability for that zone.
The technician identifier (key) sent to ServicePower is constructed as:
TechName (no spaces or special characters) + ZoneName
This combined name must be 65 characters or fewer to meet ServicePower’s limitation.
Example:
Technician: Steve Jobs
Zone: Missouri
ServicePower Tech Name: SteveJobsMissouri
Update Technician (ServicePower)
When the capacity or default availability for an existing TechZone (technician + zone combination) is changed in ServiceWorks, ServiceWorks sends the updated availability settings to ServicePower.
If a technician’s display name is edited in ServiceWorks, the name change is not pushed to ServicePower. The relationship between ServiceWorks and ServicePower is tied to the TechKey, which is constructed as: TechName + ZoneName
Because this key identifies the technician record in ServicePower, changing the technician’s name does not rename the existing ServicePower technician entry.
Known Issue — Technician Name (ServicePower)
When technician information is transmitted through the ServicePower API, the last name field is not supported. As a result, technicians created or updated in ServicePower will appear without a last name.
If you notice a technician record missing the last name in ServicePower, this is expected behavior and not a ServiceWorks issue.
Delete Technician (ServicePower)
ServicePower does not support deleting a technician via API. Therefore, if a TechZone (technician + zone combination) is removed in ServiceWorks, no deletion request is sent to ServicePower.
Additionally, ServiceWorks does not send a “0 capacity” update as a substitute for deletion, since setting capacity to zero could stop dispatching for that technician.
Note: Nightly tech processing includes checking created/updated timestamps to determine what changed.
B. Zone / Route & ZIP coverage updates
What we update nightly
Add Zone (ServicePower)
When a new zone with ZIP code coverage is created in ServiceWorks, a corresponding Area is created in ServicePower. (A ServiceWorks Zone is equivalent to a ServicePower Area.)
In ServicePower, every Area must belong to a Group. Because ServicePower does not provide an API to create groups, if the new zone belongs to a brand-new group, the group must first be created manually in ServicePower before the zone can be fully associated.
Update Zone/Route (Name Only) — ServicePower
If the zone name is changed in ServiceWorks (for example, from “TX” to “Texas”), ServiceWorks will update the corresponding Area name in ServicePower.
However, the existing TechZone technician names in ServicePower will not be renamed as part of this update, since those technician records are tied to their original TechKey.
Add ZIP Code — ServicePower
When new ZIP codes are added to an existing zone in ServiceWorks, those ZIP codes are automatically transmitted to the corresponding Area in ServicePower.
Delete ZIP Code — ServicePower
When existing ZIP codes are removed from a zone in ServiceWorks, those ZIP codes are also removed from the corresponding Area in ServicePower.
What we do NOT update
Delete Zone/Route — ServicePower
ServicePower does not provide an API to delete an Area (zone). Therefore, if you no longer service a zone, it must be removed manually directly within ServicePower.
C. Groups
ServiceWorks Groups are not used by ServicePower as a dispatch structure. The two systems organize coverage differently:
- In ServicePower, a Group can contain multiple Areas, but a technician can belong to only one Group.
- In ServiceWorks, a Group can contain multiple Zones, and technicians may work in multiple zones.
Because of this difference, ServiceWorks requires a separate ServicePower group for each zone. In practice, the Group name in ServicePower should match the Zone name in ServiceWorks.
ServicePower does not provide an API to create groups, so each required group must be created manually in ServicePower before the corresponding zone (Area) can be fully associated. Please make sure you check corresponding relevant boxes in ServicePower,
The group key is created from the group name without spaces or special characters.
Example:
Zone: TX – Bastrop ATX
ServicePower Group Key: TXBastropATX
What we update nightly
- Update group → YES (limited / mapping support)
What we do NOT update
- Add group → NO
- Delete group → NO
D. Default Availability (Tech availability by zone)
This is the key area. ServiceWorks will send availability to ServicePower for each TechZone for Mon, Tues, Wed, etc.
ServiceWorks can sync the default availability setup for dispatch technicians by zone. So for ServicePower make sure in Capacity board the capacity for every tech is set for all time bands for all zones they service.
Important protection rule
- For ServicePower, we do NOT send “0 capacity” as part of default availability updates. If any tech capacity is set to 0, we SKIP those update.
This is intentional because 0 capacity is a dangerous state (it can stop dispatching).
So we allow updating default availability structure, but we protect against pushing a “shutoff” value through the nightly job.
2) Real-Time Updates (Operational)
Tech Time Off / Block Tech (Real-time)
When a technician is blocked or takes time off in ServiceWorks, ServiceWorks sends a Tech Exception to ServicePower.
What we update in real time
- Time off management / Block tech → Tech Exception (real-time)
This is how you enforce “available until they are not”:
- Default availability says they’re available (by day/time band)
- Tech Exception temporarily overrides availability for specific dates/times
What We Do NOT Push to ServicePower (Summary)
ServiceWorks intentionally does not push:
- Delete Tech
- Delete zone/route
- Add/Delete group (and only limited group update support)
- Default availability updates that set capacity to 0 (protective restriction)
- Any “bulk overwrite” behavior that could inadvertently shut off dispatching
Simple Timeline Summary
Nightly (Process – once a day)
- Add/Update Tech (with TechZoneName rules)
- Add/Update Zone/Route (name updates)
- Add/Delete ZIPs
- Add/Update Default Availability (by TechZoneName, with no 0-capacity push)
- Limited Group update support
Real-time
- Time off / Block tech → Tech Exception
