Make Automation: Refresh Model Inputs and Flag Data Drift

What This Builds

A model is only as good as the data feeding it, and a live model that pulls from a client's shared sheet or database drifts quietly. A column gets renamed, a site stops reporting, a value that should be a percentage shows up as a raw count. This build sets up a Make scenario that refreshes the model's source data on a schedule, runs a light validation pass, and emails a plain-language summary of what changed since the last refresh, including anything that looks wrong, before that bad data ever reaches a client recommendation.

Prerequisites

• Comfortable using ChatGPT or Claude for quick summarization tasks (Level 1-3)
• A live data source your model depends on: a shared Google Sheet, an exported CSV on a schedule, or a database your firm has API access to
• A {{tool:Make.plan}} account ({{tool:Make.price}}) at {{tool:Make.url}}
• An OpenAI or Anthropic API key for the AI summarization step inside Make. This is billed separately, by usage, and typically runs a few dollars a month for a single weekly or daily digest, distinct from a Plus subscription
• Total ongoing cost: {{tool:Make.price}} per month, plus a small usage-based API cost for the summarization step
• A destination for the summary: email or a Slack or Teams channel you actually check

The Concept

Think of this as a data quality inspector who checks the shipment before it leaves the dock, not after it arrives broken. Every time the schedule fires, Make pulls the latest version of your source data, runs a handful of sanity checks (row counts in range, no missing required fields, values inside expected bounds), and asks an AI step to summarize what changed since last time in plain language. You read a two-paragraph email instead of reopening the source file and comparing it to last week's version by eye.

A note on the data this moves: every refresh sends the client's actual operational numbers, demand by site, costs, staffing levels, through Make and out to whichever AI provider you connect. That is real client data leaving your firm's systems on a schedule, unattended. Check your firm's data handling policy before wiring up a live client source this way, and if anything in that data falls under NDA or a stricter confidentiality clause, confirm with whoever owns the client relationship that an automated third-party pipeline is acceptable before turning the schedule on.

Build It Step by Step

Part 1: Define what "normal" looks like for your data source

Before building anything in Make, write down the checks that would catch a bad refresh:

• Expected row count range (for example, 40 stores means expecting 38 to 42 rows)
• Required fields that should never be blank (site ID, weekly demand, unit cost)
• Value ranges that flag an error if breached (unit cost between a plausible low and high, demand within a known band)

Keep this as a short reference document. You will translate it into the Make scenario in Part 3.

Part 2: Connect your data source in Make

1. Create a {{tool:Make.plan}} account at {{tool:Make.url}} if you do not already have one
2. Create a new scenario
3. Add your source as the first module. For a Google Sheet, look for a Google Sheets module with an option like "Search Rows" or "Get a Range of Cells." For a database or API-based source, use the matching module or an HTTP request step
4. Connect your account and select the specific sheet, table, or endpoint your model reads from
5. Set the schedule (the clock icon on the first module): daily or weekly, matching how often your model actually needs fresh data

What you should see: The module returns sample rows from your current source data when you run a test.

Part 3: Add a validation step

1. Add a router or filter module after your data source
2. Configure conditions using the checks from Part 1: row count outside range, required field blank, value outside bounds
3. Route flagged rows or a flagged count into a separate branch that gets called out clearly in the summary instead of silently passing through

Part 4: Add the AI summarization step

1. Add a module for your AI provider (look in Make's app directory for an OpenAI or Anthropic module) and connect your API key
2. Configure a prompt that compares this run's data to the prior run:

You are summarizing a scheduled data refresh for an operations research
model. Compare this refresh to the prior one and write a short summary
in plain language.

Current data: [insert current pull]
Prior data: [insert last saved pull]
Validation flags from this run: [insert any rows or counts that failed
the checks]

Summarize in three parts:
1. What changed since the last refresh (new rows, removed rows, values
   that moved meaningfully)
2. Anything that failed a validation check, stated plainly, do not
   soften or omit a flagged item
3. A one-line verdict: safe to use as-is, or needs review before the
   model runs on it

1. Store the current pull somewhere Make can retrieve it next run, a dedicated tab in the same sheet or a Make data store, so the next run has something to compare against

Part 5: Deliver the summary and save the run

1. Add a final module to send the AI summary by email or to a Slack or Teams channel
2. Save the scenario and turn scheduling on
3. Run it manually once with real data to confirm the whole chain works end to end before letting it run unattended

Real Example: Weekly Staffing Model Refresh

Setup: A workforce scheduling model for a client's 12-site operation pulls weekly demand forecasts from a shared Google Sheet the client's operations team updates every Sunday night.

Scheduled run, Monday 6am: Make pulls the latest sheet, checks that all 12 sites reported a value and that no site's forecast fell outside the expected weekly range, then sends this summary:

"11 of 12 sites reported this week. Site 7 (Riverside) is missing a value, flagged for follow-up. Site 3's forecast jumped from 340 to 610 units, more than double last week and outside the expected range, worth confirming with the client before the model runs. All other sites are within normal range. Verdict: needs review before running the model, due to the Site 3 anomaly and the missing Site 7 value."

Time saved: What used to be a manual weekly comparison against last week's file, roughly 20 to 30 minutes when nothing was wrong and much longer when something needed tracking down, becomes a two-minute read with the anomaly already identified.

Verification: reconcile before you trust it

Do not treat the AI summary as the final word. Once a month, or any week the summary flags something, open the source file yourself and manually reconcile its stated total, total demand across all sites, or whatever your model's key input total is, against the total the summary reports. This catches the case where the AI's summary itself misreads a number, which matters here because the summary's "safe to use" verdict is the thing standing between bad data and a client-facing recommendation.

What to Do When It Breaks

• The scenario stops running and you don't notice → This is the failure you won't see. No email arrives, and unless you are watching for it, a week can pass with no refresh at all. Turn on Make's built-in scenario notifications (under the scenario's Notifications settings) so a failed run sends a separate alert from the summary email, and put a recurring reminder on your own calendar to confirm the last summary actually arrived
• The AI summary misses a real change → This usually means the "prior data" comparison point was not saved correctly on the last run. Check that the data store or comparison tab actually updates after each run, not just the first one
• Validation flags everything, even normal weeks → Your bounds from Part 1 are probably too tight. Widen the range slightly and re-test against two or three weeks of past data you know was fine

Variations

• Simpler version: Skip the AI summarization step and just get an email with the raw validation flags. Faster to build, but you lose the plain-language "what changed" narrative
• Extended version: Add a second branch that automatically blocks the model from running, or clears a "ready" flag in your tracking sheet, when the verdict comes back "needs review," so a bad refresh cannot silently feed into a model run before a human looks at it

What to Do Next

• This week: Build the scenario against one real data source and run it manually before turning on the schedule
• This month: Add the validation checks that matter most for your specific model and tune the value ranges against a few weeks of real data
• Advanced: Connect the output of this refresh directly into the prompt chain's sensitivity analysis step, so a fresh, validated dataset feeds straight into the next report cycle

Advanced guide for Operations Research Analyst professionals. These techniques use more sophisticated AI features that may require paid subscriptions.