We’re preparing to expand our library of Adobe Workfront best practices . . . again! In addition to relying on our in-house expertise, we want to incorporate recommendations from you, our all-star customers.
Submit your own best practice recommendations by leaving a comment on this thread. We'll review submissions to be included with our next update.
What is an Adobe Workfront “best practice”?
Best practices are guidelines that represent an effective, efficient course of action; are easily adopted by you and the users at your company; and can be replicated successfully across your organization.
Topics help categorize Community content and increase your ability to discover relevant content.
When creating custom fields in custom forms I always specify the name of the field with the name of the team the custom field is for and then a hyphen following by a description of the field if that field is unique to that custom form. Standard fields on all forms are just called due date, language, description, etc.
I always use the label as an opportunity to ask a specific question.
For example - we use objective on nearly every custom form. However, not all of our teams want ‚ÄòObjective’ on their form. The video team for example wants to ask, ‚ÄòWhat should be the key takeaway from the published video?’. The photo team may want to ask, ‚ÄòWhat message should these images convey to our customers?’ And our marketing analytics team may want to ask, ‚ÄòWhat questions are you seeking to answer?’
All of these questions are similar, but unique. One ‚ÄòObjective field’ won’t do. So, the question the team wants to ask is the label of the custom field, and the name is: [their team name] - [general label].
Label: What should be the key takeaway from the published video?
Name: Video - Objective
The specific label helps us get accurate information and the specific name helps tremendously in reporting.
That is great! Thanks for sharing, Samantha.
Just wondering, as a follow up, do you have system admins, group admins, or anyone with access to custom form management in their access level, make those adjustments?
Our group admins are primarily responsible for their forms and making those adjustments, but they're trained and monitored by our sys admin. We keep a pretty tight grip on all our custom forms and who has access to them.
Thanks for sharing Samantha,
I concur, and have used prefixes on Parameter Names (and other Objects) for years, given the extra fidelity (targeting them) and efficiency (organizing them) that such prefixes offer. The one drawback, in the past, is that end users would have to "look past" the prefix to then understand the "real part" of the Parameter Name...but as you so eloquently illustrate, Workfront's introduction of the independent Parameter Label provides the best of both worlds.
c.c. @Gevorg Kazaryan‚ to share the ‚ù§Ô∏è
Our workers can get confused as to where to find the custom form information (is it at the main project level? in a parent task? etc). I add an asterisk at the end of the project / task / issue name to clarify that it came in originally as a request and has custom form information.
e.g., Event - Brave New Worlds (11/9/21)*
That's a good idea I haven't heard before. Just out of curiosity, do you also have a shared view that shows custom form information, if there is any, or do you leave that to individuals to create/use?
We (as partners who implement Workfront for clients) like to use Indexing for our Dashboards and Reports - D001, D002, / R001, R002 etc...
Also, we use ranges of numbers to represent different personas, e.g. D0xx might be the Planner Range of Dashboards and contain Reports ranging from R001 - R099, D1xx /R1xx might be for the worker personas - and so on. D9xx is reserved for System Admins.
All of the above is flexible and can be tailored to suit your own instance.
Another helpful example we used was where we created over 50 reports each for five departments. This time dept. 1 was assigned D1xx and R1xx, D2xx and R2xx... etc. next, the key here was that when copying dashboards and reports from one dept. to another, we were able to do so rapidly by changing just one number. This is helpful when managing large numbers of reports as it makes it easy to identify and recall reports that are similar across different departments.
Another variation, where you have similar reports on a dashboard might be to use the same number for the dashboard and the reports contained within, so D045 contains R045a, R045b, R045c, R045d and so on - again, copying these to suit another team requires a tweak to the number and the team name in the reports. Everything is kept in order and this helps with the follow-on maintenance of the reports as well as making searching for them super-easy (search R045a returns that report very quickly).
A final note; using identifiers like this helps also when you need to list a set of reports - its much easier to say 'reports R045a-e' than it is to write the names of each report.