ShotGrid for Content Production Management: Configuring Statuses

Where production mess begins and how ShotGrid helps

What chaos looks like without a single system

Chaos usually doesn’t start with “bad people”, but with disconnected agreements. Tasks live in chat, statuses are in the producer’s head, deadlines are in a spreadsheet, and files sit on a server in folders named like “final_definitely_last_v7”.

When there aren’t shared statuses and rules, the most important things fall apart: it’s unclear what’s ready, what’s under review, who’s next in line, and where the current version is stored. The result is extra fixes, duplicated work and “lost” files that are simply stored in the wrong place or named differently.

Notifications are a separate pain. A spreadsheet can hold the plan, but it can’t tell people what they need to do right now. So even a good plan turns into endless reminders and manual checks.

How ShotGrid plugs these gaps

ShotGrid helps consolidate three pillars in one place: tasks, statuses and context (discussions, versions, files). Typically several groups use it at once: production (planning and control), creative (submitting versions and comments), and tech (pipeline, templates, integrations).

After rollout you can expect clear, practical changes: it becomes visible who is doing what and at what stage; comments stop "getting lost" because they are tied to a specific version; files disappear less often thanks to a clear link to a task; and there’s less manual supervision because notifications go to the people who actually need to act.

A simple example: a designer submits titles “for review”, the director gets a notification, leaves a comment directly on the version, and the task moves back to “needs fixes” for the artist. No one has to remember who to message or which file to open.

ShotGrid basics in plain words

ShotGrid works like a single project log: what we do, who does it, in what state, and where materials are. When the whole team understands the system’s terms the same way, there is less confusion and fewer manual clarifications.

A minimal dictionary almost everyone needs:

• Project: the project, a container for people, stages and data.
• Asset: an item that is created and reused (character, location, logo, 3D model).
• Shot: a specific frame or scene in the edit structure.
• Task: a piece of work for an Asset or Shot (modeling, rigging, comp, sound).
• Version: the result you can view and compare (render, preview, playblast).
• Note: a comment or remark attached to a task, version or frame.

People often confuse Task and Version. A Task answers “what needs to be done and who’s responsible.” A Version is “what exists right now.” A task can have many versions. A version usually has an author, a date and a short description of what changed.

For daily work you don’t need tens of fields. Typically name, status, assignee, due date, priority and two links — to an Asset or Shot and to the latest Version — are enough. Other fields (budgets, metrics, custom attributes) are better added later, when the team understands what’s actually missing.

To avoid duplicates, agree on naming rules in advance. For example: a consistent format for shots (SC010_SH020), unified asset names (CHAR_Anna, PROP_Cup) and a ban on “final_the_most_final”. A simple check: if an entity can’t be found quickly by search, the names have already drifted.

Designing statuses for your pipeline

Statuses in ShotGrid aren’t for decoration — they let you understand a task’s situation and who should act next in 10 seconds. Start from the stages of your process: modeling, UVs, texturing, rig, animation, FX, comp, sound, editing. Stages describe the work; statuses describe the state of the work.

Good rule: have fewer statuses than stages. You might have 15 stages and 6–8 statuses. This keeps the system from becoming a collection of tiny labels no one understands.

A common basic set is:

• Not started (pending)
• In progress
• In review
• Needs fixes
• Done (approved)

Next decide what is global and what stays within departments. Shared statuses should mean the same for modeling and comp. Internal states like “building cache” or “render in queue” are often better tracked as a field, tag or note than as a separate status for each team.

For statuses to work, record rules for transitions: who changes status and when. For example, an artist moves a task to “In review” only after attaching a reviewable version; a supervisor moves it to “Needs fixes” or “Done.” The producer monitors schedules and risks but doesn’t touch working statuses.

Test rules with a real case: a texture artist creates the first version, sends it for review, gets notes, moves it back to work, re-sends and gets approval. If extra statuses appear on that path — remove them. If one state is missing (e.g. “Blocked”) — add it only when it solves a concrete problem.

Roles and permissions: keep it simple

Set permissions by roles, not by individual people. Then when people change, you change the role assignment instead of rebuilding the system.

Start with 3–6 roles that really exist in production. Usually producer, supervisor, artist and client are enough. Contractors are a separate role even if they do the same work: the difference is usually trust level and what you can show them.

Then link roles to access groups and entity visibility. The logic is simple: a person sees only the projects, shots, tasks and versions they need for daily work. An artist doesn’t need to see budgets and internal planning fields; a client shouldn’t see other teams’ shots or internal notes.

To keep permissions sane, answer a few questions in advance and stick to them:

• Who can change task statuses — only supervisors or artists too?
• Who can create Versions and publish them for review?
• Who can write notes visible to everyone, and who only within their team?
• Which fields are “internal” (e.g. reasons for delays) and are hidden from external users?
• Who can delete or rename entities?

