Editable calculated fields

Modeling
1

Hi :blush:

I’m working on a scenario where a calculated field needs to be editable under certain conditions. Here’s the situation:

  • A user selects an Office from a large list via a binding.
  • Upon selection, two large textboxes—Office Information and Contact Information—are automatically populated. These text fields originate from the connected Model-document (via binding).
  • Sometimes, users need to make small adjustments to these fields, such as entering an individual contact they personally know.
  • Importantly, edits to Office Information or Contact Information should NOT update the original Model-document. Instead, the user’s changes should be saved to two separate fields, where the initial values are copied over from the original when the Office is first selected.
  • Currently, this copying is performed by a calculation, which results in the fields being readonly. This prevents users from making the necessary edits.

What I’d like to achieve:
When a user chooses an Office, the full Office and Contact details should be copied to dedicated, editable fields. The user can then make their individual adjustments, with the guarantee that the original Model-document remains unchanged. I’d appreciate any suggestions on how to make these calculated fields editable after the initial copy.

Thank you!

2

Sounds like the perfect use case for document mapping if you were on 2025.06. You use the document mapping to copy over the field values and then you have a document without any computations that would prevent editing otherwise. Not sure how much of that functionality is useable in 2024.06 though.

3

Ah good to know for the future. Unfortunately mapping was just introduced in the 2025 version.

4

The latest 2024.06 kernel versions already have support for some of the mapping functionality. Tooling support might be a different story. So there might be a way for you to get this to work.

5

@andreas-fresh-mesa is correct, Mapping Models and the changes in Kernel are available as experimental parts of 2024.06

Using a Mapping Model you could map the data from your source documents into your target document. However, this mapping happens in the backend and you would need to do something like this to work with mapping

  1. A user selects an Office from a large list via a binding.
  2. Upon selection, the form is saved and disabled
  3. The two large textboxes—Office Information and Contact Information—are populated by mapping data in the backend.
  4. The Form is reloaded with the new data.

You could achieve a similar result with workflows by creating process variables from the connected documents and updating the fields with a service task. Once again, this would happen in the backend and the form would need to be reloaded.

You could also use a Field Dependency to write the Field Value across but you need to be careful how you set up the trigger as you only want this to happen once.

6

Hey, thank you very much :slightly_smiling_face:
I have now found a solution where I added an “edit” checkbox. When it is selected, the two text fields are replaced with two new ones (via dependent views), and at the same time, they are automatically filled via a trigger in the data configuration. It’s not pretty but it works :slightly_smiling_face:

7

Yes, the Kernel Mapping API and tools are available since 2024.06-ext5 and can be used with this version.
We did modeling improvements with 2025.06 but kept the models non-breaking. So you could model the mapping with a newer SME.

8

I’m glad you found a modeling solution that works. By adding the “edit” checkbox, you have nicely defined when the default should be used and when the field should be editable. This solves the problem that I had in mind when I said

I guess your User Flow is something likes this:

  1. Textbox1 is pre-filled with the data by computation and therefore read-only
  2. The user clicks on “edit”
  3. Textbox1 is hidden and Textbox2 is shown. You use a Field value dependency to copy in the text from Textbox1
  4. The user can edit Textbox2 as much as they like
  5. If the user deselects “edit”, Textbox1 is shown and we return to 1. in this list
9

Yes thats exactly the workflow :slight_smile: Thank you.