Restricting Custom Form Permissions on Projects

[KellieGWAB]

Here is the solution we are trying to solve for:

We use Workfront enterprise wide with multiple groups/processes onboarded into our system. One team has a very specific custom form with very specific questions that have to be answered in order for a project to be created. Once a project is created with that form they do not want users to have the ability to access the fields to change the values. They must remain intact in order for the project to meet strict compliance/risk standards. 

I've set the form up so that only "admins" have access to edit the form, which works in theory. However, in my risk assessment I've been able to identify "work arounds" that creates the ability for end users to edit the fields.

1. Anyone with manage access to the project, has the ability to add additional custom forms to the project.
2. If they add a custom form that utilizes the same fields as the first form, without restrictions in place, the user can edit the fields on the second form and it will update the form fields on the original form.

• I tested removing manage access to the project and that will remove the owners ability to add custom forms but then they can't do other things that are required of a project owner, like changing the status, managing the finance, manage risks, modifying dates, etc.
• I have reporting that can/will show changes made to the field but this doesn't solve for removing the ability to edit the fields. Which is a compliance issue for these types of projects. 
• I couldn't find a way to remove a users ability to add custom forms if they have manage access to the project.
• I can't restrict the ability to edit custom forms entirely on the project because there are certain fields that will need to be updated by a project manager and those fields don't live in the restricted section. 

Any suggestions from the community on how to truly lock down fields/forms to end users with manage access?

[ChrisStephens]

This is a work around that I actually leverage quite a bit. The two ways I see around doing what you are presenting is a) using something like fusion to watch for those fields to be changed and using fusion to unwind the changes, or b) not using those fields on other forms.

[skyehansen]

Similar to Chris' answer: in our instance, 

1) we make sure that the fields being used from workflow to workflow are unique to the workflow with very few exceptions, (e.g. your team with the compliance issues should have its own unique question fields)

AND

2) we make sure that the majority of users cannot attach forms / the majority of forms cannot be attached by normal users. With project forms, these are all controllable via templates (i.e. users shouldn't be able to attach forms, they should have the form already through using the template.).

[KellieGWAB]

Thanks @ChrisStephens and @skyehansen - All great ideas to consider. Something I was exploring was the ability to lock down a custom field so that it can't be used by another group and based on what I'm seeing and have tested, it's not possible to not share a field with other group admins that have access rights to create custom forms. Ultimately come down to monitoring the field, the form, and the projects regularly. 

@skyehansen I know that contribute access would prevent users from attaching a form but we can't turn it off for anyone with manage access. How do you lock down users ability to attach custom forms to projects? 

[skyehansen]

Here's the article for sharing custom forms. https://experienceleague.adobe.com/en/docs/workfront/using/administration-and-setup/customize/custom... 

In summary: the understanding should be that "system wide" lets everyone see and fill in, and no further sharing is necessary.

0) out of the gate, we restrict access levels as much as possible to not allow this and configure our processes (e.g. project templates already have forms attached) so that no one has to get trained to do it

1) we don't share our custom forms with anyone unless we want them to intentionally attach it

2) we do set all custom forms to system wide, so that everyone can see existing forms or fill them in

[Richard__Carlson]

I just want to add, anecdotally, that I have never needed to set all custom forms to system wide for access issues.  I have never needed to individually share a custom form with anyone.  I guess that these things are being inherited based on roles, groups, etc.

[skyehansen]

When you create a custom form, it defaults to system wide. So, you're correct in that you shouldn't need to SET it. Just don't unset it, is my advice.

[ChrisStephens · Accepted solution]

I just tested it, and you can make it so not everyone can add fields to forms, you need to make the fields so they're not visible to people that shouldn't be using that field.