"To DE or not DE?" That is the question...

[Doug_Den_Hoed__AtAppStore]

As I look back over the past 8 or so years I've focused my career on extending Workfront, I am still as impressed as ever with its Custom Forms and Parameters functionality (aka Data Extensions or DE for short). One of the earliest official lines I recall hearing about DE was at the first user conference. I think it was my friend Scott Johnson, who was Founder and CEO at the time, and now Chairman of the Board, who said (rather humbly, which I appreciated; and I'm paraphrasing): "we know that no one knows your business better than you do: so we've built our software in a way that will let you change it to fit what you need". Brilliant. Since then, I've invested a lot of time doing some very interesting things with DE within Workfront, including modeling 60 month financial charts, online job application systems, mobile-ready questionnaires, order quoting systems, executive dashboarding, cumulative graphs...too many to remember! Which takes me to my point. Once a Workfront DE Parameter is named and gets used in reports and "baked in" to everyday speech as a concept, the idea of renaming it gets harder, more costly and less likely. It is worth some time -- especially upfront, with a clean slate, but even if you're already underway -- to think through how to name and manage these DE Parameters. Personally, I run a pretty tight ship: in the Workfront Instances I oversee, I give very FEW people the right to change Parameters, a very LONG speech about the importance of strong naming conventions, and (where I can), a PREFIX at the beginning of each related Parameter to make it easier for those maintaining the parameters to manage them. That last point in particular is always conentious, though. As innocuous (to me) as having "IIR" (Incident Investigation Report) at the beginning of the "IIR Start Date" Parameter, to others, it is also an ever-present bit of jargon that can cause distraction, confusion, and at the extreme, be a barrier to adoption. So, with a sigh, I don't believe there's a perfect answer on this one. But I am curious. Who do you allow to create your Custom Parameters, and how are you naming them to stay organized (yet still meet your users' needs)? Regards, Doug

[EricLu2]

{{Doug}} You are so right. The versatility of WorkFront’s DE capabilities also introduce the ability to proliferate confusing, ambiguous, and perhaps conflicting attributes. Who creates attributes? I am the only person who creates attributes. I have a backup, but I’m the only person who normally has anything to do with custom attributes. We’ve eliminated a whole host of problems by single-threading this process. Not everyone will have this luxury, but I appreciate that we are able to work it out this way. How do we name them? 1) If they have generic value (like Baseline_cost_variance), then we name them what they are - the business semantic; 2) If they have limited value (like Marketing_Campaign_number) then we name it with a prefix to indicate its membership in that unique group of attributes, followed by what the data means - the business semantic; Eric

[MarcMo]

Doug, I have been struggling with cumulative graphs and have been told they weren't possible. Can you share how you got this to work? Ideally, I'm looking for the graph to accumulate over time without making a custom field for each week of the year.

[Doug_Den_Hoed__AtAppStore]

Sure Marc; I'd be happy to explain further about cumulative charts. The ones I was referring to were in a calculated parameter at the Task level, with one task for each month, in order to show a cumulative amount over the course of a year. I've attached an example of an S-Curve chart, showing only the Planned and Forecast series, so you can more easily see the effect. If this is the kind of chart you had in mind, I'd invite you to post a mockup and describe what you're after. Regards, Doug

[RobertGo]

Tightly controlled here. But only being able to use the Field List view or a Parameter Report to learn what custom forms those fields appear on is not enough. I am not aware of Workfront providing a "where used" function that system admins can use to chase down all the objects (reports/prompts, views, filters, groupings) where custom fields are used, or where any built-in data items are referenced for that matter.

[Doug_Den_Hoed__AtAppStore]

Hi Robert. To find where Custom Parameters are used (when considering the "effort" to rename them), I invite you to consider our Report All Report Details solution, which creates an Excel Spreadsheet showing (for each Workfront Report selected) which fields are used in the Filter, View, GroupBy and SortBy of each report. I've attached a screenshot to illustrate. Regards, Doug

[CameronCh1]

Hello Doug, I am interested in cumulative reporting as well. I believe, I am somewhat on the right track, but need a little more guidance. We are logging defects and want a cumulative count per day. I have attached simple chart to show..we had 44 yesterday, and 42 logged today, I would really like to see 86 total logged on todays value. Any help would be great. Thanks,

[Doug_Den_Hoed__AtAppStore]

Hi Cameron. Cumulative Issues is a tough one. With Tasks, there's an implied relationship (e.g. where an indented task can refer to its parent task and pull a number down to create the cumulative running total. But on Issues, there's no such relationship. Would it be possible to move the Issues (even after the fact) under a daily Task, representing the date the Issues were raised, so you could leverage the Task approach? Regards, Doug