Road closure alerts for field teams, before they set off

A field team can hear about road closures before it sets off: a flow checks the roads around each depot, site or job on a timetable, keeps only the closures that are new, and posts them to the team that needs them. Traffic incidents finds closures, roadworks and other incidents on online maps as they are now, each with its kind, street, district and position to about 150 metres.

This article is for operations leads in utilities, telecoms, construction, security and home services who send people out every day. It covers the three ways to look, how to cut the noise, two examples, and when to use a trigger that reacts instead of a timetable.

Three ways to look for closures

• Across an area. Search a city or an area you draw with an Area of interest. Each incident comes back as its own item. A city is about two searches; a large area is cut into parts and searched from the centre, up to eight parts a run.
• Around a point. A circle around one place, such as a single depot or a construction site.
• Around each incoming place. Your own list of sites or today’s jobs. Each one goes on with incidents_nearby (how many are within the radius) and nearest_incident (the closest, its kind and its distance). This is the one most field teams want.

Each incident is a Road closure, Roadworks or an Incident. Accidents are reported as road closures for now, so a closure list catches them too.

Cutting the noise

A city has roadworks every day, and a team that gets the same list each morning soon stops reading it. Three blocks keep the alert short:

1. Filter on incidents_nearby greater than 0, so only sites with something near them go on.
2. Only new after an area search, so each incident is sent once: it keeps the same incident_id while it lasts.
3. A radius that fits the work. 500 metres for a fixed site where access is what matters; 2 km for a depot whose vans need a clear way out.

Example: substations in Manila

A made-up power company in Manila sends crews to substations every day. Its flow runs at 05:30: a Schedule, the substations in a My data table, Traffic incidents around each with a 1 km radius, a Filter on incidents_nearby, and a Slack message per crew channel naming the substation, the closure and how far away it is. On most mornings the channel stays quiet. On a morning with a burst water main, two crews learn before they leave that the usual road is shut and the closure is 640 metres from the gate.

The template Closures near substations for field crews is this flow, ready to adapt.

Example: installation jobs in Berlin

A made-up fibre installer in Berlin has different addresses every day. The jobs arrive as rows in a sheet in Google Sheets; a New rows trigger runs the flow for each new day’s list. Traffic incidents checks within 500 metres of each address, Sort and limit puts the jobs with the most incidents first, and the dispatcher gets one email listing the affected jobs with their nearest closure. The technicians whose jobs are clear hear nothing; the two whose streets have roadworks get a call about where to park.

React instead of polling

For a handful of critical sites, a timetable may be too slow or too noisy. The When something changes trigger can watch for a road closure near up to five sites, checking every 15 minutes, every hour, every 6 hours or once a day, and starts the flow only when a new closure appears. The first check only looks; after that, each new closure runs the flow with the changed item, so the team hears about it once, when it happens.

Closures and speeds together

A closure on a side street may not matter; the same closure on the only road out of a depot does. Traffic Flow adds how the roads around a place are moving right now, including roads_closed and the busiest road. Put it after Traffic incidents and a team sees both: what is shut, and whether traffic is backing up because of it. See road speed, free flow and the jam factor explained.