The existing Subject that is created for notes added in the Creative Review app is useless noise for us.
Note on Version-1288876 and Task-3415741
This means nothing to anyone.
Could we have it use the entity names instead? This would be an easy and immense improvement.
Review Note on GPLS544_00B_0030_Sb_v01 (Storyboard)
+1 from me!
Jumping to link to this other thread from last year with a similar regard… One day we’ll get the notes we deserve! 
Thank you everyone for your feedback on this we are looking into our notes workflow in general at the moment so this discussion is very helpful. I have logged this as an improvement and had a few follow up questions.
Would this be something you would want to customize a default subject format per site/project or is the naming convention you provided a good default overall?
And is there another information you would want in the subject that is related to the parent entity, version, task, pipeline step, etc.?
For us…
Sure having a bit of control over the configuration of how these are titled would be great. But what is more important for us is having something that is readable and consistent. There are other ways to add notes (screening room, RV, etc) that I didn’t test/list here so this isn’t exhaustive, but this is an example of 3 different ways Note Subjects appear.
Seems like we’d want consistency and control at least around how notes subjects are titled for:
Would be happy to have @alfonso and others chime in with their thoughts as well. They may have additional desires. Again for us it’s readability and consistency.
<Playlist Name> - <Month Day>ABCD252_Color_ClearanceReview_20250708 - July 8th<Author>'s Note on <Version Name> and <Version Link>Kevin Porterfield’s Note on ABCD000_000_0000_Ds_v01 and ABCD000_000_0000<Version ID> and Task-<Task ID>Note on Version-1665408 and Task-5200769Hey @contardom and @kporangehat!
Sorry for the late reply, and happy new year!
I’d suggest ditching the {first_name}'s note on format for something more direct. Since auto-named notes only include the author’s first name, things get confusing fast when multiple people have the same name. The Playlist naming adds that extra date in natural language at the end which can be very annoying to parse and the rest are just plain annoying.
On our studio, we use a webhook script that renames notes like this: {project_code}_{YYMMDD}_{author's department}>{recipient's department}_{link(s)}
This lets us quickly identify where the note comes from, where it goes, and what asset(s) it covers without digging through multiple fields or dealing with convoluted filtering. (i.e. it is pretty easy to know which are all the director’s notes by just searching dir> instead of doing some deeper filtering in the filters menu (specially when there are multiple people))
As mentioned in the thread I linked and as @kporangehat listed, the current inconsistency makes sorting through notes REALLY difficult (we switched from regex matching to auto-naming every new note because of this). The Creative review naming is particularly unreadable using the IDs.
Our convention isn’t perfect. Multiple recipients from different departments become “MULT”, and people without assigned departments get “NA”. But it’s flexible enough for our small studio setup and centralized in a single config (though notification emails get sent with the original naming, which SUCKS).
For implementation, I’m thinking about a block-based approach where each block represents either a field or custom text.
Hope this helps clarify things. Cheers!