In this article · 5 sections
Procore and Google Calendar are where a lightning window turns into a changed plan: a crane lift moved, a pour rescheduled, a practice pushed back. This is a planning guide for connecting both to Flash Agent: the decisions to make before you switch them on, what each one writes, and how to read the record afterwards.
Before you start
Flash Agent is included in the Portfolio and Enterprise plans, and single-site plans can add it. Each connector is one line per tenant, with its own permissions and its own audit log, and it is switched on per site with its own scope. So the work is mostly deciding, site by site, what you want the agent to see and touch.
- Which sites get which connector. A jobsite may need Procore and not Calendar; an athletics site the reverse.
- Which calendars and which project schedule belong to each site, so the agent reads the right ones.
- Who confirms changes for each site, and where: Slack, Teams, SMS or the Flash app.
- The policies the agent should answer against, such as your lightning radius or WBGT bands, which Flash keeps per site.
Procore: what it reads and what it may change
- Reads
- The project schedule and the daily log for the site.
- Proposes
- Moving crane lifts and pours out of a lightning or weather window, writing the weather delay to the daily log, and texting the foreman.
- Confirmation
- Every schedule change waits for a person before it is made.
In the illustrative example on the Lightning Prediction page, a superintendent with 12 sites asks which one has a crane lift inside a lightning window this week. The answer names one site and one afternoon, the lift is rescheduled in Procore, the foreman is texted, and the answer cites the cell and the model run it came from.
Google Calendar: what it reads and what it may change
- Reads
- Events on the site’s calendars.
- Proposes
- Moving or shortening events inside a risk window, with a note telling attendees why.
- Confirmation
- Every event change waits for a person before it is made.
For athletics, this is how a practice moves when the forecast crosses your limit: the agent prepares the new time, the trainers are told, and the change sits as "waiting for a person" until a coach confirms.
Waiting for a person
Nothing on the calendar moves until someone confirms it.
Reading the log afterwards
Every Flash Agent action is logged with four things: who asked, what was read, what changed and who confirmed it. Each answer behind an action also carries the 1×1 km cell id and the model run time, so a reviewer can check the decision against the map and the accuracy method.
- Start from the change: the lift, pour or event that moved.
- Check the cell and run: was the decision made on the forecast for that site, and how recent was the run?
- Check the confirmation: who approved it, where and when.
- Read it alongside the alert log, which records who was warned, when, and when work or play resumed.
Portfolio plans include a portfolio-wide audit log and exports, so the same record can go into a safety file or a season review. Turning a connector off removes the agent’s access immediately; the log keeps the history.
Frequently asked
No. It can propose moving lifts and pours, logging the delay and texting the foreman, but every schedule change waits for a person to confirm it, and the confirmation is logged.
It reads events on the site’s calendars and proposes moving or shortening those inside a risk window, with a note to attendees explaining why. Each change waits for a person.
Flash Agent is included in the Portfolio and Enterprise plans, and single-site plans can add it. Each connector is one line per tenant with its own permissions and audit log.