For external users follow “least necessary access.” Clients usually need to view tasks and versions, leave comments and participate in approvals, without changing project structure. Contractors typically need only their tasks, the ability to upload versions and communicate about them.

A small guideline on roles: the supervisor sees the whole project and sets final statuses; the artist marks a task “ready for review” and uploads versions; the client sees selected shots and leaves feedback. This reduces accidental edits and eliminates questions like “why do I see this?” and “why can’t I do this?”.

Notifications and subscriptions: so nothing gets lost

Notifications in ShotGrid aren’t for control, they’re for speed. A good setup ensures important things arrive immediately and everything else lives calmly in the project feed.

First identify events that truly require reaction. Usually these are enough:

• task status change (e.g. “In progress” → “In review”)
• a new comment with a mention
• upload of a new version
• assignment or reassignment of a task
• deadline change

Then decide who should receive them. By default notifications often get spread to everyone and become ignored. A working rule: the assignee, their lead and the person who created the task receive the notification. Others subscribe if they really need to follow.

To avoid email spam, split channels: urgent goes by email, everything else is a subscription in ShotGrid (to a task, shot or playlist). Practical rule: email only when lack of reaction will halt the process.

Example: an artist uploads a new version and sets status to “In review.” The supervisor receives a notification, leaves comments and sets the status to “Needs fixes.” The artist sees this immediately and the work doesn’t stall for a day.

Comment etiquette saves hours: post one action per message (what to fix or confirm), add context (where to look: version, frame, element), set a due date or priority if important, and use mentions only for people who must respond.

Linking tasks to files on the server: a clear scheme

For ShotGrid to really help, every file must have a clear place on the server and every task a simple answer to “where is the current version.” Without this, people start sending “final_definitely_final_3” in messengers and waste time.

Start with a single folder template for all projects. It should be the same for editing, graphics, sound and 3D, even if some folders aren’t used in a given project. This reduces mistakes and makes searching easier.

An example scheme easy to explain to the team:

• 01_Source (sources: camera, audio, references)
• 02_Work (working files by task)
• 03_Renders (renders, previews, playblasts)
• 04_Publish (approved versions ready for handoff)
• 05_Delivery (finals for client delivery)

The next important step: link the result to the task in ShotGrid, not only in people’s heads. On a task card keep at least three things: the folder path, the filename according to the rule, and the current version. For example: Project/02_Work/Shot010/Comp, Shot010_comp_v012.nk, v012.

To make folder contents clear, keep a simple separation: sources live in 01_Source and are not edited; working files are only in 02_Work; previews and test renders are in 03_Renders; anything considered “published” goes to 04_Publish. Finals for the client go to 05_Delivery and shouldn’t be mixed with working files.

Make the “single source of truth” rule strict: the current file is checked in ShotGrid in the Published/Version entity (or your “Current file” field) where the path and version number are shown. If a file isn’t published or attached to a Version in ShotGrid, it’s not yet part of the pipeline even if it exists on the server.

Step-by-step setup from zero in one sprint

If you allocate one sprint (usually 1–2 weeks), you can get ShotGrid ready so the team starts working in it instead of “sometime later.” Focus on the minimum and test with a real example.

Sprint plan: from an empty project to a pilot

Start with a skeleton and grow it with checks.

First create the project and agree on work stages. Then set a short list of statuses (for example: To Do, In Progress, Review, Approved, On Hold) and decide who changes a status and when.

Next prepare task templates for Assets and Shots. Better to have 6–10 typical tasks per entity than 30 “just in case.” Templates save time and reduce manual errors.

Then assign roles and responsibilities. Each task should have a single owner, not “everyone somewhat responsible.” Immediately enable subscriptions to key events: assignment, status change to Review, comments, and review rejections.

Finally, lock down the server folder structure and naming rules. Example: Project/Assets/Character/Name/Work and Project/Shots/Seq/Shot/Publish. It’s important that ShotGrid references the same paths, not “where someone keeps things.”

After the basic setup run a mini project for 1–2 days: one Asset and one Shot through a single edit cycle.

During the pilot you’ll quickly spot what needs fixing: too many or missing statuses, duplicated or unclear task names, noisy or missing notifications, naming rules that fail in practice, and links to files that point to different places or break.

Fix weak spots immediately after the pilot, and only then extend templates and rules across production.

Common mistakes and traps during rollout

The main problem with ShotGrid adoption is not that “the system is complex,” but that team rules don’t keep up with the configuration. As a result people stay in spreadsheets and messengers and ShotGrid becomes “for reporting.”

Mistakes that break the process fast

The process often falls apart for a few recurring reasons.

There are too many statuses and some mean the same thing. For example, “In review”, “Waiting review” and “Lead approval” differ only by name and the team argues about which to pick.

