Use “Tell the customer a visit is weather-held” in Recued. Records watcher for visits that move to weatherhold. Re-reads the visit and its site, mails the customer once, and stamps notifiedat.
Tell the customer a visit is weather-held
Use “Tell the customer a visit is weather-held” in Recued. Records watcher for visits that move to weatherhold. Re-reads the visit and its site, mails the customer once, and stamps notifiedat.
Complete workflow
Field Service Day Plan
7 pinned recipes
Use Field Service Day Plan in Recued for weather, geocoding, scheduling, and records. It includes 16 built-in actions and 5 ready-to-run workflows. Actions that change data use Recued's approval controls.
You are viewing one recipe in this workflow. Installing it opens the complete pack so its other recipes and background automations arrive together.
Use “Add a service site” in Recued. Geocode one service address once and store its coordinates.
Use “Schedule a site visit” in Recued. Book one visit to an existing site on a date and time window. The visit is keyed on site, date and window start, so re-running the same booking converges on the same row instead of double-booking the slot.
Use “Plan today's service day” in Recued. Reads today's visits, fetches the forecast at each weather-sensitive site's stored coordinates, and records a verdict on every visit — holding the ones the weather will not allow and releasing the ones it will.
Use “Show the day plan” in Recued. Reads one day's visits in window order and shows each with its site, work, weather verdict and status. It reads information without changing data in the connected service.
Use “Close a site visit” in Recued. Mark one visit done or skipped, with an optional note.
Show all 7 recipes
Use “Records runtime” in Recued. It helps you complete this workflow using the connections and settings you choose.
When it fires
On any update to a visit row. It sends only when ALL of these hold:
- status is
weather_hold notified_atis empty — the customer has not already been told- the site has a
customer_emailAND asender_mail_instance
A site missing either mail field is silently never mailed. That is deliberate: this pack will not pick a sending account for you.
⛔ notified_at is the dedup, not a cursor. Reactive runs have no backed context.recipe.* state, so anything keyed on "what did I do last time" would resolve empty on every tick and mail the customer on every update. The only durable record of "already told" is the stamp on the row, which is why the guard reads it and the last step writes it.
⚠ This recipe updates the row it watches, so it re-fires itself exactly once. The second fire finds notified_at set and stops at the guard. That is the intended shape, not a loop.
⚠ Once notified, the hold will not lift by itself. plan-service-day deliberately refuses to reinstate a visit whose customer was already told the work is off, even if the forecast improves. Reinstating it is your call.
Delivery is converged, not exactly-once. The mail carries a reconciliation id keyed on the visit, so a retry after a crash converges on one message rather than claiming provider-level exactly-once delivery.
How it works
Inspect the data fetches, transforms, gates, and output this recipe runs.
Process (16 steps)
visit
?
is_held
compare
Check if visit record status equals weather_hold
already_notified
compare
Check if visit record notified at has data
should_consider
all
Check if all conditions are true
consider_guard
guard
Stop if should consider equals
site_id
replace
Replace text in visit record site ref
site
?
mailable
all
Check if all conditions are true
mailable_guard
guard
Stop if mailable equals
reconciliation
template
Generate text from a template
subject
template
Generate text from a template
body
template
Generate text from a template
send
?
notified_at
date_add
Add 0 seconds to
stamp
?
card
to_summary
Format results as a summary card