When a New Gemini Feature Hasn't Reached Your Workspace, Here's How to Tell Waiting From Broken

On the morning of September 1st I opened a Google Sheet looking for canvas. It wasn't there. I checked the menus, tried a second spreadsheet, and still found nothing.

The feature had been announced the day before, on August 31st, as "starting to roll out." I spent about fifteen minutes poking at admin console settings before I stopped. That turned out to be the right place to stop, because nothing was wrong. Not seeing it yet was the expected state.

As an indie developer who is also his own Workspace admin, the settings I was about to change were my own, which is exactly why it's so easy to start changing them. Repeating that fifteen minutes every time a feature is announced got old quickly, so I built something small that just counts days for me. Looking back, what cost me the time wasn't missing knowledge. It was that the same symptom — "it isn't there" — means opposite things depending on the rollout pace, and I couldn't recall which case I was in while standing in front of the screen.

"Rolling out" is a start date, not an arrival date

A Workspace release note carries three pieces of information that are easy to blur together. Reading them separately is most of the diagnosis.

The first is edition availability. If your plan isn't in the list, waiting will never help.

The second is the release track. Your domain is set to either Rapid Release or Scheduled Release, and the announcement gives a separate start date for each. Scheduled Release domains typically begin about two weeks after Rapid Release. You're reading one announcement, but only one of those dates applies to you.

The third is rollout pace, which describes how long it takes to reach everyone once the rollout begins. Announcements use one of three phrasings.

Sheets canvas began rolling out to Scheduled Release domains on August 31st over a period of up to 15 days. So on September 1st, not seeing it isn't an anomaly at all.

One more thing worth internalizing: rollouts progress user by user. A colleague in the same organization seeing the feature while you don't is normal mid-rollout. If you read that as "my account is broken," you start changing settings and manufacturing a real problem on top of an imaginary one. That's exactly the edge I was standing on for those fifteen minutes.

Five checks, in order

The order matters. Work down the list and stop at the first thing that fails — that's your answer.

1. Edition — Confirm your subscription appears in the announcement's availability list. If it doesn't, you're done here.
2. Your domain's release track — Check it in the admin console. Menu labels get reorganized, so typing "release" into the console's search box is more reliable than navigating by memory. If you're on a personal Google account waiting for a Workspace feature, this step is also where that becomes clear.
3. The start date for your track — Rapid and Scheduled have different dates. Read only the one that applies to you.
4. Admin-side switches — Whether the app is on, alpha and additional service settings, and any DLP or label-based restrictions on data access. If you've restricted what Gemini can reach, the feature can be fully present and still come up empty. I worked through what Drive-side restrictions actually change in Before You Unshare a Drive File, There Is a Setting That Already Keeps Gemini Out.
5. User-side conditions — Display language, whether you're signed in with the work account, and whether you've signed out and back in. Only now does it make sense to suspect cache or browser extensions.

If steps 1 through 3 tell you the window is still open, don't touch steps 4 and 5. Changing settings while hunting for a feature that hasn't arrived leaves you with a problem whose cause you won't recognize once the feature does land.

A ledger that counts the waiting period for you

Doing that date arithmetic in your head for every announcement doesn't last. I put three input columns in a spreadsheet and let a script fill in the deadline and the remaining days.

Name the sheet rollout. Column A holds the feature name, column B the start date for your track, and column C the rollout pace. The script writes columns D onward.

// Workspace rollout ledger
// A=feature / B=start date for your track (YYYY-MM-DD) / C=pace (full|gradual|extended)
// D=deadline (written) / E=days remaining (written) / F=verdict (written)
 
const PACE_DAYS = { full: 3, gradual: 15, extended: 30 };
const SHEET_NAME = 'rollout';
 
