Sam Na writes practical freelance workflow guides that help independent professionals manage client access, collaboration, and cloud files with clearer boundaries.
Contact: seungeunisfree@gmail.com
Before you copy a client link, answer two questions: who should be able to open it, and what should that person be able to do after it opens?
File sharing permissions for clients are easiest to manage when you stop treating “Share” as one decision. In practice, a freelancer is usually making at least two decisions at the same time: who receives access and what that access allows.
Those decisions sound simple until a project becomes busy. You want a client to review a draft, so you send a folder. A stakeholder forwards the link to another person. Someone with edit access moves a file. A collaborator deletes an item from a shared folder. A delivery folder includes a working document that was never meant to be exposed. None of these situations necessarily begins with bad intent. They often begin with a sharing setting that was broader than the task required.
That is why cloud storage access permissions should be treated as part of the freelance workflow rather than as a technical detail hidden behind a Share button. When permissions match the work, clients can review, comment, download, or collaborate without receiving control they do not need. When permissions are broader than necessary, ordinary project actions can affect files, folders, or people that were outside the original purpose of the share.
The exact labels differ between cloud services. Google Drive uses roles such as Viewer, Commenter, and Editor for many file-sharing situations. Dropbox distinguishes view and edit permissions for shared content. OneDrive commonly offers Can view and Can edit choices along with different link audiences such as specific people or anyone with the link, depending on account and administrator settings.
You do not need to memorize every provider's menu. You need a repeatable way to think before clicking Send. Start with the client's task. Decide whether the client needs to see, review, download, upload, edit, reorganize, or manage anything. Then choose the narrowest practical access that still lets that work happen.
This guide explains that decision process. It covers view versus edit access, specific-person links versus broader links, folder inheritance, client-facing folder boundaries, download and resharing controls, testing, and access review after the project changes. The goal is not to make sharing difficult. The goal is to make the permission match the purpose.
Every share should define both. “The client can access this” is incomplete. A useful permission decision says which client or audience can access which item and what they can do with it.
Treat sharing as two separate permission decisions
First decide who should be able to open the item
The audience question comes first because a perfectly chosen view or edit role is still too broad if the wrong people can use the link.
Imagine that you want one client contact to review a confidential proposal. Giving the link view-only access limits what a recipient can do to the file, but it does not necessarily answer who can become that recipient. If the link works for anyone who obtains it, forwarding the link may extend access beyond the person you originally had in mind.
For work that is intended for named people, look for the provider's recipient-specific sharing option. The exact wording varies. A service may ask you to add an email address, invite a person, choose “specific people,” restrict access, or require sign-in.
Broader link sharing can still be useful. A public media kit, downloadable client resource, event asset, or other intentionally broad material may not need person-by-person invitations. The mistake is not using a broad link. The mistake is using one without noticing that the audience changed.
Then decide what those people should be allowed to do
After defining the audience, decide the recipient's role. Does the client only need to read the document? Do they need to comment? Do they need to upload assets? Do they need to change the file itself? Do they need to reorganize an entire folder?
These actions are not equivalent. A client who needs to approve a PDF usually does not need permission to delete neighboring project files. A stakeholder who needs to read a report does not automatically need the ability to replace it. A collaborator who is actively co-writing a document, on the other hand, may genuinely need edit access.
Thinking in actions keeps the setting tied to the actual task. Instead of asking, “Should I give them editor access?” ask, “What action are they expected to perform?” The correct role becomes easier to see.
Do not use familiarity as a permission rule
Freelancers sometimes grant broad permissions because the recipient is a trusted client. Trust matters, but it does not tell you what functionality the project needs.
A long-term client may be completely trustworthy and still accidentally move a file, rename a shared folder, delete an item, or edit a document that was supposed to remain a fixed reference. Limiting permission is not an accusation. It is a way to make the interface support the intended workflow.
The same principle works in the other direction. Do not force a client into view-only access when the project genuinely requires collaboration. If they are responsible for maintaining copy, uploading assets, or editing a shared planning document, the role should support those tasks.
A sharing setting is easier to evaluate when you answer these questions before generating the link.
Do not make one vague “sharing” decision. Decide the audience first, then decide the allowed action. A client should receive enough access to complete the intended task without automatically receiving control over unrelated files or functions.
Choose view, comment, or edit access deliberately
Use view access when the content should remain unchanged
View access is the natural starting point when the client needs to read, inspect, preview, or download material but should not alter the shared version.
Examples include final PDFs, approved reports, reference documents, presentation exports, read-only instructions, completed design previews, or files that serve as a fixed record of what was delivered.
Google Drive's current documentation describes Viewer access as allowing a person to open a file without editing or commenting. Dropbox similarly distinguishes view access from edit access for shared files and folders. OneDrive provides Can view options for many sharing situations.
View access is not automatically the same as “cannot make a copy.” Depending on the platform and settings, viewers may still be able to download, copy, print, or forward a usable link. If preventing those actions matters, review the provider's additional controls rather than assuming that view-only solves every distribution concern.
Use comment or review access when feedback is the task
Feedback is different from editing. A client reviewing copy may need to point out a sentence, suggest a change, or leave an approval note without directly changing the working document.
Where the service and file type support a comment or review role, that middle option can keep the feedback process clearer. The client contributes to the decision without directly rewriting the current document.
Google Drive supports a Commenter role for supported content. Microsoft's sharing tools may offer review-oriented options in supported situations, including review mode for certain Word documents. The exact feature depends on the file type, account, and current product configuration.
Do not force a review role simply because it sounds safer. If the client is genuinely co-authoring the content and should make direct changes, edit access may be the correct workflow. The role should match the job rather than a universal preference.
Use edit access only when changing the content is part of the work
Edit access can be powerful, especially at the folder level. Depending on the service, someone with edit rights may be able to change content, add files, move items, rename them, share them, or delete them.
Dropbox's current permissions documentation states that editors of a shared folder can add, edit, download, share, or delete files. Microsoft's OneDrive documentation similarly notes that people with edit permission on a folder can perform actions such as copying, moving, editing, renaming, sharing, and deleting items they can access. These capabilities are useful when the person is a true collaborator, but they are broader than simple document review.
Before choosing edit, name the required editing action. Perhaps the client needs to update a shared content calendar. Perhaps they need to upload product photography into a campaign folder. Perhaps two people are jointly maintaining a spreadsheet. Those are concrete reasons.
“They are the client” is not a concrete reason by itself.
Use when the task is consumption.
The recipient needs to read, inspect, preview, or receive the material without changing the shared original.
Use when the task is feedback.
The recipient needs to respond to the work without becoming a direct editor where the service supports that role.
Use when changing the shared content is part of the job.
The recipient needs to modify files or collaborate actively rather than simply review them.
Pause before granting it.
Folder-level edit access can affect multiple items and may permit broader actions than editing one document.
Give the recipient the smallest practical set of actions that still lets the agreed work happen.
If review is enough, do not grant edit by habit. If real collaboration requires editing, do not make the workflow unusably restrictive.
View, comment, and edit roles correspond to different client tasks. Start from what the client needs to accomplish, then choose the role that supports that action without adding unnecessary control.
Choose who can use the link
Specific-person sharing gives the link an intended identity
When a file is meant for one client contact, a small group, or named collaborators, recipient-specific sharing creates a clearer boundary than an unrestricted link.
OneDrive's current documentation, for example, distinguishes a “Specific people” option from broader link types. A link intended for specific people does not simply become usable by every new person who receives a forwarded invitation, although other people may already have access through another route.
Google Drive likewise lets users share directly with named people and groups. In work or school environments, the available sharing behavior can depend on administrator policies.
Recipient-specific access is useful when you need to know who the intended audience is. It can also make later review easier because you can inspect named access rather than remembering where a general link may have traveled.
Anyone-with-the-link access solves a different problem
A broad link is useful when ease of access is more important than identifying every recipient. It may suit resources designed to be distributed widely, client-facing downloads that are intentionally easy to forward, public campaign assets, or other low-sensitivity material.
The convenience comes from reducing sign-in and invitation friction. The tradeoff is that possession of the link may become the practical access boundary.
Google Drive states that “Anyone with the link” access allows anyone with the link to use the shared file according to the selected role, without requiring a Google Account in that sharing mode. Microsoft's OneDrive documentation similarly notes that an Anyone link can be used by someone who receives it directly or through forwarding, subject to the settings available for that account.
That does not make broad links inherently wrong. It makes them appropriate for a different audience model. Before selecting one, ask whether you are comfortable with the link being forwarded to another person.
Organization-only links are not the same as public links
Business cloud services may provide an intermediate audience: people inside the same organization. This can be useful when the project belongs inside one company and anyone within that organization who receives the link may reasonably need access.
For a freelancer working externally, however, an organization-only link can create confusion. You may create the correct file and permission role but still discover that the client cannot open it because your organization's sharing boundary does not include them.
The reverse can also happen. A client using a managed company environment may send you a link that works only for their employees. In that case, the sharing problem is not view versus edit. It is that your identity is outside the intended audience.
Do not assume the same choices exist on every account
Personal accounts, business accounts, educational accounts, and administrator-managed organizations may expose different controls. A company's administrator can restrict external sharing or disable broad link options even when the consumer version of the same product supports them.
Microsoft explicitly notes that some link options may be unavailable because an organization's administrator has restricted them. Google Workspace environments can also apply organizational sharing policies.
This matters for freelancer instructions. Avoid telling a client, “Just choose Anyone with the link” as if that option must exist. Instead, describe the intended result: the named external freelancer needs access, or the final delivery is intended to be accessible without individual invitations. Then use the controls that the client's environment actually permits.
Best when the audience is known.
Useful for named client contacts, private review, and projects where recipient identity matters.
Best when easy distribution is intentional.
Use only when you are comfortable with access following the link rather than a fixed list of recipients.
Best when the audience is an internal company group.
External freelancers may need a different sharing route.
Not every menu will match a tutorial.
Managed accounts can hide or restrict sharing options according to company policy.
Choose the audience model as deliberately as the permission role. Named recipients, organization-only access, and broad links solve different sharing problems. A view-only link can still be too broad if anyone who receives it can use it.
Check folder scope before sharing
Sharing a folder is broader than sharing one file
A folder share is convenient because it can grant access to an entire collection at once. That same convenience is what makes the scope worth checking carefully.
If you share one PDF, your first review question is simple: is this the correct PDF? If you share a project folder, you also need to ask what else is inside that folder now and what might be added later.
A folder that looks client-ready today can become broader next week if you drop internal notes, pricing drafts, unused assets, another client's material, or private production files into it. The permission is attached to the shared structure, not to your intention at the moment you created the link.
That is why a dedicated client-facing folder is often easier to manage than sharing a broad working folder and trying to remember which subitems are sensitive.
Parent-folder permissions can affect what happens below them
Folder hierarchies matter because cloud services often apply access from a shared parent to content inside it.
Google Drive's current folder-sharing documentation explains that files within a shared folder generally receive the folder's sharing status. It also warns that you cannot simply give a person less access to one file than the access they already receive through the containing folder in ordinary shared-folder situations. Google now provides limited-access folder mechanisms for more restrictive structures in supported cases, but the important freelancer lesson is simpler: do not assume a child file can always undo broad parent access.
If one document needs a different audience, it may belong in a different folder boundary rather than inside a broadly shared parent.
Inspect the folder from the top down
Before sharing, start at the folder you plan to send and look downward. What files are already inside? What subfolders exist? Which ones contain working material? Are there hidden assumptions in the structure, such as a folder called “Admin” that was never meant for the client?
Then look upward. Is this folder already inside another shared location? Are other collaborators inherited through the parent? Are there existing links that provide access through another path?
Permission mistakes often happen because the freelancer only inspects the new share they are about to create. Existing access can matter just as much as the new link.
Create a clean sharing boundary instead of solving exceptions one by one
If you repeatedly have to hide individual files from a shared client folder, the folder itself may be serving too many purposes.
Separate internal work from client-facing work. Your private project space can contain drafts, production notes, experiments, internal checklists, temporary exports, and research. The client-facing space contains the material the client should be able to reach.
This reduces permission complexity because the structure itself supports the access rule. Instead of asking whether each new file should be hidden from the client, you choose the correct side of the boundary when you save it.
Do not inspect only the file you are sending.
A recipient may already have access through a parent folder or another sharing route.
A shared folder keeps existing after today's handoff.
Think about what you may add to that location later.
Keep the boundary obvious.
A dedicated review or delivery folder is easier to reason about than a broad production folder full of exceptions.
Use provider-supported restrictive structures when needed.
Do not assume every child item can automatically override broader parent access.
Folder permission is a scope decision. Before sharing a folder, inspect what sits inside it, what access may come from above it, and what you are likely to add later. A clean client-facing boundary is usually easier to manage than a shared working folder full of exceptions.
Match permissions to the client task
A final delivery usually needs different access from a working document
The same client may need several permission levels during one project because the task changes over time.
During drafting, the client may need to comment on a document. During collaborative planning, they may need edit access to a shared tracker. During final delivery, they may only need to view or download approved files.
Do not preserve a broader role simply because it was useful earlier in the engagement. Permissions should follow the current task rather than becoming permanent project history.
Review folders should support review, not production management
A review folder has a narrow purpose: help the client evaluate work. It usually contains prepared drafts, proof files, presentation exports, or documents awaiting feedback.
If the client only needs to review, exposing the full working directory may create confusion. They may see incomplete alternatives, technical files, tests, or production assets that are not ready for discussion.
Create a review boundary that contains the material relevant to the current decision. Then choose the role that supports the feedback method you expect.
Upload requests do not always require folder edit access
Sometimes you need the client to give you files rather than collaborate with files you already own. It may be tempting to give the client edit rights to your entire project folder so they can upload material.
Before doing that, check whether your platform provides a more focused intake feature. Dropbox, for example, offers file requests that let people submit files without necessarily giving them ordinary access to browse a project folder. Other platforms may provide upload-only or request-based workflows through different features or plans.
The broader lesson is to separate intake from collaboration when possible. A client who needs to upload raw photos does not necessarily need to reorganize your working folder.
Shared operational documents may justify edit access
There are many cases where edit access is entirely appropriate. A client and freelancer may jointly maintain a content calendar, launch checklist, project tracker, product database, or planning document.
In that situation, removing edit access would create unnecessary friction. The document exists specifically to be updated by multiple authorized people.
The important distinction is that you are granting edit because shared editing is the purpose of that item. You are not using edit as the default setting for every file associated with the same client.
Start with view access unless another action is genuinely required.
Use comment or review access where the service and file type support it.
Use edit access when direct changes are part of the agreed collaboration.
Use the narrowest practical upload or intake method instead of automatically exposing the full working folder.
Share a dedicated delivery location with the access needed to retrieve the deliverables.
There is no single correct permission for every client relationship. Match access to the task: viewing, feedback, editing, uploading, or final delivery. Change the permission when the task changes.
Review download and resharing controls
View-only does not always mean download-disabled
This distinction causes frequent confusion. A recipient may be unable to edit the cloud version while still being able to download a copy.
Google Drive's current permissions documentation notes that viewers and commenters can download by default in many My Drive sharing situations, while owners can apply advanced settings that restrict downloading, printing, or copying for viewers and commenters.
OneDrive also provides download-related controls in supported account types and sharing configurations. Microsoft's documentation describes a “Can't download” option in some contexts, while available features may depend on the account, file type, organization, and current product configuration.
Dropbox similarly distinguishes ordinary view access from additional link controls, with some capabilities depending on the account and sharing method.
If download behavior matters, inspect that setting directly. Do not infer it from the word “Viewer.”
Preventing editing is different from preventing redistribution
A recipient who cannot edit a file may still be able to send the link to someone else if the link's audience model permits that other person to use it.
This is why permission design has two layers. The action role controls what an authorized recipient can do with the item. The audience rule controls who can become an authorized recipient through the link.
If forwarding matters, use a sharing method designed around named recipients or another restricted audience rather than relying only on view-only access.
Editors may have sharing abilities you did not intend
Editing and resharing can be connected. Google Drive's current documentation notes that Editors can share files in many My Drive situations, although owners have advanced settings that can prevent editors from changing permissions or sharing.
Dropbox editors may also be able to share content depending on the sharing context and account settings. OneDrive folder editors can have broad capabilities, including sharing, under supported configurations.
When you grant edit rights, check whether that role also gives the person power to extend access to others. If the project requires editing but not permission management, use the provider's available controls to separate those responsibilities where possible.
Technical restrictions do not replace project agreements
Cloud controls can reduce ordinary copying, editing, or forwarding in supported situations. They are not a universal digital-rights guarantee.
If a person can legitimately view sensitive information, the project still depends on an appropriate relationship, agreement, and handling expectations. A screenshot, photograph of a screen, retyped content, or another external method may exist outside the cloud provider's control.
Use technical restrictions to reinforce the workflow, not to pretend that software can eliminate every form of human access once information has been displayed.
Controls editing of the shared original.
It does not automatically answer whether downloading, copying, printing, or forwarding is possible.
Review it separately.
Use the provider's supported download restriction when the project genuinely requires it.
Check whether editors or link recipients can extend access.
Editing rights and sharing rights may overlap depending on the service.
Technical controls support policy; they do not replace it.
Once someone can see information, software cannot guarantee that every external copy is impossible.
Do not treat “view-only” as a complete security description. Check download, copying, printing, forwarding, and resharing controls separately when those behaviors matter to the project.
Test access before sending the client link
Your owner view can hide recipient problems
A file that opens perfectly for you proves very little about the client's experience. You are the owner or an authorized collaborator. The service may recognize your account automatically and bypass the restrictions that the recipient will encounter.
Before an important share, review the permission panel rather than relying on the fact that the link opens in your browser.
Confirm the intended recipient or audience, the role, the folder being shared, and any optional restrictions. If you use a broad link, confirm that the broad audience is intentional. If you use named recipients, confirm that you entered the correct account identity.
Test from outside your normal signed-in session when practical
For important deliveries, it can be useful to inspect the link in a separate browser profile, private window, or another appropriate account. This may reveal that the link asks for sign-in, requires an access request, exposes a broader folder than expected, or does not behave the way your owner session suggested.
This test has limits. A private browser is not a perfect simulation of a managed client organization. The client's administrator may have policies that affect external links, and the recipient may be required to use a specific work identity.
Treat the test as a usability check, not a guarantee. The important point is to look at the share from the recipient's side before the deadline when possible.
Check the link target, not just the permission label
You can set the correct Viewer role on the wrong folder.
Before sending, open the exact destination and look at its contents. Does the link point to the final-delivery folder, or to the entire client project? Did you accidentally share the parent folder because both names look similar? Does the folder contain an internal document that was added after you first prepared the delivery?
Permission review without content review is incomplete. The safest possible role still exposes whatever content sits inside the shared boundary.
Use the client's task as the final test
A permission can be restrictive and still be wrong. If you give a client view access to a document they are supposed to edit, the security setting may be narrow but the workflow fails.
Run one final task-based check: can the client do exactly what the delivery message asks them to do?
If the message says, “Please leave comments,” the role should support comments. If it says, “Please upload your photos here,” the recipient needs an appropriate intake path. If it says, “Download the approved files,” the client needs a usable route to retrieve those files.
Do not judge access from your owner view alone.
Check whether the share is restricted, recipient-specific, organization-based, or broadly link-accessible.
Verify view, comment, edit, or another supported permission against the client's actual task.
Make sure the selected file or folder contains only the material you intend to expose.
If downloads, resharing, expiration, or other restrictions matter, inspect those settings separately.
Use a suitable external session or account to look for obvious access problems.
Only after the audience, action, scope, and expected task all match.
Test sharing from the recipient's perspective. Confirm the audience, permission role, shared scope, optional restrictions, and the specific task the client must complete before sending the link.
Review and remove access when the work changes
Permissions should change when the project changes
Access that was correct during one phase of a project may be unnecessary later.
A client may need edit rights during planning but only view access after a document is approved. A subcontractor may need a folder for two weeks but have no reason to retain access after their task ends. A stakeholder may leave the company while the project continues.
Do not treat permission settings as permanent simply because the link still works. Review them when the scope, people, or project stage changes.
Use the provider's access-management view rather than relying on memory
Cloud services typically provide a place to inspect who currently has access or which links exist. Use it.
OneDrive and SharePoint provide Manage Access controls that can show sharing paths and allow owners to stop or change sharing in supported situations. Google Drive lets owners manage people and general access. Dropbox also provides controls for shared members and links.
This matters because a file can have more than one access path. Removing one person from a direct invitation may not matter if the same person can still use a broader link. Deleting one link may not remove direct folder membership.
Review access as a whole rather than assuming that changing the most visible setting closes every route.
Remove collaboration access when collaboration ends
When the project moves from active work to final delivery, consider whether editing rights still serve a purpose.
The client may reasonably need continuing access to completed files. That does not automatically mean they still need the same edit permissions that were useful during production.
Likewise, a freelancer may remain responsible for future maintenance under a retainer, in which case continued access can make sense. The goal is not to remove access mechanically at every milestone. The goal is to make continued access an intentional decision.
Build permission review into project closeout
A project closeout checklist often includes final delivery, invoicing, archiving, and notes. Add access review to that process.
Check which client-facing links should remain, which review links are obsolete, whether temporary collaborators still have access, and whether your own access to a client-owned folder should continue.
When the client owns the cloud environment, offboarding may also require the client administrator to remove your account or invitation. Do not assume that deleting a shortcut from your own cloud storage removes the permission granted by the owner.
A clean ending is part of a clean sharing system. If you decide how access should end when you create it, offboarding becomes much easier.
Everyone with access still has a reason to participate in the project.
People with edit rights still need to edit, rather than simply retain access to completed work.
Old review links, temporary shares, and broad links still have a legitimate purpose if they remain active.
Shared folders have not accumulated new internal files that changed the meaning of the original share.
The freelancer and client know which final-delivery access should remain and which collaboration access should end.
Permissions have a lifecycle. Review them when people, tasks, or project stages change. During closeout, keep the access that still serves a real purpose and remove or reduce access that belonged to an earlier phase of the work.
Frequently Asked Questions
Choose the permission according to the client's task. Use view access when the client only needs to read or receive the content. Use comment or review access where supported when feedback is the goal. Use edit access when changing the shared file or maintaining a collaborative document is part of the agreed work.
No. View-only normally prevents editing of the shared original, but download, copy, print, or related controls can be separate settings. Review the current options for the cloud service and account you use if limiting those actions matters.
They serve different purposes. Sharing with specific people is useful when the intended audience is known and recipient identity matters. Anyone-with-the-link access is easier to distribute but may allow a forwarded link to reach additional people. Choose based on the intended audience rather than treating one setting as universally correct.
Depending on the cloud provider and sharing configuration, folder editors can have broad capabilities that may include adding, editing, moving, sharing, renaming, or deleting items. Review the current provider documentation before granting folder-level edit access.
The answer depends on the service and folder structure. Parent-folder permissions can affect items below them, and some services limit how much a child file can reduce access inherited from its parent. When one item requires a different audience, a separate restricted folder or provider-supported limited-access structure may be clearer.
Yes, especially for an important delivery. Review the audience, role, folder scope, and any additional restrictions. When practical, inspect the link from outside your normal owner session to catch obvious sign-in, access, or scope problems before the client encounters them.
Review them at project closeout rather than applying one universal rule. Final-delivery access may still be useful, while temporary edit access, review links, or collaborator permissions may no longer be necessary. Keep continued access intentional.
Make permission review part of every share
Good client file sharing is not about selecting the most restrictive setting every time. It is about making the permission fit the purpose.
Start with the person. Decide whether access belongs to a named client, an internal organization, a defined group, or anyone who receives the link. Then define the action. Does the person need to view, comment, edit, upload, download, or manage the content?
Next, inspect the scope. A correct role applied to the wrong folder is still the wrong share. Check the parent folder, the files below it, existing access routes, and the material that may be added later.
Finally, think about time. A permission that is appropriate during active collaboration may be unnecessary after approval. A temporary review link may not need to live forever. A final-delivery folder may reasonably remain available long after editing rights are removed.
This is the practical meaning of learning how to share folders securely with clients: you know who the share is for, what they can do, what the share includes, and when the access should be reviewed again.
Once those questions become routine, cloud permissions stop feeling like a collection of mysterious buttons. They become another part of a clear freelance workflow.
Before your next client share, run a four-question permission check.
Ask who needs access, what they need to do, which exact file or folder they should reach, and how long that access should remain. Then choose the cloud setting that matches those answers instead of accepting the first default shown by the Share dialog.
Sam Na writes about practical freelance workflows, cloud collaboration, client file management, and simple systems for independent professionals. The focus is on making recurring project decisions easier to understand, repeat, and maintain without adding unnecessary complexity.
Contact: seungeunisfree@gmail.com
This guide provides general information about cloud file and folder permissions for freelance client work. Available settings can differ by cloud provider, account type, subscription, file type, organization policy, and administrator configuration.
Sharing features can also change over time, so review the current documentation and permission panel for the service you actually use before an important client share. Do not assume that a setting described for one account will appear in exactly the same way for another account.
If the files contain confidential, regulated, contractual, personal, or otherwise sensitive information, consider the client's requirements and relevant professional or official guidance before deciding how access, downloads, retention, or external sharing should be handled.
