ID: 2324

Zoom Project & Folder Schema Setup Best Practices

Target Audience: Super-admins, Super-users, Project-Admins

 

Below are a few sample folder schema you can draw inspiration from for your initial Zoom folder/project structure setup at the beginning of the Zoom project. This article presents the best practices for using Zoom projects/folder structure based on scenarios encountered by various Evolphin Customers.

Common elements – stock images, video footage files, fonts – that are shared across creative projects/jobs are often organized into a “Library” project. Inside the project sub-folders that are vendor-specific or file type specific can be created to bucket files.

 

Highly recommended to create 2-4 deep folder hierarchy to reduce number of files per folder. While Zoom Server has no performance issues with storing millions of files per folder, list command (not search) in a Zoom Client, an external OS File System Browser using a Drive may have difficulty browsing too many files inside a folder. When navigating using Asset Browser with a browse mode that performs a list command, users will have serious performance issues with large number of files (over 2000 but depends upon the client machine specs & network speed).

For instance by organizing the AP Photo/ folder into monthly intake folders allows us to reduce the number of images inside the AP Photo/ folder.

 

Besides monthly sub-folder schema, you could organize by topic or show. Do not need to create deeply nested folders as Zoom will allow metadata to search and locate assets. Just sufficient to keep the number of files per folder to a few thousands. This is not a hard and fast rule, if you never plan to use our future OS file system drive, then go crazy and store million files in a folder, Zoom server has no performance penalty.

Beside the library assets, the day to day work in progress production assets need to be organized. Here are a few best practices we have seen:

In this model, the administrator creates a single global Zoom project and maps all the users to a project. Roles are assigned based on access level that needs to be granted: designer, retorucher, art-director, client-services etc. Under the project root folder, client or job-specific top level folders are created:

Project sub-folder organization by a job id:

 

Project sub-folder by asset type:

In the above image, you can see project sub-folder broken down by file types such as 3D, After Effects, Static Images etc.

 

Pros

  • Do not have to add users to a new project every time a project is created. In a fast paced creative team which executes thousands of projects every year creating and managing multiple projects may become a chore.
  • Security and access control needs to be managed only for a single project
  • Shared notification for all activity under a single project
  • Less administrative burden

Cons

  • Desktop status notification is per project, users will be notified of all changes in a project unless they turn off notification/monitoring for the entire project in client settings
  • Accidentally update the project will cause all project folders to be checked out
  • Delinking project root will cause all job files under that root folder to be delinked on the desktop. Need to be careful about checking out individual project job/client sub-folders to different working copies to ensure sub-folders can be delinked. (Delink allows Zoom to free up space used to manage the checked out working copy, for large job user may not want jobs occupying space after they are finished)

When to use

  • You have a team that works together on every job
  • You do not wish to assign users to project again and again

Each client is mapped to an individual project in Zoom. Administrators have to setup a project root folder for each client.

Pros

  • Allows permissions to be controlled on a per client basis.
  • Clients can be given access to the section of the repository that hosts their jobs
  • Desktop notifications filtered by client project
  • Creative directors or Project leads can manage their own set of client projects

Cons

  • Manage multiple projects – more administrative burden
  • Multiple jobs under the same client project will cause desktop notifications to go out to potentially all team members, even if they are engaged on different jobs

When to use

  • When you have a large team that is assigned to a specific client
  • You do not have too many jobs being executed in parallel, for a single client
  • Remote access to a client is required

In this model each job is mapped to its own project. Administrators have to setup a project root folder for each job.

Pros

  • Allow fine grained access control on a per job basis
  • Desktop notifications filtered by each job, teams not working on another job do not see the notifications or assets associated with other jobs
  • Freelancers and clients can be granted access to the repository on a per job basis
  • Per job project reporting can be performed

Cons

  • If you execute thousands of jobs every year, this model can impose too much project administration overhead

When to use

  • You have long running large jobs that are accessed by internal and external users
  • You don’t have thousands of active jobs – project administration per job is not much of a burden

If you are importing a large volume of images, photos on a daily basis and wish to move assets into meaningful folder structure using a Quality Control (QC) job for instance, Zoom offers a few possibilities:

  1. Initial Check-in or ingest can bring assets into an unprocessed QC staging project folder on Zoom.
  2. Then a periodically scheduled job could automatically go over the ingested files, read the metadata associated with the file and create sub-folders to move them to appropriate directories in an automated fashion

Here is a visual of such a sample process:

 

This requires automation to be written & setup but using Zoom APIs it can be done relatively easily.