Hi Shotgun,
Can I please have back the ability to choose my CustomEntity? We use different numbers depending on the purpose, and now they are hidden today!
Unused custom entities will now be hidden to make browsing the list easier in Site Preferences [SG-20671]
Can you please put them back until you can come up with a UI that allows you to collapse the unused list?
Thank you!
Den
Hey, I’m just going to move this over to the Shotgun category for better visibility.
Thanks! Looking forward to an update
Plus 1 on this request from Den – we add custom entities for different things as we get further into a project, and would like them back until you have a solution to collapse and reveal. Please.
PS - we are stuck right now until we can add a new custom entity. Please update on this.
Another plus1. The update says unused custom entities will be hidden, but I’m also seeing ones that are used being hidden.
Same here. I discovered this accidentally. But we need the unused custom entities back in the place till you guys have an solution to deal with it. If it’s hidden then in the current scenario how to enable one of them even for test purpose. Kindly update on this…
Hi @shotgun! Just checking in whether this is on your radar now.
Thanks!
Den
Hi @dennisserras,
As you noted, it is a new feature so as not to overwhelm the entity page with a full long list of custom entities that you are not using. Now you enable one at a time and the next in line will be revealed on the page when you save your preferences after each enabling.
So in my image you can see the last CustomEntity enabled was “Card” which is using “CustomEntity06”. Then below, you see the next available to choose from is “CustomEntity07” which is greyed out because it is not yet enabled (or you can choose the next non-project or threaded entity). It also gives you a count for how many of each entity type is remaining.
So to enable an entity, you expand the arrow beside the one you want to enable like you always would, give it a name, enable Tasks or versions as needed, and then Save Changes. Once you save, you will see the next CustomEntity reveal itself for you to enable if you choose.
Hope that helps! If you have any feedback, please let us know on the roadmap.
Cheers,
Beth
Also, I did find a bit of an easter egg with this which might be helpful if you need to reveal more than one hidden CustomEntity at a time.
If you open the next entity available and give it a new name (but don’t enable it) then Save Preferences - it will take it out of the hidden list. You can keep doing that to reveal many that are hidden, but not enabled, if that’s at all helpful. I’m not sure if this is a bug, but feel free to exploit it as you like 
Update: turns out that it’s by design to be able to reveal non-enabled entities by giving them a name
Hi there. We made this change to future proof how custom entities will work going forwards, including opening up the possibility to allow for unlimited custom entities at some point. I appreciate that there are some things such as the ability to easily choose a particular custom entity to enable which are now gone, but we are looking into some options which might bring some of that flexibility back.
Hi Jack and Beth,
Thanks for the explainers (and the possible workaround). My suggestion would be to use the way it has been for the last 12(?) years until you have the replacement for it ready. The nerfed system which I assume was developed for new customers is understandable, but I think the compromise between removing confusion about new entities and making custom entities difficult to use really errs on the side of difficulty. If you want to make it more intuitive, don’t put the unused entities in-line with the others at all but put it at the top or bottom of the list with something like a [+] or “new entity” or something similar, where you can choose the entity number and the icon. That’s more similar to how the rest of the site handles new items and more in-line with how other sites treat this problem. As it is, we’ve lost the ability to manage custom entities (unless we use Beth’s hack) with what is in my opinion very little UX benefit.
I vote you revert it until you can actually solve the UX problem, and not do half-measures which don’t make it better for power users or more intuitive for new users.
Thanks!
Den
Hi Den, I appreciate you sharing your perspective here, thanks.
Names are important.
IMO as long as the CustomEntityN is visible in the API, that N matters and people should be able to choose it.
Ideally from the beginning, Shotgun would have abstracted the underlying table name, and made people choose a unique camel-cased code, which would then be used for the default DisplayName. Right now, all custom entity types in the API are exposed as CustomEntityN, and in the UI it’s a mix, which is needlessly inconsistent and confusing. And why should devs have to commit Custom Entity numbers to memory?
Ideally for all new sites, people could choose a unique code and that would be the only name visible in the API.
For existing sites and backwards-compatibility, you could continue to allow people to query on CustomEntityN forever, but give the option of assigning a unique code. In most cases, I’m guessing people would use the DisplayName for that.
Just wanted to chime in here; I agree with Den and Jonah, and this is my use case: at our studio, we have several SG sites for different sets of projects that all share a codebase. It’s important for us to keep the CustomEntities consistent, because they are referenced by their “CustomEntityN” name in API code, not their display name, so if the numbers are different, we have to account for this in our code, which is super messy.
The workaround I was offered by SG Support was “You could manually enable the 24 entities and then disable again the first 23.” Not false, but not a great solution.
