Dear *,
I need to share our current predicament regarding pre-filled fields in combination with CDMs with you. With the hope that we could speed up A12-14696 or that anyone could think of another workaround. And if nothing of the above comes true, it might still help someone with similar problems 
When modelling with CDMs two very useful form model features don’t work:
- Initial Values
- Initial Rows
There is a workaround for “initial values” that we use in our insurance applications, that works in some scenarios: We configure dependent fields and set the desired pre-filled value there. As trigger field of the dependent field we use an arbitrary other field (boolean, enumeration or confirm) in the form with a stable and deterministic value - if such a field exists.
So the logic basically is:
if [arbitrary-field] has value [x] set value of [relevant-field] to [y]
And we do that for each and every relevant-field we want to pre-fill.
There are two cases where this workaround doesn’t work, though:
- when you have no such stable and deterministic field that is set by the user and could serve as trigger field
- when the form is created for the first time and you need the form to be loaded with initial values
In both cases I tried to add a new field to the document model (and hide it in the form model) that could serve as trigger field and give that field a value via computation. But unfortunately that doesn’t work due to: A12-15397. Changing a value via dependent field requires that the trigger field is actually changed in the form and cannot be set via computation or from the backend. Please also refer to Dependent Field and Initial Value.
Currently we have 4 customers affected by this problem and we will have to tell them soon that we’re unable to pre-fill certain fields 
Therefore the question: Has anyone come across these problems and found a better workaround? Is there an idea for an intermediate hack? Or, what would be the best, can we somehow help to speed up A12-14696?
Thank you and happy modelling 
Bianca
Hi Bianca,
until we can provide a solution for A12-14696, maybe you could get the current workarounds working by programmatically setting the values of the trigger fields / to-be-initialized fields in cdm forms for new documents. This could be achieved as a temporary solution by a saga, which
- reacts to the creation of certain activities by ActivityActions.put (only for new documents)
- waits until the activity is loaded
- dispatches FormEngineActions.event actions that wrap Events.valueChange actions to set the value of known trigger fields (or fields which should receive an initial value).
To manage a larger amount of initializations, some data structure might be used which holds for known forms the known field paths to be initialized and their initial values and over which later is iterated when dispatching the actions.
Initializing top level inline repeats with initial rows could be maybe achieved by dispatching wrapped Events.Repeat.addRow actions in the same saga.
Mind that the described idea would only mimic the initialization of the top level of the form. Remote controlling the initialization of detail screens on enter would require a further saga.
Such “form engine remote control” sagas are really hacky and cannot be recommended as a long lasting solution. Also, I’m not sure about the performance implications of this hack.
Let me know if this idea is helpful.
Greetings
Conrad
Hi Conrad,
thank you for your fast reply!
We might have to use such a programmatic solution, yes! And we would probably come and talk to you about it 
.
Unfortunately in our setup that’s not as easy as it sounds. We provide a generic base application that holds all the code (frontend, backend, interfaces to all external services and so on). The customer applications are then modeled and configured “on top” of that generic base application and don’t hold any code themselves. Therefore we would need to provide a very generic implementation in the base application that would work for n customer applications…
Maybe there is anything else that could work?
Thank you and kind regards!
Bianca
Hello,
the initial value for CDMs feature is part of the 2023.06 ext6 release and will be also supported in 2024.06 version of A12.
Katerina from the Discourse team
Hi @katerina-icy-token,
Can you give me more information about the initial value for CDMs feature is part of the 2023.06 ext6 by any documentation or example code. It would help our project a lot.
Thank you.
Hi @anh-round-summit,
The documentation for Initial Values in CDMs is here.
We don’t have a lot of examples as CDMs are considered experimental and are therefore not subject to our policies in the same way that a productive feature would be.
That being said, I modeled a 2023.06-ext6 workspace which uses CDMs to fill 4 Fields on different levels.
[Link to Zip file]<INTERNAL_LINK> on owncloud
Password: showMEinitialVALUES
There is one field per DM which is filled with an Initial Value by:
- Open the Form Model
- Click on the Control in the Model Tree
- Enter a valid Value in the “Initial Value” Field of the Control Editor
fyi
The advanced Workspace from 2024.06-ext4 has CDMs in it. You could also use those models for testing and simply try adding some Initial Values to the Controls in the Form Models and test this in the Preview App.
