Drive connector: indexed object count identical after full reconnect, is the allowlist applied??

[Fran _Administración_]

Hi all,

I'm trying to scope the Rovo Google Drive connector to a single shared drive, and after several days I can't tell whether the allowlist is being applied at all. I'd appreciate a sanity check from anyone who has this working.

**Goal**

A Rovo agent that answers only from the documents in one Google shared drive ("Integración - Documentación"). Nothing else from Drive should be indexed.

**Setup**

- Google Drive connector added by a Workspace admin account, with domain-wide delegation.
- Allowlist: one entry, the shared drive root URL (ID starting with 0A...). Verified it's the drive root, not a subfolder — an earlier subfolder URL was correctly rejected with "folder does not exist in any shared drive you have access to".
- Blocklist, date filter, group inclusion/exclusion: all unconfigured.
- "Allow personal drives" toggle: OFF. The "Review included content" summary confirms "Shared drives: 1 location included in the allowlist" and "My Drive: not included".
- The org has only 2 shared drives in total.

**Verified contents of the allowlisted drive**

Using the Drive API with the same admin account that the connector delegates to:

- 147 total items: 124 files + 23 folders
- Of those files, 22 are of types the connector documents as indexable (3 PDFs + 19 CSVs)
- Expected indexed object count: roughly 45

**What actually happens**

- Day 1, right after fixing the allowlist: 26,082 indexed objects
- Day 2: 26,217 — it went UP, not down
- Days 3-4: still 26,217, unchanged
- I then deleted the connector entirely and created a new one from scratch. After the initial indexing spinner finished, the count is again exactly 26,217 — byte-identical to the previous connector's figure.

That last point is what I can't explain. A brand-new connector landing on the exact same number as the deleted one suggests either the count is cached org-level telemetry rather than the connector's real state, or the previous index was never purged on disconnect.

**Questions**

1. Is the allowlist actually enforced for Google Drive today? I found AI-1226 ("Create Allowlists for Rovo Google Drive ingestion"), which is still in Gathering Interest and states there is no known workaround — yet the admin UI does show a working allowlist tab that accepts drive, folder and file URLs. Has this shipped, or is the UI ahead of the engine?

2. How often does the "indexed objects" counter refresh, and does it survive a connector being deleted and recreated? If it's cached, it's very hard to verify any scoping change.

3. What does the green "Sync in progress" label mean exactly? It appears permanently with grey and green color depends of the moment. Is it a status badge (sync enabled) rather than a progress indicator?

4. If the allowlist isn't enforced yet, is the blocklist the recommended approach — i.e. explicitly blocking every other shared drive?

Thanks in advance for any pointers.

[Jovânio Junior]

Hi,

Based on the current Atlassian documentation, I think there are two separate things happening here.

First, Google Drive allowlists are supported today for Shared Drives. Atlassian’s current documentation explicitly says that an allowlist can limit what is indexed from Google Drive, and that only Shared Drive root URLs are supported — not individual folders or files.

So your configuration of:

Allowlist = one Shared Drive root
My Drive = excluded

is aligned with the current supported model.

The confusing part is AI-1226. That ticket still says allowlists are not available, but it was created in 2025 and appears to be stale compared with the current product documentation and even newer Jira suggestions that explicitly reference the existing Google Drive allowlist functionality.

Where I would be careful is using the 26,217 indexed objects value as proof that the allowlist is not working.

Atlassian says indexed-object allowances/counting are pooled at the organization level, and an indexed object represents content ingested through Teamwork Graph connectors. That makes it quite possible that the number you are seeing is not a clean “number of objects currently belonging to this specific connector” metric.

The fact that deleting and recreating the connector immediately returned to exactly 26,217 makes me suspicious of the counter as well. I couldn’t find documentation that guarantees that this value is reset when a connector is deleted, so I wouldn’t use it as the primary validation method.

I would validate the allowlist functionally instead:

Put a uniquely named test document inside Integración - Documentación.
Put another uniquely named document in the other Shared Drive.
Wait for indexing to complete.
Search for both from Rovo.
Ideally test through the synced/indexed path rather than by directly providing the Google Drive URL.

That last point matters because Rovo has more than one way of reaching Drive content. Atlassian documents that the admin connector controls what is synced/indexed, while some Rovo functionality can access third-party content at runtime using the user’s own permissions.

There is even a current Atlassian feature request documenting a case where content blocked from the synced Google Drive connector can still be reached through another mechanism such as Smart Links.

So regarding your questions:

1. Is the allowlist enforced?
According to the current documentation, yes — for Google Shared Drives. I would trust the newer support documentation over AI-1226 here.

2. Indexed object counter?
I wouldn’t rely on it to verify connector scope. Atlassian documents the indexed-object allowance at organization level, but I couldn’t find a documented refresh/reset behavior for the number shown after deleting/recreating a connector.

3. “Sync in progress”?
I also couldn’t find documentation precise enough to say that the green label represents a percentage/progress state. Given that synced connectors continuously synchronize changes, it may simply indicate an active synchronization state rather than “initial indexing is still running.” Atlassian describes the connector as continuing to synchronize new/removed content after setup.

4. Should you blocklist the second Shared Drive?
In theory, no. If the allowlist contains only one Shared Drive, the other Shared Drive should already be excluded from synced ingestion. Atlassian also says organizations would normally use either an allowlist or a blocklist rather than both.

Given your very reproducible 26,217 → delete connector → recreate → 26,217 behavior, though, I think this is a good case for Atlassian Support. I’d provide them the connector ID, timestamps, the allowlisted Shared Drive ID, and those object counts and ask them to confirm the actual ingestion scope from the backend.

Your test is detailed enough that Support should be able to distinguish between UI telemetry/cache and an actual ingestion problem.

Hope this helps.