Permissions are set so that a user can’t perform basic actions: attach a version, change a status, or write a note to the right people. Then they post everything to chat and the system has no record of it.

Notifications are enabled “for everything for everyone.” After a few days most people turn off subscriptions entirely and important changes stop being noticed.

Files and renders are stored in different places: someone’s disk, a shared folder, or the cloud. The task doesn’t have a clear link and searching becomes a quest.

There’s no naming and versioning rule. As a result “final_final_2.mov” can’t be reliably mapped to a task, shot or specific fix.

One simple example: an artist uploads a preview to ShotGrid but keeps sources locally. The supervisor marks “Needs fixes” but can’t determine which version to fix because the task lacks a folder path and a consistent filename format.

The antidote is simple: a limited set of statuses per entity type, 2–3 roles with clear permissions, notifications only for assignments and status changes, a unified storage scheme (where sources, previews and finals live) and a mandatory link or publication to the task. Once basic discipline is established, it’s safe to expand the system.

Quick pre-launch checklist

Before you tell the team “we now work in ShotGrid,” run a short 20–30 minute check — it saves days of fixes after go-live.

5 checks that catch 80% of problems

• Each task has an owner and the due date looks realistic. Tasks without owners or with “sometime” deadlines will almost certainly stall.
• Statuses are interpreted the same way across departments. Ask 2–3 people in different roles to explain what “In Progress”, “Review” and “Approved” mean. If answers differ, clarify names or descriptions.
• It’s clear what happens after a status change. For key transitions (e.g. “Ready for review”) it should be obvious who’s next, what they do, and what result is acceptable.
• File paths are visible where people actually look for them. Open a task card and check: is there a field with a clear path, version name, or folder link that matches how the team opens materials in practice?
• Notifications aren’t noisy. Do a test: change a status on a task and see who gets notified. If “the whole studio” receives it, people will start ignoring everything.

A live test works best: take one typical task (e.g. “render shot” or “prepare layout”), run it through all statuses and confirm that every step is clear without chat explanations.

Example scenario: a small project from start to delivery

Imagine a short commercial: 10 shots, a team of 6 (producer, supervisor, 2 artists, compositor, editor), two-week deadline. ShotGrid helps because everyone sees the same thing: what’s done, what’s in review, where fixes are and where current files are stored.

Keep statuses consistent in meaning but allow different steps inside departments. Modeling may need a separate asset approval step; animation may need a lock state.

A readable set that works across departments:

• Not Started
• In Progress
• WIP Review
• Client/Sup Review
• Changes
• Final

How it looks for one shot: an animation artist creates Version v001 and sends it to WIP Review. The supervisor comments directly on the version (frame-precise if needed), sets Changes and specifies what to fix. The artist releases v002 and the cycle repeats. When the shot is accepted, the task moves to Final and the compositor immediately knows which approved version to use.

To onboard someone in 30 minutes the most important thing is a simple, consistent server structure. One working example:

/PROJECT
  /shots
    /sh010
      /anim
        /work
        /publish
      /comp
        /work
        /publish
      /review

Rule: only items that match a Version in ShotGrid (filename and version number match) go into /publish. /work can hold drafts, but they mustn’t confuse the team.

Measure two things at project end: time spent finding the correct file or “latest version”, and the number of extra fixes caused by version confusion or incomplete comments. If these metrics drop even on a small project, statuses, notifications and file structure are working.

Next steps after the pilot: lock the process and infrastructure

A pilot reveals both ShotGrid benefits and team habits: who forgets to change statuses, who posts comments in the wrong place, who keeps files locally. To make the system a process backbone, record the rules and avoid changing them weekly.

Freeze rules and reduce friction

Right after the pilot gather short feedback: what hindered, what saved time, where questions appeared. Then “freeze” status rules for 1–2 months. This gives the team time to adapt and provides you with real data on where statuses work and where a new state is needed.

Write a one-page mini-regulation. It doesn’t have to be perfect, but it must be clear:

• who can change which status and when
• how to name versions (e.g. shot010_comp_v003)
• where working files and finals live
• what to always include in handover comments (which version to check, what to review)
• how to act when blocked (who to contact, which status to set)

Support the process with infrastructure

When tasks tie to files, infrastructure weaknesses surface fast: access rights, network speed, lost versions, missing backups. Check three things in advance: reliable storage (server or NAS), regular backups and clear folder-level access roles.

If you need an on-prem approach (local storage, security requirements, heavy scenes), discuss where production will be stored, how workstations connect, how copies are made and who manages access.

Sometimes it’s convenient to centralize infrastructure and support. For example, GSE.kz (gse.kz) as a manufacturer of servers and workstations in Kazakhstan and a system integrator can cover basic hardware, rollout and ongoing support so your storage and access scheme doesn’t fall apart in a few months.