> For the complete documentation index, see [llms.txt](https://academy.shade.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.shade.inc/guides/review-and-client-delivery/work-with-freelancers.md).

# Work with freelancers

Give freelancers exactly the access a job needs, let them mount drives when they need to, and remove access cleanly when the job ends.

**Outcome:** freelancers can do their job in Shade, mounting drives if they edit, without seeing other clients' work, and you can remove their access in one step when the job ends.

**Who it's for:** admins and producers who bring in outside editors, colorists, sound designers, or assistants.

**Time:** about 5 minutes per freelancer.

## Choose the right role

| The freelancer needs to                                       | Use                                      |
| ------------------------------------------------------------- | ---------------------------------------- |
| Edit from a mounted drive, on specific drives or folders only | **Contractor** (paid seat)               |
| Review or upload to a few folders in the browser              | **Guest** (no seat)                      |
| Grab files once, or upload once                               | A published **link** (no account needed) |

Contractors are workspace users who aren't part of default drive inheritance, so they see only what you add them to, including when they mount drives. Guests can't mount drives. See [Guests vs Workspace Members](https://academy.shade.inc/sharing-and-collaboration/guests-vs-workspace-members).

## Steps

{% stepper %}
{% step %}

### Invite them with the right role

For an editor who needs ShadeFS, invite them to the workspace as a **Contractor**. For a browser-only reviewer, skip the workspace invite and share folders with their email address, which makes them a guest.
{% endstep %}

{% step %}

### Grant access to only what the job needs

Share the specific drive, or better, the specific project folders, with the freelancer, at the lowest level that works:

* **Edit** to cut and export
* **Comment** to review
* **Download** to pull files only

Drive names are visible to anyone with access to something inside the drive, so keep drive names client-safe.
{% endstep %}

{% step %}

### Give them a starting point

Send them a link to the folder, and if they're editing, the guide for their editing app, such as [How to use Shade with Adobe Premiere Pro](/guides/editing-integrations/how-to-use-shade-with-adobe-premiere-pro.md), plus [Edit remotely over ShadeFS](/guides/editing-integrations/edit-remotely-over-shadefs.md).
{% endstep %}

{% step %}

### Offboard when the job ends

Remove the contractor from the workspace, or remove the guest's shares, as soon as the job ends. For guests, go to **Workspace > Manage Members > Guests**. If you shared links, disable them under **Shared Links** in the drive's sidebar.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Freelancer turning into a regular? You can upgrade a guest to a workspace member at any time, without re-sharing anything.
{% endhint %}

## Related guides

* [Set up an agency workspace](/guides/setup-and-migration/set-up-an-agency-workspace.md)
* [The client review loop](/guides/review-and-client-delivery/the-client-review-loop.md)
* [Roll out Shade company-wide](/guides/setup-and-migration/roll-out-shade-company-wide.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://academy.shade.inc/guides/review-and-client-delivery/work-with-freelancers.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.