Our studio has pretty much completely overhauled our status workflow. I thought I’d share for those curious about how some studios manage statuses. We’ve linked Version statuses to Task statuses to Shot Statuses. The philosophy behind this is as follows: Shot Statuses are the overview status - used for clients and execs. Task statuses are used by Coordinators and Artists, and version statuses are used for the review process by Artists and Supervisors.
All you need to know, is that BKD Note means “Internal Note”.
I’m curious to hear people’s thoughts, questions, recommendations. Special thanks to @mmoshev for pointing us in the direction of Webhooks.
6 Likes
I really appreciate how you visualized this, related each set of Statuses to each other, organized them into what looks like a linear order toward completion, and categorized the Statuses into general groups. Great context cues and clear separation of responsibilities.
I was curious about one thing – was there any particular reason to have a different final Status for the different entity types? i.e. the bottom-most Status on Shots is Final, on Tasks is Delivered to DI, and Client Approved on Versions.
1 Like
Hi Jon, thanks for your incredibly thoughtful response! haha
The short answer, is that I’ve been thinking about adding Final as a task status to let artists know that a shot has been basically, approved by DI. But since we have it set up that Delivered to DI takes the task off the artist’s dashboard, it’s less important. For reasons I describe below, it makes less sense for us to use Final as a version status.
To answer your question in depth, I can explain my thinking about how I see the different entities and the roles they play. Versions on SG, for our studio, play the role of a low-res review which we review internally and send to clients - so technically, you never deliver a version to DI, since versions are low res, you final it when it’s client approved - which triggers the ready for hi-res task status, which tells the artist it’s ready to go. Furthermore, it triggers the Shot Status, Client Approved which we have linked to a client spreadsheet - here - so the thinking behind shot status is what’s relevant to Client and Execs, and DI, so the distinction between delivered to DI and Final is relevant here - where it’s less relevant in Tasks, and not relevant at all in Versions.
1 Like
I had to implement something similar over here. I would get batches of notes from a client in a spreadsheet, so I looped through each row and looked for certain keywords, like, “final” or “good” or “make it suck less”. Final in a client note means that the version is approved, the task is complete, and the shot is final. I ended up doing this with the old-school SG events daemon though, since it was before WebHooks was around.
Speaking of WebHooks, care to share the technical details of exactly how you implemented a WebHook? I was wanting to do something with AWS Lambda, but I had some performance concerns with regard to caching entities, etc.
Just used the built in Webhooks feature and some python scripting with the statuses mapped out. See here: Webhooks - SG Developer
I’d tell you more about our python code but I’m not the software engineer who did the work. Good luck to ya!
Thanks for the response! Yeah, I was looking for specific details on how to configure these, more on the AWS Lambda side - like, has anyone actually implemented a WebHook with Lambda?
Yes, you can use AWS Serverless framework to easily configure these.
It configures the lambda and api gateway routes for you.
