multi select field in request and/or project - looking for pro/cons of adding to project templates vs request forms or both

[BethHolzman]

Problem I am trying to solve: (please scroll down for additional questions)

I need to add campaign information to projects/requests without changing the existing flows.  

This fix needs to update existing projects/requests as well as new requests/projects going forward.  

Background:

I have existing requests and projects in my portfolio and can't use programs to manage this.

I have elaborate request forms and project templates.  All of which I have inherited.  

I have users entering request who know which campaign(s) their request is being entered for. 

My initial plan: (is this correct or is there a better way to proceed??)

1. Create a new project template, add a multi select field (with a list of the campaigns), and bulk add this template to existing projects. 

2. Bulk edit selected existing projects adding the new campaign selection(s).

3. Add this new project template to the existing project template forms to allow future projects to use this field. 

Questions for experience league community:

1. My initial plan listed above puts the campaign designation(s) on the person converting the request into a project.

       1a. Is there a way to add a multi select field into the request form so that during the conversion to project the request data can pre-populate the project multi-select field?

      1b. If there is a way to pre-populate the project multi-select field, is this project field now locked or can it still be edited?   

2. If I add a similar campaign multi select field to the request form and someone looks at the project details (after conversion), they will see two similar fields both with campaign designations that may or may not be the same selections.  Is this best practice? Is this a valid concern?

3. Would it be better to just have the multi-select field on the request and not the project? If additional selections need to be made, the project manager and/or the request submitter just edits the project details.  If changed at the project detail level would that show on the original request?    

    3.a - my concern with having the multi-select field only on the request is losing the ability to use the built in Workfront reporting on project data.  Is this a valid concern?

     3.b. - additional concern is the request submitter can edit the request form and make additional campaign designation selections after the request is converted to a project. 

[RowvillBh1]

       1a. You can setup calculated fields to fetch values from other fields. Or if you were referring to default values in a field then I'm afraid that's not possible for multi select.

      1b. Users with Edit access will be able to edit custom fields on the project as well.

2. My recommendation would be to lock the request using "Business rules" (Workfront's new feature) to stop users from making changes when the request is converted or is in a particular status. 

3. No, project level changes will not reflect on the request. you can lock the request as stated above and keep projects the source of truth post conversion.

    3.a - Yes, best to keep it on the project level. However, you are able to report on information that exists on the "Originating/Converted request" 

     3.b. - Same solution. Lock the request using Business rules.