Description
We have hundreds of Custom Forms and thousands of Parameters, many of which are referenced in dozens of automations across multiple platforms, both in and not in Fusion. The only tool that is built into Workfront to help us document and govern these objects is the Description field (forms) or the Instructions field (parameters). The absence of a full-featured data dictionary within the platform is very limiting in what and how we are able to document.
We would like additional fields on these object types so we can spend less time tracking down all the areas throughout our stack that are impacted by things like changing a parameter name, or deleting a custom form, etc.
While we do want the ability to attach custom forms to a wider array of object types (especially including Teams, Roles, Reports and Dashboards), I believe this need is better served by the addition of a few extra system fields on these objects. Doing so will allow us to build our data dictionaries directly in Workfront.
Why is this feature important to you
The frequency in which we or teams we work with encounter errors due to benign changes on Categories and Parameters is having a strong negative impact on our efficiency, productivity, and the perception of Workfront's quality by our users because "it's always breaking." While a data dictionary can be maintained externally, there's no way to encourage or enforce admins/group admins to use or update it as they interact with these object types, as it's not built in to the form editor.
How would you like the feature to work
On both Categories and Parameters (maybe even Parameter Options!), we would like multiple additional system fields made available in the form editor so we can add and reference additional details relevant to each object. Open to suggestions on what these fields should be or how they behave, but anything that allows us to input and edit the various entity relationships of a field or form will be helpful.
Current Behaviour
We do our best to document dependencies in the one field we're allowed to do so, but it is limiting to us and also confusing to users. (E.g. when using a custom field's Instructions field to document entity relationships of the parameter, that is shown to users interacting with forms and they have no idea what it means.)
We have explored using Fusion to seed a collection of Projects and Tasks as a pseudo data dictionary, which allows us to add a lot of detail and metadata about these objects, but its tedious to maintain and isn't easily seen when someone is making updates to one of these objects.
