Moving Fields Between Forms: Data Retention

[CalvinFold]

Freely admit I tried this with Support already, but was hoping the Community knew a trick. Feel like I've asked this of the Community before, but can't seem to find the post, if I indeed made one.

I have a request to move a field, without losing it's data, between two custom forms. Both forms currently reside on all projects. Well, at least 99% of the time, I suspect there are instance of only 1 of the 2 forms on some projects due to human error.

Support gave me an elaborate method that would require me to make copies, make changes, redeploy forms, etc. We were hoping for something easier.

Anyone?

[skyehansen]

is the question about moving the field or about how to find the project with the missing form...?

[CalvinFold]

Sorry for the apparent lack of clarity:

It's about needing to move Field X from Custom Form A to Custom Form B without a loss of data.

BACKGROUND:

We've used custom forms like modules so we can mix-n-match pieces and make changes without affecting some huge all-in-one form. So a given intake brief might have 5 forms such as Account Info, Project Top-Level Data, Instructions, Intake Brief, Mock-Draft Mode.

By and large this works well...until someone decides a field located on the Account Info form needs to be on the Project-Level Data form (because it makes more sense there) and doesn't want to lose the data.

[skyehansen]

I feel like Doug answered this several times. His solution revolves around having a unique field on every form and using it to identify cases where the form exists on an object ... is that ringing a bell or is that the something you’re trying to streamline further?

(here's the post I was referring to: https://one.workfront.com/s/question/0D50z00006Px3P3CAJ/tunnel-of-death-how-to-find-a-form-with-two-... )

[CalvinFold]

Skye, I must be particularly inarticulate this morning and I'm not sure how to clarify further. 😵

I don't need to know about the existence of a form (and I have used Doug's trick for that to great effect recently). Let me try one more time:

1. From A and Form B should exist on all projects.
2. Form A contains a field named Kevin's Data Goes Here.
3. Management wants to move Kevin Data Goes Here from From A to Form B.
4. When it is done, Kevin's Data Goes Here will only be on Form B.
5. When it is done, no data was lost in Kevin's Data Goes Here despite moving the field

I hope that clarifies, otherwise I'm stumped how to ask this question. 😥

[skyehansen]

I don't know if I'm giving too obvious a solution? Why would you not put Kevin's Data Goes Here on Form B, save it, and then delete it from Form A?

[Doug_Den_Hoed__AtAppStore]

I agree Skye -- that should suffice.

The trick (once you know it, Kevin) is that any Parameter (Kevin's Data Goes Here) that is repeated on separate Custom Forms (A and B) behind an object (e.g. Project X) are technically "pointed" at the same underlying single piece of data. If you change it from "hello" to "goodbye" via Form A and then refresh the page, both A and B will show "goodbye", having retrieved them ("fresh") from that one, underlying data entry. And provided at least one form still has that Parameter on it, that "goodbye" will be preserved (under Project X), even if Kevin's Data Goes Here is removed from one of the forms (e.g. A), because the other form (B) is still "pointing" at the data.

Do note, though...if you then remove Kevin's Data Goes Here from the remaining form (B) at that point, Workfront recognizes that no Custom Form is pointing at the "goodbye" any longer, and it really is goodbye: that data is then orphaned, permanently, even if you reattached Kevin's Data Goes Here to Form B (or A) and said pretty please.

Regards,

Doug

[CalvinFold]

Skye:

So obvious, Support never mentions it. 😯

Also, so much about Workfront does not work in what we consider an "obvious" way that I never assume the obvious is how it works. In my years of working in IT/IS endeavors, I find Workfront kinda like entering Bizarroland. 😝

Doug:

You know, reading your post gave me d√©j√† vu, and now I'm fairly sure you've answered this for me before. Sorry for the repeat! 😳

To both:

Yay!

I had a vague recollection this should work, but wasn't willing to risk the data without a double-check.

Follow-up question:

So when I add the field to the second form, is there some period of time I should wait before deleting the field from the first form? Some sort of "give it time to propagate" time?

Do we need to open the projects to get the data to populate in the new location or will it happen behind the scenes?

THANKS! 👍

[skyehansen]

By the way, Kevin: these are things you can ALWAYS test out in your preview sandbox. Not that I'm saying "don't trust skye, she has a shifty demeanour" or anything, but I have commonly taken other admin advice into my sandbox if it affects a large number of objects (along with adequate enough reporting to prove things out).

To answer your questions though, it should be as simple as "Edit your other custom form and put the field on this other form. Hit save. Remove it from your first form. Hit save." But I'll have no hard feels and in fact expect you to test it.

[Doug_Den_Hoed__AtAppStore]

No worries Kevin,

I don't recall explaining it with the pointer analogy before, but certainly might have. And once again, Skye's got you covered with great advice, leaving me with only the one minor addendum...

"don't trust skye, she has a shifty demeanor" <grin>

Regards,

Doug

[skyehansen]

reminds me of that old word puzzle:

Two guards are standing before two doors. One leads to your goal, the other to a painful death.

Guard one says "one of us speaks only truth".

Guard two says "one of us speaks only lies"

The question is, which guard is Doug?

[JillAc]

Something I’ve done in a similar situation is if you are scared of losing the data when you delete the field from form A you can create a hidden section in form A called “Kevin’s test area ignore this” that only admins can see (or some subset of people I can’t actually remember how that gets defined) and move the field in there. That way you have a safeguard for the data still on form A but nobody can see it but the admins. When you feel confident that it’s working as planned then you can delete it from A.

[Doug_Den_Hoed__AtAppStore]

Ooh! Yes, that’s a good one too, Jill!

Kevin, using Jill’s technique, when you add and click the section for Kevin’s Test Area Ignore This, two drop-downs will appear on the left side of the custom form builder that allow you to choose (among users with View rights, or Manage rights, or SysAdmins) who can view and edit the custom parameters contained within the section.

TIP: if you go with this Section approach, it works best if it is the bottommost (and only) such one of its kind, as I’ve observed situations that did otherwise and led to unintended behavior (eg the section’s permission “leaking” to the next session). Might be fixed by now, but I recommend avoiding, or at least testing first, to be safe.

Regards,

Doug

[ElaineHe]

‚We have been able to move fields between custom forms without losing any data whatsoever.

Providing you are not changing any of the parameters of the field you are moving, then you and your users should not feel any impacts of the change of form.

hope that helps?

[CalvinFold]

Sandbox + "SysAdmin area at bottom of form" are both good safeties, in addition to the "how" of migrating the field across forms.

THANKS! 👍