Prevent folder creation depending on Asset type


I have a certain asset type that I’d like to prevent certain folders from being populated in on folder creation.

For example I have a scripts directory that should only be created for a certain type of asset. I added a scripts.yml file alongside of it. The parent directory of this files is called “Asset” where it will dynamically pick up the name of the asset type when run.

in the scripts.yml file I have:

type: "static"
constrain_by_entity: "$asset"

    - { "path": "sg_asset_Type", "relation": "not_in", "values": ["Stuff"] }

Where $asset is my parent folder (I assume) and I’m trying to say with the constraints “Hey, don’t create this folder if you are of asset type Stuff”

However this does not work as expected and I get the error when I run this create folders hook:

\blah\blah\blah\scripts: constrain_by_entity '$asset' could not be resolved into a parent node. It needs to be on the form '$name', where name is the name of a parent yaml configuration file.

Where I have no idea what “name” it’s referring to.

Any idea where I’m going wrong?



Any takers on this? There seems to be some significant gaps in the file system reference documentation.
From the section on static folders in

#pick one of the shotgun folders that are above this folder
#in the folder hierarchy. In this case it is a parent folder
#named step that we want to look at when deciding if this
#static folder should be created or not.
constrain_by_entity: “$step”

$step is referring to an actual folder named step? A shotgun field? a yml file? I can’t make heads or tails of this. In my actual “asset” folder of my schema I have contraints defined by $asset that work (asset being the parent folder and I’m able to prevent creation of static directories by using constrain_by_entity: $asset. However in the folder above this (asset_type) I am unable to use $asset_type or $asset as the entity constraint.

The schema is (briefly) as follows:


  • asset_type
    – scripts
    – scripts.yml
    – asset (contains a Data folder and Data.yml)
    – asset.yml

where the Data folder only creates for certain asset types. However I’d also like the scripts folder to only create for certain asset types as well but it has to be be a parent of the asset_type folder.
Hence I thought “Oh, I should constain by the asset entity” but that just doesn’t work in this case.
So I literally thought that the constrain_by_entity variable wanted the name of the containing folder ie asset_type but that also doesn’t work.

What are the cases where constraints will work, then?


1 Like

Hey! Apologies for letting this one sit! What you have should work and matches what’s described in the File System Configuration Reference. I’m going to see if I can repro what you’re seeing (and figure out where it’s going south). Will report back!

1 Like

Hi again – I went through about three iterations of a reply here, and sadly, I’m not sure you can do what you’re seeking to do.

In the static folder creation code in tk-core, it’s actually taking the constraints value, “translating” its syntax a bit, and feeding it directly to a find_one() query in the Shotgun API:

If it doesn’t match the constraints, it returns without creating the folder.

It order to do that find_one(), it has to have an entity. So the parent folder that you’re basing your constraint on needs to be of type shotgun_entity. In your case, you do have a shotgun_entity folder, asset, but it’s not the parent of scripts, it sits parallel to it. And the actual parent folder, asset_type is not of type shotgun_entity, but shotgun_list_field. Which puts you in a bit of a bind.

I tried one other thing: You can manually specify a parent with the associated_entity_type setting. I tried setting that to Asset in scripts.yml, but I got the same error you did. It looks like associated_entity_type doesn’t work with static folders, but it may also be the case that you can’t specify a parent that’s not above the current folder in the hierarchy.

All that to say, I empathize with your frustration here. I’m going to run this by the team and see if anyone has any better ideas as to how to move forward here. It’s possible someone has some deeper schema knowledge than I do (the more advanced stuff is a bit of a dark art), but if not, I wonder if it would be as simple as supporting associated_entity_type for static folders.

I’ll keep you posted on what I find. Sorry it’s not better news!


Thank you for looking into this! Hopefully someone skilled in the dark arts has a work around.

While we’re on the subject, I’m also trying to create a dynamic step folder but only if the asset is of a certain type.

here’s the code for Design.yml (to be paired with a Design folder)

type: shotgun_step
name: short_name
    - { "path": "sg_asset_type", "relation": "in", "values": ["Editorial"] }

What I mean to do is make the folder named after the step only if the parent asset type is “Editorial”. The parent folder is Asset, btw.

Is there a way to make this happen?


1 Like

Hey there,

Any updates regarding my last post?


1 Like

Hey @StarkRavenSimone – apologies for the delay here, but here are some ideas that should get you going:

  • First off, to confirm what you saw, it looks like shotgun_step doesn’t support filter:. As steps aren’t actually normal project entities in Shotgun, they don’t really have a concept of a related asset/asset type.
  • Having said that, you could set up your desired directory structure by moving the branching up a folder. Essentially, you’d create two asset folders with different filter settings – one for the asset type for which you want a Design folder, and one for the rest.
    • To be more explicit, based on your example above, this means the two filters would look like:
      • { "path": "sg_asset_type", "relation": "in", "values": ["Editorial"] }
      • { "path": "sg_asset_type", "relation": "not_in", "values": ["Editorial"] }
  • From there, you have a couple choices:
    • You could create a shotgun_step folder within the first folder, or
    • You could have your asset.yml file actually represent two consecutive folders, as is described here.

The second is much simpler, but it wouldn’t be dynamic – you’d just be creating a folder called Design under the folder, for assets of type Editorial. This means that you wouldn’t have step in your context in Toolkit workflows either.

The first will give you the full functionality for a shotgun_step folder – you will have the step in your context. However, it’s a little more complicated, too: since you’ll have different folder structures for assets of different types, you’ll need to have separate templates for them, too. Eg, in addition to maya_asset_work, you’d have something like maya_asset_editorial_work. And in order to use those additional templates, you’ll need a whole separate environment for them. This means that:

  • You’ll need to create, in addition to shot_step.yml, asset_step.yml, etc., something like asset_editorial_step.yml in config/env/, which, where relevant, will point to the right templates.
  • You’ll need to modify the pick_environment core hook to make sure that it takes your new environment into account.

So, you can definitely get this to work, and this route is the more “correct” way to go. It complicates your setup considerably, but once you have it set up, it should work as you desire.

Hope that helps! Let us know if you have any other questions.


I’m not sure I entirely follow.
Lets say I have two folders at the same level, asset_type_a and asset_type_b. Each has its own underlying structure and a matching yaml file.
One yaml says to create this for “Editorial”, the other not.
I wrote up something similar and it’s still favoring the folder structure for asset_type_a. It completely ignores asset_type_b no matter the actual asset type.

In this case I’m using the shotgun_list_field and I’m not sure that can be used with filter.

1 Like

Hi again – I tested this out, and this is what worked for me:

Note: In my test, I used “Prop” as the asset type to have a step folder, just because that’s what I had in my project. In your case it’d be “Editorial”. And the goal was to have the following:


So, everything up to project/assets/asset_type/ remains the same as default. From there:

modified existing project/assets/asset_type/asset.yml so it looked like this:

type: "shotgun_entity"
name: "code"
entity_type: "Asset"

    - { "path": "project", "relation": "is", "values": [ "$project" ] }
    - { "path": "sg_asset_type", "relation": "is", "values": [ "$asset_type"] }
    - { "path": "sg_asset_type", "relation": "is_not", "values": [ "Prop"] }

I removed any folders below asset/.

Then I created project/assets/asset_type/asset_prop/ and project/assets/asset_type/asset_prop.yml, with the following contents in the yaml file:

type: "shotgun_entity"
name: "code"
entity_type: "Asset"

    - { "path": "project", "relation": "is", "values": [ "$project" ] }
    - { "path": "sg_asset_type", "relation": "is", "values": [ "$asset_type"] }
    - { "path": "sg_asset_type", "relation": "is", "values": [ "Prop"] }

I moved step.yml and step/ (and its subfolders) under asset_prop/.

That worked. When I created folders for jar (a prop), it created step folders. When I created folders for rocco (a character), it didn’t.

Does that answer the question?

1 Like

That works, thanks!
I just realized that this was a two-part question. At first I was a bit confused which part we were referring to. But this clears up the second part of the issue. Thanks!

I wonder though if it’s possible to do something similar with the Asset type folder since there are types that I want to have a different folder structure for.

Since I’m using shotgun_list_field in my asset_type.yml file, does that prevent me from using the same filtering as we used on shotgun_entity?


Hi –

You can’t do filtering within a yaml file for a folder of type shotgun_list_field. The settings it supports are:

  • type
  • entity_type
  • skip_unused
  • create_with_parent
  • field_name

(as documented here and seen in the code here.)

But again, even though we did our filtering in asset.yml above, we were filtering on asset type. So, I think (unless I’m missing something) functionally you’d get the result you’re after with the approach described above.


In this case it’s with a static folder. The same idea does apply. Certain asset types will get the subfolders and others not.

The only thing that’s keeping this from working is the folder name. It should remain static. Using shotgun_entity seems to be the only way to make this work but I have to make the folder name dynamic (I think). Is there a way to “trick” the name into being static instead of being referenced from an asset field?

If I try to do this as a static folder I get an error constrain_by_entity '$Asset' could not be resolved into a parent node.
Maybe this goes back to something that was not possible to do in the original post but is there a way to get the constrain_by_entity to recognize an Asset type and how to I constrain by the asset type?

Here’s my example in scripts.yaml (it’s more or less the same as the example in the first post):

type: “static”
constrain_by_entity: “$Asset”
- { “path”: “sg_asset_type”, “relation”: “not_in”, “values”: [ “Editorial” ] }


1 Like

Can someone update this url link from above please? It’s not linking to anything useful.

I think it should point to for the benefit of others.

1 Like