function updateRolloutLedger() {
  const sheet = SpreadsheetApp.getActive().getSheetByName(SHEET_NAME);
  if (!sheet) {
    throw new Error('Sheet "' + SHEET_NAME + '" not found');
  }
 
  const lastRow = sheet.getLastRow();
  if (lastRow < 2) return; // header row only
 
  const rows = sheet.getRange(2, 1, lastRow - 1, 3).getValues();
  const today = truncateToDay(new Date());
  const out = [];
 
  for (const [name, rawStart, rawPace] of rows) {
    if (!name) {
      out.push(['', '', '']); // leave blank rows alone
      continue;
    }
 
    const start = parseDate(rawStart);
    const pace = String(rawPace || '').trim().toLowerCase();
    const span = PACE_DAYS[pace];
 
    if (!start || span === undefined) {
      // Writing '' here would be indistinguishable from "not processed yet"
      out.push(['', '', 'check input']);
      continue;
    }
 
    const deadline = addDays(start, span);
    const remain = Math.round((deadline - today) / 86400000);
    out.push([deadline, remain, remain >= 0 ? 'waiting' : 'investigate']);
  }
 
  sheet.getRange(2, 4, out.length, 3).setValues(out);
  sheet.getRange(2, 4, out.length, 1).setNumberFormat('yyyy-mm-dd');
}
 
// Accepts both strings and Date values; returns null so the caller can branch
function parseDate(value) {
  if (value instanceof Date) return truncateToDay(value);
  const m = String(value || '').match(/^(\d{4})-(\d{2})-(\d{2})$/);
  if (!m) return null;
  return new Date(Number(m[1]), Number(m[2]) - 1, Number(m[3]));
}
 
// Drop the time component, or "days remaining" shifts with the run time
function truncateToDay(d) {
  return new Date(d.getFullYear(), d.getMonth(), d.getDate());
}
 
function addDays(d, n) {
  return new Date(d.getFullYear(), d.getMonth(), d.getDate() + n);
}

Run updateRolloutLedger once from the editor to authorize it, then attach a daily time-driven trigger. Opening the sheet in the morning, I only need to look at rows whose verdict flipped to investigate.

truncateToDay looks like a function you could skip. Skip it and the remaining-days figure drifts by a day depending on when the trigger fires. There's no reason to carry a time component when you only care about dates.

What running the logic actually taught me

I ran it against dates pulled from real announcements, with September 1st, 2026 as the reference day.

Seeing them side by side is what made it click. "It isn't there" means the opposite thing for a full rollout than it does for a gradual one.

For something like Ask Gemini in Chat, which reaches everyone within one to three days, still not seeing it a week later is a problem to investigate, not a wait. Conversely, suspecting a gradual rollout after three days is just impatience. My instinct to start clicking around in the admin console came from feeling that the feature "should" have arrived by now. Instinct doesn't factor in rollout pace.

The boundary day was another decision I made only after running it. The deadline day itself counts as waiting; investigation starts the day after. Flipping the verdict on the deadline day throws away a full day of legitimate grace.

Returning check input instead of a blank cell for unparseable rows was also a post-run fix. With blanks, I couldn't tell a row the script hadn't processed from a row whose date format got rejected. I lost time chasing a row I'd typed as 2026/8/1, which failed silently until I changed this.

When the deadline passes, what to send

Once a row flips to investigate and all five checks pass with the feature still missing, it's time to contact your admin or reseller. "It doesn't work" produces a long back-and-forth. Handing over everything up front is faster.

• The release note URL and its date
• Your domain's release track (Rapid or Scheduled)
• The start date for that track and the number of days elapsed
• Your subscription edition
• Admin settings you've already verified (app on/off, DLP or label restrictions)
• Reproduction steps and a screenshot of the actual screen

With the ledger in place, items two through four are a straight copy-paste. Not having to re-derive them for the support thread turned out to matter more than I expected.

Once canvas does arrive, the question shifts to how much of a workflow belongs in canvas and where Apps Script has to stay. I wrote up where I draw that line in Sheets canvas Takes the Entry Point, Not the Execution Boundary. It's a good thing to read while you're waiting.

Wrapping up

Next time an announced feature doesn't show up, go back to the release note before you touch a single setting, and read exactly two things: the start date for your track, and the rollout pace. Those two decide whether you wait or investigate.

Whether the ledger is worth building depends on how many features you're tracking. I only wrote it once I was following several a month.