How to set field code names

Hi there,

Not sure how exactly to title this post. I have two assets in Shotgun that I would like to link, but not through the usual Sub-Asset structure. The idea is that we have a prop (a pillow, fwiw) that can also be a set-dressing asset (respectively called prp_pillow and sdr_pillow). We would like the actual modelling/surfacing work to be done on the prop, and for some proxies to be generated for the set dressing asset at the same time.

The way I’d like to handle it is to have a field to link the prop to the set dressing asset, so I created a field “Propify” on Assets in our SG site. I enter “sdr_pillow” into the Propify field on the prop asset, and I can access this through the API under “sg_propify” on the Asset entity. So far so good.

However, I also want to be able to warn the artists if they are about to start working on a set-dressing asset that is linked to a prop asset, as they should be working on the prop itself. However, when I try to find the inverse of the link (to find the prop from the sdr asset), the field name is “sg_asset_3”. This seems a little arbitrary and non-intuitive.

Is there any way to change this field code? Or how can I go about it so that the field code is something a little more sensible?

I hope this all makes sense and that I’ve explained myself ok…




For each entity or multi-entity field you create Shotgun automatically creates what we on the team call a reverse field. This reverse field is always a multi-entity field and it’s name is automatically derived from relevant context.

In your case the reverse field is called sg_asset_3 because it is referring back to the Asset entity type. It is also suffixed with the number 3 because field codes are required to be unique and this is probably the third time you create a field which would have been called sg_asset.

Unfortunately this can’t be changed as field codes are immutable and are referenced in many places in the application like other fields, page setups, queries, filters, etc…

I know some people that have written API wrappers have built aliases to expose more friendly names that automatically get translated. This is something you can do but otherwise you’re kinda stuck with it. :cry:

I know this doesn’t address your issue but hopefully the context helps you understand the why of it all.


Hi Patrick,

I had guessed this might be the case, thanks for confirming and for all the info! I can wrap the queries for that particular field in a wrapper function in our tools here. The reason I asked if it was possible is that I have some junior colleagues here that will be writing code to interact with SG, and this might be confusing for them, but I can make them aware.

Thanks again!