Hi William! I was browsing the Community when your thread caught my eye and I wish I had seen it around the time of your original post. I am curious to learn of your progress since this time and also have an opportunity to explain a bit further around the concept of the Virtual Instance ID (VIID) as presented last year at LEAP.
This problem often gets clouded between instance partitioning and departmental delineation. The approach I laid out at LEAP was strictly about instance partitioning and a way to allow your Workfront environment to scale effectively. The idea behind a 2-character VIID prefix (strictly numbers) is to hide complexity in simplicity. It is a common failing to try to overpack information in a prefix to convey information, but the idea behind the VIID is not to convey information per se, but to offer virtual partitioning. In the same manner that you will not have a Workfront instance for each and every department or sub-department, you will not have a VIID for same. A good way to think of it is, as each new entity starts their new Workfront subscription, they will inherit a new sequential 2-character numeric identifier, provided they also have a clear and separate business delineation. How you manage objects within a virtual instance becomes the same as we normally manage objects within a single subscription instance, (i.e., groups, etc.). It is important to underscore this only applies to configuration objects (i.e., roles, groups, teams, etc.), not production objects (i.e., projects, tasks, users, etc.). It is also important to underscore that the virtual instance should fall under a common business function and identity to minimize the need to delineate among departments.
Let's say the Marketing Department is the first subscription in your Workfront instance. They will receive a VIID of "01" borrowing from my example at LEAP. Departments within Marketing, say Marketing Ops, Advertising, Creative Services, Digital, etc. should all have a common sense of objects needed to serve Marketing as a whole and will share the same VIID. If culturally this is problematic, you will likely need to devise naming variations to accommodate this in some scenarios, but this would not be part of the VIID, which has a singular purpose as described. A new subscription entity will then inherit a VIID of "02', and so forth, and so on.
The benefits in doing so are tremendous as your Workfront environment scales. The notion behind hiding complexity in simplicity stems from the fact that in using a consistent 2-character numeric prefix, the mind can be trained to overlook this repetitive information, and this is why I recommend numbers only, not letters, as the mind begins to appropriate more attention when it sees letters. It is only when this prefix becomes information loaded and is changing, the mind's eye truly begins to see this as noise and users object. It is also more easily explained away by informing users this is a governance policy to code usage. There is also the fact that this prefix can be totally masked or obscured with simple Views because it has a fixed position and length when viewing objects in list form wherever presented within the environment. Filters can also be leveraged to present select objects by VIID designation, overcoming some filtering limitations. This prefix can also be overcome in reports with display labels, and we will eventually have the ability to have display names or aliases for custom fields on custom forms, as was shared at another LEAP presentation last year, and this will totally eliminate the aesthetic issues, but you will still need to have this naming convention to drive object ownership consistently across all objects since all objects do not have group affiliation.
I hope this helps! Chris Berry Workfront
