Worker Availability and Telemetry

A worker lookup rarely wants every worker in the directory. It wants the people who are on shift, hold the right skills, are responsible for the equipment that raised the alarm, and are near enough to reach it. Connected Field Service builds that shortlist by combining what you have configured about each worker with what the worker's own device reports about them, and it hands the result to the send activities that follow in the workflow.

Everything described here is applied by the Worker Lookup activity in a workflow template, and each part of it is optional. A lookup with no restrictions returns every enabled worker. Each restriction you enable narrows the list, and the location option also orders it. Learn more

Availability

Availability answers whether a worker should be contacted at all right now.

  • Enabled—Disable a worker to remove it from all dynamic worker queries without deleting the record entirely.

  • Enable tag—Instead of a fixed setting, a worker can be enabled by the live value of a data point. This lets availability follow something the system already knows, such as a badge-in reader or a schedule tag maintained elsewhere.

  • Availability schedule—A worker can be linked to a Schedule, together with the schedule state that counts as available. When the lookup applies scheduling restrictions, a worker whose schedule is not in that state is excluded. Workers imported from a maintenance system can instead use the calendar held in that system.

    • Group schedule—A group can carry a schedule of its own. When both the worker and the group have one, the worker is available only if both are available. When only one of the two has a schedule, that one decides. When neither has one, the worker is always available. Learn more

Scheduling restrictions are applied only when Apply scheduling restrictions is selected on the Worker Lookup activity.

Suitability

Suitability answers whether this worker is the right person for this particular alarm.

  • Group membership—The lookup can be limited to named groups. Groups are how you express teams, trades, and shifts. A lookup can name more than one group, and a worker in any of them is returned.

  • Proficiency—Where groups are imported from a maintenance system as skills or characteristics, each worker's membership can carry a proficiency level. A lookup can ask for a group at specific proficiency levels, so that an alarm goes to the people who are actually strong in that skill.

  • Alarm and area assignment—Each worker can be assigned alarms, alarm areas, or a whole alarm server. When the lookup applies alarm source restrictions, only workers assigned to the alarm that triggered the workflow, or to its server, are returned. Alarm area restrictions widen that to workers assigned to the alarm's area or to a parent of it, and can be applied only alongside the source restrictions.

  • Asset assignment—Each worker can be assigned assets. Assignments are inherited down the asset tree, so assigning a worker to a parent asset makes them responsible for everything beneath it.

Telemetry from the Worker's Device

When a worker runs the MobileHMI app and grants worker access to the server, the device reports back to Connected Field Service periodically. That telemetry becomes part of the worker's record and is browsable as GENESIS data:

  • Location—The device's GPS position. This is what makes distance and travel-time ordering possible.

  • Battery level—How much charge the device has left.

  • Signal strength—How well the device is connected.

Because this data is exposed as ordinary GENESIS data points, you can display it, alarm on it, and use it in expressions. A dispatcher display that shows which technicians are reachable, and where they are, is built from these points.

A worker's device reports location only while worker access is enabled in the MobileHMI app. Workers with no reported location are still returned by a lookup that orders by location, but they are placed last, after the farthest known worker.

Proximity

When the lookup is told to order workers by location, it needs to know where the alarm is. You supply that as an expression on the activity—commonly an alarm related value that carries the coordinates of the equipment, or a global alias that resolves to them. The lookup then compares each worker's reported position against it and sorts the list so that the nearest worker is contacted first.

How "nearest" is measured is a setting on the activity:

  • Radius—Straight-line distance between the worker and the alarm. This needs nothing beyond the two positions.

  • Distance—Driving distance along the best route, obtained from Azure Maps.

  • Time—Driving time along the best route, obtained from Azure Maps, optionally taking current traffic into account.

Driving distance and driving time require an Azure Maps account, and the key is supplied to the Connected Field Service Workers Point Manager through an environment variable. Learn more

Layering Filters

The restrictions combine. A lookup that applies group, schedule, and area restrictions and orders by travel time produces the members of that team who are on shift, are responsible for the alarm's area, sorted with the one who can get there soonest first. Add Top count to keep only the first few, and the workflow contacts a short, well-chosen list instead of broadcasting.

What's Next?

Using Dynamic Worker Lists