What it says
What this says
As at Fri 9 Oct 2026Final platform release notes by Martin Sobczak, published 20 Jul 2026. Release four-twelve moves the nightly refresh to incremental loading. Service levels, tiers and connector limits are stated as unchanged, with the refresh complete by 07:00 customer local time on business days.
What it is: BG-Demo's internal release notes for customers, owned by Martin Sobczak and published 20 Jul 2026. The release went live at 18:30 on Monday 20 July 2026 and changes how the nightly refresh loads data: "now works incrementally rather than reloading everything it can reach".
Commits: it restates the existing target, "complete by 07:00 customer local time on business days, as for every tier". It also says "Service levels are unchanged, including availability and the nightly refresh target."
Unusual: load ordering across connectors is now decided by the scheduler, and a large first incremental pass on a long-history connector may take longer. The notes say failed-load reporting is unchanged, so a changed source still needs attention.
Not settled: it names no customers, gives no figures on refresh duration and sets no new service credit. It does not say how flat records indexed will be spotted beyond asking customers to raise a ticket.
As found in this document
As at Fri 9 Oct 2026- Date start20 Jul 2026Source: the AI read of this record
- Nightly refresh targetcomplete by 07:00 customer local time on business days, as for every tierSource: the AI read of this record
- Service levelsService levels are unchanged, including availability and the nightly refresh target.Source: the AI read of this record
- Tiers, allowances and connector limitsunchangedSource: the AI read of this record
The document
Body
BG-Demo - Release Notes
Status: Final Document owner: Martin Sobczak, Senior Product Manager Published: 20 Jul 2026
Release four-twelve at a glance
Release four-twelve goes live this evening, Monday 20 July 2026, at 18:30. It is a platform release: the headline change is to the way the nightly refresh loads data from connected systems. There are no new screens and nothing to learn on the customer side.
If you only read one paragraph: the scheduler that decides what to load each night now works incrementally rather than reloading everything it can reach. In normal running you should not notice anything except, we hope, a steadier refresh.
What changed
Incremental-load scheduler
Read the whole document (3,956 characters)
- The nightly refresh scheduler now plans each connector's load as an incremental load. It picks up what has changed in the source since the last successful load instead of treating every run as a full pass.
- The scheduler keeps its own record of the last completed load for each connector, so a connector that was skipped or failed on one night is picked up on the next.
- Load ordering across connectors is decided by the scheduler. Where a customer has several connectors, the order of loading may differ from previous releases.
- The aim is a refresh that finishes inside the usual window: complete by 07:00 customer local time on business days, as for every tier.
Why we made the change
Several customers have connected more systems over the past months, and the full-pass approach was spending time re-reading data that had not moved. Incremental loading is how we keep the refresh inside its window as connector counts grow. This was the problem we were trying to solve: teams asking the brain a question first thing and getting an answer that reflects yesterday's close of business.
What you should expect
- Records indexed should continue to rise in the normal way after each business day. If a connector's records indexed stay flat for several days, tell us. That usually points to a source that has changed rather than a quiet source.
- Answers in chat, search and pages draw on the same data as before. Nothing about permissions, connectors or configuration has changed.
- Dashboards built in the Growth and Enterprise dashboards builder are unaffected.
- First morning after release. The first refresh under the new scheduler is the one to watch. We will be watching it too.
What has not changed
- Tiers, allowances and connector limits are unchanged.
- Service levels are unchanged, including availability and the nightly refresh target.
- Data stays inside the customer's own Snowflake account. The scheduler change affects when and how much is loaded, not where it is stored.
Known points
- Because load ordering is now decided by the scheduler, a very large first incremental pass on a connector with a long history may take longer than later passes. We would rather say so now than have it surprise anyone.
- We have not changed how a connector reports a failed load. If a source system has been altered on your side, for example a renamed field or a changed permission, the connector will still need attention in the usual way.
If something looks wrong
Raise a ticket in the helpdesk in the normal way and say which connector and which morning. A short note is plenty. Please include what you were expecting to see, for example "the latest calls were not there when we opened the brain". It is much easier for the platform team to work from what you saw than from a guess at the cause.
We will log anything that looks like a request for a different behaviour from the refresh. That is not planned yet, but it is useful to hear what you are trying to get done.
Questions
Ask your customer success manager in the first instance. They can bring me in if the question is about how the scheduler behaves or about something you would like the brain to do.
Best, Martin
Unusual terms
As at Fri 9 Oct 2026- Scheduler decides connector load ordering
- Large first incremental pass may take longer