Shared File Links: Check the Audience, Role and Recipient

Updated 19/10/2026 · Reviewed content

You send a document link to a group, but one person sees an access request while another can edit it. Before changing the file itself, separate three questions: who should get in, what each person should do, and which account they are using.

This guide builds an original handover plan for a fictional Malaysian neighbourhood club. Google Drive provides the concrete permission vocabulary; our decision tables and checking method are editorial recommendations. They are not a test of your account or a claim about i8 Live storing shared documents.

Write the audience and the task first

Describe the intended exchange in one sentence. For example, “Two organisers need to update the volunteer rota; everyone else needs to read the public timetable.” This is a clearer requirement than “send the folder to the group”.

Decide what information belongs in that exchange. A timetable intended for public distribution and a volunteer contact sheet serve different audiences. Our recommendation is to prepare separate deliverables when one file would otherwise mix those purposes.

The table describes intentions, not permission settings that have already been applied. Use it as the reference when reading the actual sharing panel. If the settings do not match the intention, resolve that difference before distributing the link.

Separate access scope from the role

Google's Drive documentation distinguishes the audience allowed to open a file from the role assigned to that audience. Its sharing options include Restricted and Anyone with the link; file roles include Viewer, Commenter and Editor. These are separate decisions.

For files in My Drive, Google describes viewing, commenting and editing as different capabilities. It also notes that download access and an editor's ability to change sharing can be controlled. Read the actual settings rather than treating a short role label as the whole access review.

Our practical question is therefore two-part: “Who gets this role?” A reading role given to a broad audience still has a broad audience. An editing role given to one intended organiser has a different purpose, even if both arrangements use the same document URL.

Avoid changing general access just to make an inconvenient request disappear. First establish whether the person should be included, what task they need to perform, and whether the current access route fits that task. Then change the appropriate setting if you are authorised to do so.

Work through the club's two-file handover

In our invented example, Farah coordinates a Saturday reading event in Petaling Jaya. She prepares a public timetable and a separate organiser rota containing volunteer contact details. Only the timetable belongs in the open event announcement.

Farah writes down the intended roles before touching the sharing panel. The two organisers need to edit the rota; the wider audience needs to read the timetable. She does not assume that copying a link into a chat automatically expresses both intentions correctly.

Next, she asks an intended organiser to check the agreed task using the account meant for the collaboration. “I can open the timetable” would not answer whether that organiser can update the rota. Her handover note names the file and the action being checked.

These are verification questions, not results from a performed experiment. Farah would record the actual outcome and leave an unresolved item open. A successful check by one person also does not establish that every intended recipient has the same access.

Investigate an access request before widening sharing

Google's access-troubleshooting help says that a recipient with more than one Google Account may be signed in to a different account from the one a file was shared with. It explains switching to the account with access or requesting permission from the owner. A request is not itself an instruction to approve it.

Start with the file identity and the intended recipient. Confirm through the communication route already used for the handover that this is the right person and the right document. Do not post a private link in a public support thread simply to demonstrate the error.

Ask the recipient to report the visible message and whether they used the intended account, without sending passwords, one-time codes or unnecessary personal details. If they only need to read, an editing request may reveal a mismatch in the handover instructions rather than a need for broader access.

For a work or school account, Google notes that an organisation can limit external sharing. When the visible restriction concerns that policy, use the organisation's approved support route. Repeatedly resending the same link does not explain or resolve the policy decision.

Review the route that supplied access

Google's change-sharing guidance explains that folder permissions can affect access to contained files. It warns that stopping editors from sharing one file directly does not stop access obtained by sharing its parent folder. A file-level control therefore needs to be read alongside its surrounding access context.

Our recommendation is to record where the visible access came from: a named person, a general-access setting, or a containing folder. If the panel points you to a parent folder, consider that folder's other contents before changing it. Ask its responsible owner when the scope is unclear.

Do not infer that removing one visible entry has completed the whole review. Reopen the relevant panel and inspect the remaining routes. Record what you actually checked, and avoid announcing that nobody else can open a file unless the evidence supports that statement.

Close the handover with a specific record

1. Name the exact file and the task each recipient needs to perform.
2. Separate public material from details intended for a smaller audience.
3. Read the audience scope and role in the current sharing panel.
4. Resolve account or policy mismatches before granting broader access.
5. Ask an intended recipient to confirm the specific agreed action.
6. Review remaining access when the collaboration ends, then record unresolved items.

A useful completion note might say, “Public timetable checked by the event helper; rota editing confirmed by the two named organisers; folder access still needs the owner to review.” Each clause has a distinct piece of work behind it. “Link fixed” would hide those differences.

Google cautions that controls on sharing, printing or downloading cannot stop people distributing content in other ways. Treat an access change as a change to the service's current controls. Do not describe it as proof that earlier copies or disclosures have been recovered.

FAQ

Does sending a link prove the recipient can open it?

No. Treat delivery and usable access as separate checks. Ask the intended person to confirm the actual reading or editing task, and resolve any account mismatch before changing access scope.

Is a Viewer label enough to finish the review?

Read the audience as well as the role, then inspect any relevant additional controls. Our handover method starts with who needs the material and what they need to do, rather than choosing a role in isolation.

Should I approve every request from the group chat?

Confirm that the requester belongs in the intended audience and needs the requested capability. A familiar chat context does not replace checking the actual recipient and file. Leave unclear requests unresolved while you verify them.

Will restricting access retrieve copies already shared?

Do not assume that it will. Google's guidance distinguishes service controls from other ways people may distribute contents. Review the current access routes and handle any earlier disclosure as a separate issue.

Choose the next check for the file

For a downloaded deliverable, our file app and format guide addresses whether the recipient needs a different app or a different file format. If a visible result needs explaining, build a useful problem report with the exact observation and intended task.