Google Sheets IMPORTRANGE shows #REF! "You need to connect these sheets"
Hi, it's BlueByte. If IMPORTRANGE shows #REF!, don't start rewriting the formula — this particular #REF! is usually not a broken formula at all, but a one-time permission prompt waiting for a click. Let's confirm that's what it is, grant the connection, and cover the two things that keep it from resolving.
What this #REF! actually is
An =IMPORTRANGE(...) formula shows #REF! instead of data. Hovering the cell reads:
You need to connect these sheets. Allow access.This #REF! is not a broken formula — it is a one-time permission prompt that has not been answered yet. Recognizing that is half the fix; people often rewrite a perfectly good formula chasing a problem that is really about access.
Why IMPORTRANGE needs a connection
IMPORTRANGE reads data from another spreadsheet, so Google requires the destination sheet to be explicitly authorized to pull from that specific source. Until you approve it once, the formula returns #REF!. Two things commonly keep it from resolving:
- The connection has never been approved for this source–destination pair.
- You lack access to the source spreadsheet itself, so there is nothing to connect to.
A different-looking #REF! reading "Array result was not expanded" is a separate problem — the imported range is trying to overwrite cells that are not empty.
Read the tooltip to know which it is
Click the cell and read the tooltip. "You need to connect these sheets" with an Allow access button means the connection is unapproved — the normal case. If instead you get an error about permissions, open the source spreadsheet URL directly: if you cannot open it, you do not have access, and that is what to fix first. If the tooltip mentions "Array result", the problem is space, not access.
Grant the connection once
-
Click the cell holding the IMPORTRANGE formula.
-
Hover it (or read the error tooltip) and click Allow access on the prompt.
-
The data loads, and every IMPORTRANGE from that same source spreadsheet now works without prompting again — the grant is per source, not per formula.
If there is no prompt, check the syntax — the first argument is the source URL or ID, the second is the range in quotes:
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/SOURCE_ID/edit", "Sheet1!A1:C")A real case: one grant covered them all
You build a dashboard that pulls from a colleague's data sheet with =IMPORTRANGE("https://.../d/1AbC.../edit","Data!A1:F") and it shows #REF!. Hovering the cell shows "You need to connect these sheets — Allow access." You click Allow access, and the range fills immediately. You add three more IMPORTRANGE formulas pointing at the same source, and none of them prompt again — the connection is granted at the source level, so one approval covered them all. A week later a teammate opens the dashboard and sees the data too, because the grant lives on the sheet, not on your account.
Confirm it pulls and updates
The cell should fill with the source data, and other IMPORTRANGE formulas pointing at the same source should resolve too. Change a value in the source and confirm it updates in the destination after a moment — that proves the live connection, not just a one-time copy.
Keep it from breaking later
Connect the source once when you first build the sheet, and make sure everyone who edits the destination has at least view access to the source, so a later permission change does not silently break the pull.
How this differs from a plain #REF! or #N/A
The "connect these sheets" #REF! is a permission gate unique to IMPORTRANGE. A plain #REF! elsewhere means an invalid cell reference (a deleted cell), and #N/A from a lookup means no match was found — neither is fixed by granting access. So when the tooltip says "connect", click, don't rewrite.
Related questions
I clicked Allow access but it still shows #REF!.
Confirm you have at least view permission on the source spreadsheet, and that the source ID in the formula is correct. Re-open the destination sheet after granting access.
Do collaborators have to allow access too?
No. The connection is granted at the spreadsheet level, so once any editor allows it, the link works for everyone with access to the destination sheet.
It worked before and now shows #REF! again.
Access to the source was likely revoked. Restore your view permission on the source, then reconnect from the destination.
The tooltip says 'Array result was not expanded'.
That is a different #REF! — the imported range would overwrite non-empty cells. Clear the cells below and to the right of the formula so the result has room.
Can I connect the sheets without opening the cell each time?
The one approval per source covers every IMPORTRANGE from that source in the destination, so you only do it once. There is no bulk API for it in the UI beyond that first Allow access.
References
Haneul Seo
Infrastructure engineer · 10+ years running Linux fleets
More in this category
Gmail rejects your mail with 550-5.7.26: unauthenticated email is not accepted due to the domain's DMARC policy
Gmail enforced the DMARC policy your own domain publishes: the message failed both SPF and DKIM alignment against the header From: domain, so a p=quarantine or p=reject policy turned it into a hard bounce. The Authentication-Results header names the failing check, and three dig queries against your SPF, DMARC and DKIM records name the cause. A near-identical bounce about authenticating with SPF or DKIM is a different problem — Gmail's baseline sender requirements, not your policy.
Microsoft Entra ID: AADSTS50011, the redirect URI specified in the request does not match the redirect URIs configured for the application
Sign-in completes and then Entra ID refuses the last hop, because the redirect_uri your app sent is not a byte-for-byte match for any URI registered on the app. The match is case-sensitive, counts the trailing slash, requires https outside localhost, and treats the port as significant everywhere except localhost. It also splits by platform: web, spa and publicClient are three separate lists, and URIs added to the service principal instead of the application object can disappear. Read the URI and the app ID out of the error, compare them with az ad app show, add the exact string with az ad app update or a Graph PATCH, then wait three to five minutes.
Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled
A scanner, script or app that sends through smtp.office365.com gets 535 5.7.139 because the SMTP AUTH protocol is switched off for the tenant, for that mailbox, or by an authentication policy or security defaults that block Basic authentication. Read the wording (Tenant, Mailbox, or 'did not meet the criteria'), confirm with Get-TransportConfig, Get-CASMailbox and Get-AuthenticationPolicy, then open SMTP AUTH on the one mailbox that needs it rather than tenant-wide. Treat Basic SMTP AUTH as a bridge: Microsoft disables it by default for existing tenants at the end of December 2026, so move the sender to OAuth, High Volume Email or a relay connector.
Zoom: "Unable to connect" error code 5003 — the desktop app can't reach Zoom while the browser can
Error 5003 is the Zoom desktop app failing to complete its connection to Zoom's servers while the web client on the same machine joins fine. The app needs more than a browser does: Zoom's firewall article lists TCP 443/8801/8802 and UDP 3478/3479/8801–8810 for meetings, a set of CA hosts for certificate validation, and it asks that zoom.us and *.zoom.us be exempted from proxy or SSL inspection. A port test, a curl issuer check, and the app's built-in Network Connectivity Tool (Ctrl+Alt+Shift+D / Cmd+Option+Shift+D) show which of those is cut; fix that layer, and reinstall only when a single machine fails while its neighbours join.
Slack: "Slack cannot connect" and the grey "Last updated…" banner behind a corporate proxy
Slack loads channels over ordinary HTTPS but delivers new messages over a persistent WebSocket on port 443 to the three wss-*.slack.com hosts Slack names (primary, backup, mobile). When a proxy or firewall passes the HTTP side and blocks the upgrade — most often because SSL decryption is on for the wss hosts, or the allowlist stops at slack.com — the app shows the grey "Last updated…" banner or "Slack cannot connect." while the browser seems fine. Two curl probes from the affected machine show which layer is blocked; exempt the three wss hosts from decryption, allow every domain on my.slack.com/help/urls, and confirm with my.slack.com/help/test.
Word: "The document is locked for editing by another user"
Word found a lock — an owner file — for the document and assumed someone else has it open, so it offers only a read-only copy. Usually no one does: a crash left the lock behind, or a hidden Word process is still holding the file. Confirm which, close every Word instance, delete the stale ~$ owner file, and the document opens for editing again.