Project Tracking Settings

Tracking Settings provide a place in your project to configure which entities, fields, Pipeline Steps, and statuses you’ll be using. These settings make it possible to support different projects with different pipelines and tracking needs within the same Shotgun site.

Tracking Settings


Entities are the building blocks of a project. If you’re making a film, your project will use the Shot and Asset entity types. If you’re making a game, you might use Assets and Levels. Not every project needs every entity and some projects require custom entities, and so you can choose to only show entities your project is using.

You can hide or show an entity from your project via the left pane of Tracking Settings.

Hiding an entity type will affect the project in the following ways:

  • Hide the entity type from the project navigation configuration screen.
  • Hide all pages for the entity type (e.g., project navigation pages, pages in the “Other” menu, pages in the “Pages” menu).
  • Prevent users from creating new pages for that entity type.
  • Prevent users from creating new records of that entity type.

Tracking Settings

You can also set a default Task Template for your entities. For example, you can create a default template for your Assets. This means that:

  • When you create a new Asset, if the Asset Task Template field is visible on the Asset Form, it will be pre-populated with the specified task template.
  • If the Asset Task Template field is not visible on the Asset Form, the specified default task template will be used.


Fields keep track of important information on the entities you’re tracking. Each entity type has some core fields that are consistent across entities (e.g., description, name, status, etc.), but you can add your own. Although two projects may both track Assets, each project may track different information on Assets. This is particularly common at studios that work on both films and games.

You can hide or show fields on entities by selecting an entity type on the left and toggling field visibility on the right.

Toggle fields

Hiding a field will affect the project in the following ways:

  • Hide the field from all “Fields” menus.
  • Hide the field from all pages and detail pages.
  • Hide the field from all forms.
  • Disable the field from any queries or filters where it’s used.
  • Disable the field from any page formatting rules where it’s used.

Pipeline Steps

Pipeline Steps show up on entity types that can have Tasks. These are typically entities where you’ll create and assign Tasks. Pipeline Steps help organize Tasks into categories that can be displayed as columns on reports or pages for the entity. Just like fields, you may not need all the Steps on an entity for your project, so you can toggle them off.

Toggle steps

Hiding a step will affect the project in the following ways:

  • Hide the step from all “Pipeline” menus.
  • Hide the step from the Pipeline Step field on Tasks.
  • Disable the step from any queries or filters where it’s used.
  • Disable the step from any page formatting rules where it’s used.
Note: Hiding a step WILL NOT remove the step from any Tasks where it is being used. You'll need to manually change Tasks to a new Pipeline Step by going to a Tasks page, searching for Tasks with the Pipeline Step, and editing them.


Each entity type has a set of statuses to help track a record's status. Statuses can be used to track approval on Versions, the stage of a Task, or anything else you need to track. Different projects call for different workflows, so you can hide and show statuses differently per project.

Toggle status

Note: Some entity types may have more than one status field. You’ll see all an entity type’s status fields in this section.

Hiding a status will affect the project in the following ways:

  • Hide the status from its status field.
  • Disable the status from any queries or filters where it’s used.
  • Disable the status from any page formatting rules where it’s used.
Note: Hiding a status WILL NOT remove the status from any records where it is being used. You’ll need to manually change records to a new status by going to the entity type’s page, searching for records with the status, and editing them.


What happens when I change Tracking Settings for my project?

Changes you make in Tracking Settings are saved immediately. Everything you change can be changed back without data loss, so don’t worry if you make a mistake.

Once you make changes others users might notice the following changes in your project (see above for specifics):

  • Fewer entities appear in a project’s “Other” menu.
  • Fewer entities appear in the project navigation bar.
  • Fewer fields appear in the Fields menus.
  • Fewer Pipeline Steps appear in Pipeline menus.
  • Fewer statuses appear in your status fields.
  • Pages may show more records since filters have become disabled.
  • Pages may change color since formatting rules have become disabled.

In general changing your Tracking Settings will simplify your projects.

What about creating new fields, steps, and statuses?

When you create a new field or Pipeline Step, you’ll be prompted to choose whether to:

  • Show the field or step in all active projects—this adds the new field or step and immediately toggles it visible in any project that is not archived or deleted.
  • Show the field or step in the current project—this only adds the new field or step to the current project you're in.

New pipeline step

What does the error message “create failed (reason_code 3): Invalid project: project [] does not exist.” mean?

This message often comes up if you have hidden a status for a < a href=">global page. The global page does not specify which project to hide the status, which causes the error.

Error message

You can still hide a particular status. Just make sure you are configuring the status from a project page.




  • 0
    Louai Abu-Osba

    Does this effectively encapsulate the schema on a project basis, allowing for different Toolkit configurations as well?

  • 0
    Ryan Mayeda

    Hi Louai!

    What do you mean by encapsulating the schema on a project basis for Toolkit configurations?  Note that the Project Tracking Settings don't remove fields from db, so if your configuration tried to use a hidden field in a folder name or template with Toolkit, it could cause some odd behavior...


  • 0
    Ben Hadden

    And to further add to Ryan's comment, the API will not have awareness about which fields are hidden in a project when we first release this. Though we do plan on adding that post 5.4 in a patch release.

  • 0
    melanie zaffran

    my only comment is that different projects may end up creating similar fields without knowing it, if they are hidden on both sides (which I know already happens, even with all field being visible, just because people will name the same thing differently). Would there be a way to include a "warning" or some sort of notification when trying to create a new field that potentially already exists, but might be showing in a different project? Just a thought...

  • 0
    Ben Hadden

    Hey Melanie,

    That's a great point. There's a couple ways we help users not make the mistake of recreating fields that already exist:

    1) Whenever you try to create a field with the same field code as another (which typically means you're using the same field name), we'll warn you that a conflicting field already exists, even if it's hidden in the current project.

    2) Before you add a new field, we force users to go to "Manage Fields...", which shows the full list of custom fields on an entity. This is so users can see if a field has been hidden in the current project.

    Of course, this won't block every case. I'm curious to hear if you've had occurrences of users recreating fields on your projects. If you could describe how it happened, I'd love to add in more "checks" to make sure it doesn't.

  • 0
    melanie zaffran

    Hey Ben

    After looking a little more closely at the new feature, i agree that the way it's set up allows people to be aware of what is already available.

    the particular case I'm thinking off was a query field created to retrieve the number of characters in a shot. The field already existed under the name "Num character", but because that field name wasn't necessarily straight forward to other users, the same query field (same filters) was created a second time with the name "character Count".

    so having a check that notifies of a field with identical settings (maybe 75% of the criterias are the same) would be helpful i think. I say 75% because even if the filters don't match 100%, a pre-existing field might still be good enough, or just need a slight change to work for more than one project...It wouldn't necessarily block creation of a new/identical field, but bring attention to existing ones.

  • 0
    Mahendra Gangaiwar

    can i query what are all the entities are allowed for a project through API? I tried fetching it from Project.tracking_settings but its giving me navigation information. Basically I want to do few operations on the basis of the visible entities(which are operated from project tracking settings) on project startup.

Please sign in to leave a comment.