Workfront

JillAc · 4/8/22

How are people managing the new feature where a form can be attached to multiple object types as relates to existing forms? Can I update the object type tag on any of the forms, and then delete the duplicates? How will that impact the forms being currently used on active projects or templates? Has anybody tried this and can share how they are managing to update their existing forms to clean it up?

Thanks

CalvinFold · 4/11/22

I'm curious about how to "migrate" to cross-object custom forms too.

I know we have no real plans to change/collpase the existing ones until I can test what happens.

And any use of the new one has to be carefully considered. What happens if I make a cross-object, but then find I need to "separate" them again because of some subtle change that only applies to one object type? How does one down-grade from a cross-object form?

We also find we have in some cases made subtle differences to, say, the Issue vs. Project versions, so they have to stay separate. But it would be nice to collapse the Project vs. Task ones (since want all the Issue data to come along whether it is converted to a Project or a Task).

So many permutations to test‚Ä¶

ChloeWY · 4/12/22

I'm in the process of starting this. It seemed to work in Sandbox, so fingers crossed I'm not missing anything. Most of what I'm cleaning up are duplicate custom forms where one was created for issues and one was created for projects. My plan is

Make the project custom form also work for issues (Custom form A). This option wasn't where I expected it to be. It's in the top center of the custom form editing screen.
Go to the Queue topic where Custom form B (issue level) is currently set up to add automatically. Replace Custom form B with Custom form A.
Deactivate Custom form B

I don't think we would ever have to break ours apart again. My main use case is where the user creates an issue to request a project, a custom form is attached to input required project information, then that data is all transferred to a duplicate custom form once the issue is converted to a project.

AlisonW · 4/15/22

Hi Chloe - thank you for this. I also want to consolidate my forms as we have tons of duplicates. A couple of questions about what you've done:

So you are just deactivating the duplicate form, not deleting it?
Did you confirm that data on previous issues (the ones having the old form) was still there and just appearing in the new form? Or are you just making the change on a go-forward basis?

For anyone - if you have information on how to ensure data transfers to the original form (now configured for multiple object types) so you can DELETE the duplicate, I would love to hear about it!

ChloeWY · 4/18/22

Hi Alison,

Yes, I'm deactivating instead of deleting.
I only confirmed that data transfers to the new form during the conversion process of turning an issue into a project. This works correctly for the ones I've tested in both Sandbox Preview and the real ones that have happened in production since then. The data transfers to the new form the same way it used to before when the issue form and project form were different forms. All of my existing issues still have the old form attached to them. The migration to the new form only occurs during the issue to project conversion. And all new issues have the new form because that's the only option available now.

I hope this helps. It doesn't look like it moves over until a conversion happens.

RandyRoberts · 4/12/22

There was precious little documentaion I'm afraid.

user01245 · 4/12/22

Does this mean you can make one custom form, and then use the same one for issues and projects without having to duplicate it? Right now that's one of our biggest pain points. Having to update the issue version of the form, then duplicate it, and disable/delete the duplicates. Would be amazing if there's a way to get around that. Is this in the preview environment or on a roadmap?

ChloeWY · 4/13/22

This is in production as of last week for me! And yes, that's exactly what it means.

LilitM · 4/15/22

Hi, everyone.

I'm so glad there is interest in using multi-object forms. Please feel free to book a feedback call here and discuss your comments/questions with the Product team directly!

CalvinFold · 4/18/22

I ran some tests in Preview to check "instanced" behavior: to verify if an Issue converted to a task or project is the same form (multi-object custom form), but a "copy" with independent data.

I can confirm that, for example, you convert the Issue to a Task or Project:

If you change data in the Issue, it does not change that data in the Resolved To project or task.
If you change data in the project or task, ot does not change that data back in the Resolved From issue.

So seem to be working as I'd expect in terms of data separation as well.

RyanKirk · 4/18/22

Thank you for confirming the functionality!

EricaLo · 4/27/22

For a custom form I want to use for both an issue and the converted projected, when considering permissions on the section breaks, is there a way to allow the user who submitted the issue to edit the request but not the project?