Simple Question, Tough Answer: The Case of the Elusive Reporting Category Type

[Doug_Den_Hoed__AtAppStore]

For those who enjoy solving problems, I thought I'd share this juicy one posed to me this week:

A SysAdmin needs to create a Project level 'Reporting Category Type' custom parameter that can be used to combine related Projects on a chart. Each Reporting Category Type represents a broad definition (e.g. "Print") of a set of one or several more specific Custom Forms (e.g. "Print - Minor Update", "Print - Major Update", and "Print Only"). Since multiple custom forms on such Projects may and do exist, by convention, the name of the first such custom form (via project.categoryID) logically determines which Reporting Category Type, which the end users ensure by dragging that correct custom form to the top of the custom form list, in cases where more than one custom form exists (although end users neither know nor care about the Reporting Category Type).

A spreadsheet relating each of the 55 Custom Form to its corresponding 15 Reporting Category Types exists, but over time, it is possible that 1) Custom Forms might be added and/or renamed, 2) Reporting Category Types might added and/or renamed, 3) Custom Forms might "switch" to which Reporting Category Type they belong.

Given the above, using only native Workfront functionality (i.e. no Fusion or API assistance), how can the SysAdmin add the Reporting Category Type as a Project Level custom parameter in a way that avoids additional data entry (or knowledge) from end users, while (once the initial release is complete) still keeping the maintenance burden to less than 5 minutes for each of the three anticipated changes?

With some help noodling it through from @Katherine Stibley‚, I landed on a new solution I've never thought of before, which I've now deployed and am extremely happy with. In fact, I recorded a video explaining the related pros/cons/techniques/opportunities , which I've sent to the originators of the question, and (with their permission) intend to share it with the wider Workfront community.

Until then, though, I invite you to chew on this one, and if you'd care to share, post your ideas here, too.

Regards,

Doug

P.S. to my fellow Adobe Workfront Expert Exam creators, you'll notice the style of question is a'la Jim, and in my opinion, definitely a Master question....

[DaleWh1]

Hi Doug,

So we have worked through something similar, although not quite the same. But I am happy to type through it here to see if this solution may help. Depending on how many forms we are looking at/for (and of course some normalization can occur if there are similar yet different requirements between forms), we have executed the following:

When a single object can be one of many things, share the same calculated field across the different custom forms and use a different calculation to determine the value of the field (and therefore the sub-identity of the object). This works because a calculated field can be different across custom forms when it is reused. For example if an issue were either going to be an "Assumption" or a "Dependency" then the same calculated field of "What Am I" could be defined as if(some required field that exists exclusively on the "Assumption" form is set) then I am an "Assumption". Likewise for dependency.

If I am a combination of forms, could you consider a default form that is applied to all objects for a given project and within there, build upon the same logic to determine the field value combinations that determine "What Am I"?

I hope this answer makes sense.

[Doug_Den_Hoed__AtAppStore]

Hi Dale,

Thanks for your note, and my apologies for my late reply -- I'm orchestrating a Workfront Merge/Split this month, so haven't had the chance to chat as often as usual.

I like -- and in fact, originally tried -- your approach...but in the situation I described, it is common for the Projects to have multiple forms (so Workfront would reject the attempt to attach a second custom form with the same calculated parameter but a different calculation), and there are 55 such forms that (at the time) mapped to 15 generic Reporting Category Type values (so updating a common formula later would require dropping the custom calculation, then recreating and reattaching it 55 times every time a new Reporting Category Type value arose).

The latter happened last week, in fact (there are now 16), which -- as I'd hoped -- took only minutes to accommodate.

Since I'm still waiting for permission to share the video, I'll again invite you to mull it over here...or if you'd just like the cheat code, drop me an email at doug.denhoed@atappstore.com and I'd be happy to share it privately (so as not to end this game too soon).

Regards,

Doug

[DaleWh1]

Hi Doug,

This is a fun road to walk down on Wednesday.

Let's walk through this scenario:

For any given custom form, have a field (calculated or otherwise) with a unique prime number. In your case, you would have the first 55 prime numbers (2-257) attached to each form

For the summary form, have a calculation that checks if that number is non-zero and if so, provides it to a product calculation of all 55 prime variables. Lets call this calculation PrimeProduct.

Based off the calculation PrimeProduct, you can use one of three functions to do this.

Option 1

If the math is simple, you could simply create a custom field that looks for the expected product of the prime numbers (as there is only one answer to any combination) and provide that information. However, that is fifteen (now sixteen) if statement stacks.

Option 2

The second option would be to build a logic tree using modulo arithmetic (using the concept of root and ancillary forms) to identify the forms. But, depending on the interdependencies on forms and hierarchy, you may end up with even more if statements here.

Option 3

Another option is to create a unique field that correctly identifies the prime product for each combination and the output of that field is a text field as to it's identity. So that would be 16 custom fields that are single if statements. Then a final (17th) field that could concatenate the 16 strings, of which only one should be non-null. Now, while this clogs up the custom field count, you can bury them with Admin-only view section. And it makes the code cleaner overall. For further example, Combo1 could be a calculated field that is if(PrimeCalc=14,'Combo1','') and then the 17th field could be FormIdentity which is concat(Combo1,Combo...).

That was fun to walk through. Although I am sure the cheat code is much simpler.

[skyehansen]

we use a technique similar to the tunnel of death. https://one.workfront.com/s/question/0D50z00006Px3P3CAJ/tunnel-of-death-how-to-find-a-form-with-two-...

[Doug_Den_Hoed__AtAppStore]

Hi @Dale Whitchurch‚ ,

All three of your latest suggestions are warmer; particularly the last.

For this week's continuing mental gymnastics (so long as it's still fun), one final hint: the cheat code requires only a single formula that doesn't change when a Custom Form is assigned to a new Reporting Category Type, nor changes when a new Category is added, whether it is belongs to an existing or new Reporting Category Type.

Regards,

Doug