Expand my Community achievements bar.

Got questions about Workfront Governance? Join our upcoming Ask Me Anything session on February 12th!
SOLVED

Project/Request custom form placement with reporting calculated fields

Avatar

Level 3

We convert requests to projects and use multiple calculated fields to attach to these objects for reporting. I have two questions:

  1. Is there a best practice whether to attach reporting calculated fields to a system admin section at the end of the individual custom form or use a separate custom form with the calculated fields? Currently, I have a separate Reporting custom form with the reporting calculated fields that I attach to the Request queue topic along with the request topic custom form. Both forms go to the project when the request is converted. If I add the reporting calculated fields to every custom form, that would be a lot of individual maintenance every time I have to change something on a calculated field. The consultant that set up our configuration used both methods, so I want to make sure I understand the pros and cons of each way.
  2. I’ve found that making the system admin field section or custom form admin only permissions restricts using the fields in reporting visuals, since only admins see the field data. So I end up permissioning the form/fields section so users can see the data but not change anything. I would like to be able to hide the reporting calculated fields from non-admin project/request view, but use the calculated field data visually in reports for non-admins. Is there any way to do that?

Thanks

Cathy

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

1) I generally keep a reporting custom form for fields that have wide global use across multiple workflows. If I put these on individual custom forms that are used together in a multi-form configuration, then every time I change a calculation it will error out because it's being used in multiple forms on the same project or request, for example.

 

2) I don't call the section "system admin". As you mentioned, system admin sections should be for the admin only. I usually call the section "office use only" which has a more generic widespread use and can be safely ignored by any user who has ever had to fill out a government form of any type. Additionally, you can set a dropdown field with yes/no answers that defaults to "no". When the user changes it to "yes," the "office use only" section will show up when you configure the correct display logic rule. Otherwise the section just stays hidden.

View solution in original post

2 Replies

Avatar

Correct answer by
Community Advisor

1) I generally keep a reporting custom form for fields that have wide global use across multiple workflows. If I put these on individual custom forms that are used together in a multi-form configuration, then every time I change a calculation it will error out because it's being used in multiple forms on the same project or request, for example.

 

2) I don't call the section "system admin". As you mentioned, system admin sections should be for the admin only. I usually call the section "office use only" which has a more generic widespread use and can be safely ignored by any user who has ever had to fill out a government form of any type. Additionally, you can set a dropdown field with yes/no answers that defaults to "no". When the user changes it to "yes," the "office use only" section will show up when you configure the correct display logic rule. Otherwise the section just stays hidden.

Avatar

Level 3

Thanks very much, Skye. This information is just what I was looking for. I really like the idea of the conditional dropdown to take the office use section out of view.