Automate your Monday

It’s 8:47 on a Monday. Someone is exporting last week’s numbers, pasting them into slides, fixing a broken chart, and racing to post “the weekly update” before the 9:00 stand-up. By the time it lands, it’s already an artifact of the past — and the first question in the channel is one the slides can’t answer.

That whole ritual is three Ronja pieces snapped together: a Workflow that builds the briefing, an Automation that runs it every Monday, and a bridge so the follow-up conversation happens in Slack or Microsoft Teams, where your team already is. You set up the first two by asking; an admin connects the bridge once. Here’s the pattern.

Part one: the briefing that writes itself

Open an exploration in Build mode and describe the report you keep making by hand:

“Create a report workflow that summarizes last week’s revenue, new deals, and churn, with week-over-week changes.”

Ronja writes it as a report-kind workflow — a real, versioned job, not a one-off script. She test-runs it in the chat so you can inspect the output before committing, and once it’s live, every run produces the report as a rendered page you open in the browser, with downloadable formats alongside. The tables it reads are declared on the workflow’s page as Inputs, so nobody has to reverse-engineer where the numbers come from.

One detail that saves a future argument: the reporting timezone. When the job runs and which timezone its weeks and months are grouped in are two separate settings on the automation — so a briefing scheduled in UTC can still bucket the week the way your business does.

Part two: the schedule

One more sentence: “Run it every Monday at 7.”

Ronja creates an Automation: a Schedule trigger paired with the workflow as its action. (If the briefing lives in a shared feature, creating the automation is an admin’s move — automations have no review path, so ask an admin.) She can fire a test run before enabling it, so Monday’s first real run isn’t a leap of faith. From then on the briefing exists by 7:00 whether or not anyone is awake — and the machinery around it is what elevates this above a cron job:

Run history. The Automations page shows each automation with its recent-runs sparkline and next run time; the sidebar shows the last 30 runs and lets you open any run’s record.
Failure alerts. Enable the Automation run failed notification and a broken Monday emails your admins at 7:01 instead of surfacing as an awkward silence at 9:00. (An admin routes notifications once, on the Notifications page.)
Traces. Every fire leaves an execution trace — trigger, workflow run, and every step, on one timeline showing exactly where the time went.
Run now. Board meeting moved to Thursday? Fire the same briefing on demand.

Two variants worth knowing:

Trigger on the data, not the clock. A Table trigger fires the automation when a watched table finishes rebuilding — so if your weekend sync is sometimes late, the briefing waits for fresh data instead of reporting on Friday’s.
A briefing that thinks. Swap the workflow for a Saved Agent action and Monday’s run is an agent actually analyzing the week — and each run produces a conversation you can open from the run history (Open chat) and read like a written briefing.

Part three: where Monday actually happens

The briefing is built. But Monday isn’t a document — it’s the conversation about the document. That’s what bridges are for.

An admin connects Slack or installs the Microsoft Teams app once, then bridges the channel where the briefing lands — either by inviting @Ronja into it or with Add bridge on the Bridges page. From then on, Ronja is present where the discussion already lives.

Someone reads the briefing and asks, right in the channel: “@Ronja why did EMEA dip last week?” She acknowledges with On it…, works the question against the same governed data the briefing came from, and answers in a thread — with clickable links back to the underlying tables in Ronja for anyone who wants to go deeper. Follow-up questions inside that thread don’t need another mention; once it’s her thread, she keeps answering.

And when the conversation turns from asking to changing — “can we add a churn-by-segment section?” — Ronja doesn’t try to rebuild a workflow from inside a chat channel. She replies with a button that deep-links into a fresh exploration in the Ronja app, pre-briefed with the request. Analysis happens where the team talks; building happens where changes are drafted, reviewed, and versioned. (Microsoft Teams support is newer and a little narrower: public channels need an @-mention, and private channels aren’t supported yet.)

What Monday looks like now

7:00 — the automation fires; the briefing builds itself from the weekend’s data, in your reporting timezone. 7:01 — if anything failed, the admins already know. 9:00 — the team reads current numbers, and the questions start in the channel, answered in threads with receipts. 9:15 — the one good idea from the discussion becomes next week’s improvement, drafted in an exploration and reviewed before it ships.

The pattern generalizes past Monday: a daily data-quality check, a briefing that fires the moment month-end data lands, a per-team digest on each team’s own schedule. Each one is the same three pieces — build the job, schedule the trigger, meet the conversation where it lives — and each one comes with run history, traces, and review gates for free. If the job needs data no connector covers, Ronja builds that integration too.

The person who used to spend Monday morning assembling the update? They still open the briefing first thing. Now it’s to ask the interesting question, not to build the answer.