Virtual Instance ID - VIID concept from LEAP 2019

Hi William Sorry, we don't use anything like you are asking about, but... Apologies if it's off topic perhaps, but I think there is a need for Workfront to provide "display labels" functionality which allow us to separate the label for a field displayed to the users on a particular screen, from the unique database field name used in the back end, similar to the way you can already rename columns on a report. I think maintaining separation between the admin/database layer and the user/display layer is a good practice, and I wonder if you are attempting to build admin structures into the user layer due to inherent limitations in the Workfront product. If so, one possible solution could perhaps be to have an "Owner/Owning Group" for any field specified in the database layer in a way that does not impact (or at least should not restrict) the user/display layer. I'm not quite clear what you are trying to achieve and so it's not clear whether this idea of mine would help or hinder a solution to your needs, but I'd be interested in your views... Regards Bob Sleigh BT Group

Hi Bill, Yes, I do. In fact, I've even begun to go as far as ensuring fields are use-case specific. But the simplest way to describe this is how we're doing things in WARP. Every custom form and field I create is prefixed with WFPro. This ensures that there's never an accidental modification to one of "my" fields by other group administrators with custom form edit permissions. It makes sense to keep everything self contained. If "Group A" needs a form and fields, every form and field they use should be prefixed. If there is an existing field that serves the same purpose that someone else created, I'd still replicate the field. If you need top-level reporting on the two similar fields, then a concatenation in a calculated field would suffice. Again, this keeps everything separate and easily maintainable with minimal risk. Thanks, Narayan Narayan Raum Workfront Admin @ SunTrust Bank, WF-Pro.com Creator

Thanks Narayan. I'm happy to hear confirmation that yes, it's worthwhile, since I've already committed to doing it. Where I'm struggling is actually developing the prefix/suffix model that designates ownership. Feedback from the user base is that they don't like three letter abbreviated prefixes, or numbers, because they find them confusing. As an example, a "request type" field, which practically every group needs and wants, for our Advertising group: ADV - Request Type Request Type - adv 05 Request Type None of these are well received by the users in that group. And of course, they are not very sympathetic to the rationale given when they ask, "why can't we just have it say Request Type?" We could call it Advertising Request Type, but the full string of Advertising doesn't work well with a large portion of the other fields they need. I'm hoping somebody out there has thought of a nomenclature that is minimally distracting or confusing. William English T-Mobile

Thanks Bob, I don't think it's too off topic. I do like the product suggestion, but I would also be afraid that it complicates self service report building. We already have this challenge to some degree, because users presume that the column label of their report is the actual field name, but then they can't locate that field anywhere (because it doesn't actually exist by that name). I can imagine that might get worse, if five different fields are all labeled the same thing. The answer is ultimately user training, but getting the time and attention to facilitate that training is a luxury, and there are so many topics that might take precedence over that subject matter. William English T-Mobile

We have both our group and a group in Europe in our instance so we use NA or EU for the prefix on many objects. I have noticed the EU group tends to prefix their objects with [EU] - I think the brackets help their users as an indication that this is not part of the object name, but just a nomenclature for their group.

I'm with Bob Sleigh on this one. As someone from a programming background as well as some focus on databases and UI, I don't like that I have to have odd prefixes or suffixes on the visible field name, especially since many of our "field names" are long-winded questions. We do this funky "naming with prefix/suffix" begrudgingly with fields with the same name but slightly different purposes or group use; usually I just try to cleverly name the field slightly differently (though that is about as confusing from an admin standpoint). User adoption has proven to be easier when cryptic extras are avoided. Bad enough I have to self-build repeating fields with Field Name - Line 1 , Field Name - Line 2 , etc.--even that just throws users. It's been my experience that the more you say "we'll train around it" or "they'll get used to it" the more likely you'll get poor and confused adoption. When the field name is in the form of a sentence/question, there is a huge need to have the label separate from the field name, and then use established conventions like camelCase or underscores or the like for backend field names, which can be kept brief. Helps immensely when doing calculations. This backend name can then be differentiated by prefix with anything I want without affecting the user experience. There used to be entire books written about this for database administrators. Granted, in our environment, we do not expect users to create their own reports because we've had to create custom versions of so many of the built-in fields; there is just no way to properly train anyone in report building who isn't doing it fairly regularly and have easy access to our admin team. So I would not have to worry about the issue of duplicate field names with separate backend names; we had to abandon the idea of users making their own reports before we even launched. BE THAT AS IT MAY, and back on-topic I suppose, we're currently using " - group" as in "Request Type - Comps" and "Request Type - Design" for the few fields that have this sort of overlap (and as I said, begrudgingly). Since not all fields have this issue, we don't do it uniformly for all field names. I like the idea of the square-bracketed version Heather mentioned; it looks "computery" and more obvious it's "some system thing" to the user; though I would put it at the end to help readability. I might adopt that if it became a bigger problem than it currently is. Kevin Quosig

Those are some good points, Kevin - especially the point around question-based fields and how cumbersome they can become. I wouldn't say we have a lot of users making their own reports. More commonly, users are wanting to make their own Views, so same issue there. Even for our Group Admins, who do the bulk of report building, it gets confusing. I inherited this instance, and with it, a lot of maddeningly similar fields like "Request Type," "Type of Request," "Requests," "Request Types". Not to mention some brilliant custom fields like "Project Status," "Task Status," and "Request Description" where they wanted to put those fields in custom forms as opposed to using system fields. Fixing it all has been on my to-do list, but it's a fairly heavy lift because it's not just a matter of renaming these fields with a more thoughtful nomenclature. Many of them have already been in use by multiple groups for which the value list happened to be a good match. So I can't rename "Request Type" to "ADV Request Type" without also renaming it on a different form used by the CRM group. I can create a new occurrence of CRM Request Type for that group, but then have to deal with the problem of managing historical data that's already been collected in the (now) ADV Request Type field. And people wonder why I'm always angry at the world! Thanks for the input, Doug . But, I'm still not clear on what your opinion is? :) Good advice re: letters and numbers only. I briefly experimented with some Unicode symbols and quickly learned they are nightmarish to reference in calculated fields. Are there other consequences to journeying beyond alphanumerics? Wondering what the drawbacks might be to using punctuation as separators, as Heather shared. William English T-Mobile

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

Thanks for elaborating Chris, I concur with your approach, and have used a similar technique for many years. In my case: the prefix pattern is XXXX (four letters), rather than your 99 (two numbers), but follows the same principal that (in time), a standard fixed length is easiest to ignore and/or strip off, recognizing that four characters (obviously) do take up more space than two numbers, however there are advantages in avoiding the ordering/hierarchy/longevity implied by using numbers, not to mention four characters ~500K combinations from which to choose (vs 99), and finally four characters, in my opinion, are Just Right as far as choosing something both familiar yet "overlookable" as a conventions...such as VIID, for example Look forward to catching up with you at SKO in SLC next week. All the best! Regards, Doug Doug Den Hoed - AtAppStore