Practical Guide · Documentation-based workflow. Platform role descriptions and security guidance checked 28 October 2026. The worked example is fictional, not a report of a customer project or a test of every platform.
When a freelancer asks, “Can you send the login?”, it can feel faster to reply with a password than to figure out the permissions screen. That shortcut becomes awkward when the job is over. Who can still open the files? Was the same password used somewhere else? Can the person change billing details, invite other users, or publish without approval?
You can usually share access with a freelancer without sharing your own password. The better approach is to create an individual invitation, give the smallest useful role, record what was granted, and decide how it will be removed before the project ends. It takes a little more thought at the beginning and saves a surprisingly messy handoff later.
This guide is for small business owners and freelancers managing websites, analytics, shared folders, or routine marketing work. It is an operational checklist, not a security certification or legal advice. Product screens and account restrictions change, so verify the current instructions in the linked official documentation.
Before you share access with a freelancer, write down the actual task
“Help with the website” is too vague to justify an administrator account. “Draft three service pages for review, without publishing or changing plugins” is an access decision you can make. The difference matters because an invitation can grant much more than the immediate task requires.
Start with six questions: What will the person produce? Which workspace contains the inputs? Do they need to view, comment, edit, publish, or manage users? Who approves changes? When does the work end? Who will remove access?
Do not treat a freelancer’s professional status as a substitute for permission planning. A trusted collaborator may still be given more access than either side intended. Separate ownership from production: the business keeps ownership and recovery control; the contributor gets the specific ability needed to do the job.
If onboarding is already scattered across email, use AWL’s client onboarding checklist to gather the task, contacts, and approval process before opening accounts.
Three ways to share access with a freelancer
Use the first workable option in this order. The goal is not to make sharing complicated; it is to avoid handing over a permanent identity when a bounded invitation will do.
| Access method | Best for | Main trade-off | What to record |
|---|---|---|---|
| Named user invitation | Website CMS, analytics, business platforms | Role may still permit more than the task requires | Email, platform, role, expiry or review date |
| Restricted file or folder share | Briefs, drafts, selected assets | Folder permissions may expose everything inside | Exact folder, viewer/commenter/editor, owner |
| Controlled credential access | Legacy service with no supported collaborator role | Shared identity weakens attribution and can persist | Exception approval, access method, rotation plan |
An invitation is not automatically safe just because no password was sent. A user with administrator rights can still change important settings. A restricted folder is not restricted if it sits inside a parent folder that grants broader access. The actual permissions matter more than the name of the tool.
Choose the smallest useful permissions in common business tools
WordPress: writing access is different from site administration
For a draft-only writing task on a standard WordPress site, Contributor can create and manage drafts but cannot publish them. Author can publish and manage their own posts; Editor can manage other people’s posts too. Administrator has broad site-level controls. Plugins and custom roles can change these capabilities, so inspect the real site rather than assuming the labels guarantee a specific boundary. WordPress documents the defaults in its roles and capabilities guide.
If the writer needs to upload media, a default Contributor role may not suffice. Decide whether the owner will upload the assets, whether a narrower custom role is available, or whether the task genuinely requires broader permissions. Do not quietly switch to Administrator just to make a single upload work.
Google Drive: share the work folder, not the whole archive
Google Drive offers Viewer, Commenter and Editor access. For reviewing a brief, Viewer may be enough; for adding notes, use Commenter; for actively editing the agreed working files, Editor may be necessary. Be careful with parent folders and inherited permissions. An Editor can have significant abilities over files within a shared folder. See Google’s current file and folder sharing instructions.
A useful pattern is a dedicated project folder containing only the approved brief, non-sensitive reference assets, work-in-progress drafts and a deliverables area. Keep invoices, contracts, other clients’ work and account recovery material elsewhere. Share with the collaborator’s specific email address rather than choosing “Anyone with the link” for private work.
Search Console and Analytics: read-only first
For an SEO review, start by asking whether the freelancer needs to inspect reports or actually change a configuration. In Google Search Console, a property owner can add a user and choose a permission level. A Restricted user is often a better starting point for observation than granting owner status. Check Google’s Search Console users and permissions guidance for the current distinctions and removal procedure.
Google Analytics also separates roles such as Viewer, Analyst, Marketer, Editor and Administrator, with account-level permissions potentially inherited by properties. Give access at the narrowest appropriate level. A reporting assignment is not a reason to grant settings or user-management authority. Google explains those distinctions in its Analytics role reference.
Advertising accounts, payment platforms and storefronts require extra care because a change can spend money, affect transactions, or expose customer information. Keep budgets, billing and ownership under an authorized business contact unless a separately approved task truly requires them.
Copy this access register before sending an invitation
A spreadsheet or a simple project note is enough. It should not contain passwords, one-time codes, API secrets, or recovery answers. Its purpose is to show who has access to what and why.
Project | Platform / exact asset | Person & account email | Task | Role granted | Owner / approver | Start date | Review or end date | Access removed? | Evidence of removal Website rewrite | WordPress | writer@example.com | Draft three service pages | Contributor | Business owner | 3 Nov | 20 Nov | No | — SEO review | Search Console property | analyst@example.com | Read performance reports | Restricted user | Business owner | 3 Nov | 14 Nov | No | —
Rows are fictional examples. Replace dates, emails, tasks and roles with the current project information. The “evidence of removal” field might hold a dated confirmation or a note referencing the platform’s user list. It should not hold screenshots containing sensitive data.
Review the register during the project, not only on the last day. If the scope changes, update the role deliberately. A request for “just one more thing” can require permission reconsideration, not necessarily permission expansion.
A seven-step invitation workflow
- Confirm identity through an established channel. Use the freelancer’s agreed work email from the project agreement or verified conversation. Do not rely only on a forwarded request that suddenly names a different address.
- Confirm the task and decision rights. Can the collaborator draft, edit, publish, delete, export data or change account settings? Write the approved actions.
- Choose the narrowest platform role. Check role definitions and whether access at a parent account would include unrelated properties or projects.
- Prepare a bounded workspace. Move only approved reference files into a dedicated folder. Remove unnecessary customer data and secrets before inviting anyone.
- Send an individual invitation. Use the platform’s supported member, role or sharing feature. Avoid sending a primary account password by chat or email.
- Test the actual handoff. Have the freelancer confirm they can perform the required action, and that they cannot access something deliberately out of scope. Use a harmless sample task, not a live billing change.
- Set a review and revocation date. Put the owner responsible for removing access in the register. Some tools offer expiry settings; where they do not, use a calendar reminder and manual check.
Ask the freelancer to protect their own account with multi-factor authentication where supported. Australia’s Cyber Security Centre small-business handbook recommends MFA, software updates and backups as practical baseline measures. Strong authentication does not replace least-privilege access; the two solve different problems.
Worked example: a short website content project
Imagine a small consulting firm hiring a freelance writer to prepare three website pages and an SEO specialist to check search performance. These are illustrative roles, not people who were hired or an experiment that AWL conducted.
The tempting shortcut: send the website administrator password and a link to the company’s entire Drive. It is quick to arrange, but creates uncertainty over who can publish, change plugins, browse sensitive folders and use the same login after the project ends.
The bounded version: create a WordPress Contributor account for the writer; have the owner upload approved images and retain publishing approval. Share a dedicated Drive folder containing the brief and draft assets, with editing rights only where necessary. Give the SEO reviewer a suitable read-focused role for the Search Console property. Keep billing, domain registrar access and backup administration with the business owner.
The owner reviews the draft pages, signs off the changes, and publishes. At closeout, the owner checks that source files live in a business-controlled location, revokes both invitations, and records the date. The SEO specialist does not need the writer’s login. The writer does not need the SEO property. Neither requires the main business email password.
This process is not guaranteed to prevent every incident. It does make authority visible and gives the business a clean removal path. That is a much better operational outcome than guessing later which credentials were shared.
Copy-and-paste message to request or approve access
Freelancers can use this request when a client offers to send a login. Owners can send the approval version back with the role and end date filled in.
Subject: Access needed for [project / task]
To complete [specific deliverable], I need [view/comment/edit/draft] access to [exact platform, property or folder]. My work account is [email]. I do not need ownership, billing access, or the password for your primary account. Please use the platform’s user invitation or a restricted folder share if available.
The proposed access period is [start date] to [end date]. [Name / role] will approve changes before they go live. Once the final files are accepted, please remove my access and confirm closure. If the platform has no separate user role, let’s agree on a safer exception before sharing credentials.
Do not paste client names, tokens or confidential URLs into a public template. Keep the actual request inside the project’s established communication channel. This message also pairs well with a clear scope of work so that “access granted” never becomes “anything in the account is authorized.”
What if the platform offers only one shared login?
Some older tools and small plans do not support separate users. First check whether a supported team feature, delegation option or lower-privilege plan is available. If access is not essential, ask the owner to run the change while the freelancer supplies instructions or files. That often solves the task without creating a second login.
If temporary credential access is genuinely unavoidable, the business owner should approve the exception and decide the safest permitted transfer method. A reputable password manager’s sharing controls may reduce the risk of an exposed chat message, but they do not magically create a separate identity or guarantee that the recipient cannot use the credential outside the intended task. Check the service terms, available logging and whether access can be revoked. Avoid sharing MFA codes, recovery codes or the primary administrator credentials; where no suitable arrangement exists, escalate rather than improvising.
After the task, rotate exposed credentials where appropriate, revoke sessions or tokens if supported, and inspect the account’s authorized users and connected applications. Store recovery material with the owner, separate from the project workspace. NIST’s current digital identity guidance treats recovery codes as sensitive account-recovery mechanisms, not ordinary collaboration material.
End the project by revoking access, not just saying thanks
Removing permissions is part of a deliverable handoff. A friendly final email does not disable a WordPress account or a Google Drive share. Use the project’s final acceptance as the trigger for this checklist, subject to any agreed support window:
- Confirm the business controls final files, source documents, licenses and relevant published assets.
- Remove the collaborator’s named users from each platform and shared folder; check inherited and group-based permissions too.
- Review linked apps, API tokens, invitations and access methods created for the job. Revoke what is no longer required.
- If a credential was shared, follow the agreed rotation and session-revocation plan.
- Verify owner, billing, recovery contact and MFA settings remain under authorized business control.
- Record which access was removed, when, by whom, and whether any exception remains active for support.
- Ask the freelancer to confirm that any retained work files are limited to the agreed retention obligations. Do not assume the platform revocation removes previously downloaded copies.
The longer client offboarding checklist covers the surrounding delivery, invoice and support boundary. For the bigger business risk behind this habit, see why a login can become a fragile part of an online business.
Five red flags that should pause the invitation
- The request asks for owner or administrator rights but describes only a routine drafting or reporting task.
- The login invitation is going to a new, unexplained email address or a shared account used by several people.
- The folder contains other clients’ materials, payroll records, identity documents or recovery codes unrelated to the work.
- Nobody can say who will approve publication, spending or account changes.
- The project is ending, but there is no owner assigned to revoke access or collect final assets.
A red flag does not prove malicious intent. Often it means the handoff was planned too quickly. Resolve the gap in writing and continue with a narrower setup.
Questions that come up in small projects
Should I create a separate business email for every freelancer?
Not necessarily. A named external collaborator account is often enough if the platform supports it, the identity is verified, and the business can revoke the permission. For services under a managed organization, follow that organization’s identity policy. Avoid creating one shared login for several contractors simply to save a few invitations.
Does “Viewer” always mean the person cannot download anything?
No. Viewing and copying or downloading are different controls, and the platform’s defaults matter. Check settings before sharing confidential files. Consider providing a redacted version of a document rather than trying to restrict a highly sensitive original.
Can I leave access active in case we work together again?
It may feel convenient, but permanent unused access creates an unnecessary dependency. Remove it at project close and re-invite the person when new work is approved. If there is an ongoing retainer, document its scope and review access periodically.
What if a freelancer needs Administrator access for technical maintenance?
Sometimes a legitimate task really does require privileged changes. Treat that as a separate, time-bounded approval with a backup, clear change record and a known recovery owner. Granting a high-privilege role should be an explicit exception, not the default starting point for a mixed list of tasks.
The small version you can use today
Before anyone starts, write one sentence describing the task, invite a named person to the smallest useful workspace, give the narrowest role that actually works, record the removal date, and keep account ownership under your control. You do not need a complicated access-management product to begin doing those five things.
A good collaboration should make it easy for someone to work and easy for them to leave. When that is designed at the start, the final handoff is simply the last step of the process rather than an uncomfortable search through old logins.
