- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2020 01:29 PM
What is the best practice or preferred method of duplicating fields on the same record, when that additional field would be for information only?
In other words, we don't want to actually store data for that field. That would be a waste of resources. We want something like a label that copies content over from another field. Like an annotation sort of.
This form has multiple tabs. In this tab is a writable field "specific recommendations."
In the next tab, our customer wants to duplicate that same field. I managed to accomplish this by creating a new field, and setting the calculated value field to assign the contents of the original field to the second field.
The problem with this approach, is that data gets permanently saved in the field, taking up unnecessary storage space. If I run a report on that additional field, the data shows up in the report.
We don't want that. We want a label, or information only.
An annotation won't work because it is static. I couldn't figure out how to manipulate it with code.
Solved! Go to Solution.
- Labels:
-
Scripting and Coding

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2020 02:04 PM
Hi,
I believe someone mentioned in another thread that you could click on the other section and then place that same original field again...in that other section. So that it's just a basic replication of the same field. Have you tried to click on the section in the form layout settings page and place it there a second time?
Me personally...I would say it's a training issue and the team just needs to know it'll be under the one section...OR...if needed to be under multiple sections, then just bring it out of the sections altogether and place as a main form component...but...
I believe as I mentioned you can add the field again to the other section.
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2020 07:29 AM
Keep in mind that adding the field multiple times to the form does not always cause changes to the field data to be saved the way you want. It can be unpredictable, meaning if you change copy 1 the system may decide to use copy 2 to update the database which does not have the changes you wanted.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2020 08:04 AM
The field is changed everywhere whenever you make a change on one of them. So there's only "one", when updating/changing. The other one would be the "same" as what's currently in the database, then the other would contain new information thus enacting the "changes" action and furthermore updating the database.
Also, if they do decide to go with DOM Manip, the field would be read-only and so only one is truly the "law" as far as data is concerned.
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2020 08:07 AM
Not in my experience. I just had this issue the other day on a demand record where T-Shirt size was on two different form sections. The system would sometimes save the change and sometimes would not. Once I realized it was on two diff sections on the form and dropped the field from one it worked fine after that.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2020 08:45 AM
Hmm, interesting...
For testing...I created a string field called "Test String" and placed it under two different form sections. I'll test 2 sets of 5 saves (one set per section). First set from just updating it from the first section. Another set from just updating it from the second section.
Here's the results from each save (section 1 edit only):
And now testing from section 2 update only:
Hit an issue. Upon saving "Test 6" in the second section, the changes were not saved and refreshed back to Test 5.
Checking history log doesn't even show I attempted that change.
I wonder if it's evaluating it differently since this is the 2nd section the field is on (so last section with it doesn't "count"). I'm going to remove the test string field from section 1, leap frog over section 2 and create a section 3, and place the field from section 1...there...and now see if the behavior repeats itself with this now last section trying to be the one to make an update.
Now with trying to make update from section 3 only:
Reverted back to Test 5 as well...
Now with trying to make an update from section 2, which previously didn't "count it":
Worked.
And one more time from section 3 only...just for last ditch effort...reverted back to Test 6 text.
Now let's add it back to section 1 and see if either an update to section 2 or 3 works (maybe it appearing 3 times does something, haha):
Updating from section 3: Nope
Updating from section 2: Nope
So yea...it appears while you can add this field multiple times, the earliest section (per layout/design) is the only one where the changes will actually save.
Guess I never noticed it before, so thanks for bringing it up.
But back to the overall use case for the author...you can add it multiple times without creating a new field, if you don't DOM Manip and make it read-only...the users could think they can make a change and save. If the section the field they are viewing in is NOT the first where it appears, the changes won't save.
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2020 09:26 AM
Ya, this is why the "Form Design" interface does not allow it.