At the moment, the logic of working with additional fields, as far as I understand, is as follows:
the additional field has the number # - the name and identifier with which we work.
if you change the name, nothing will change in the already configured actions and business process interfaces. but if you change the identifier, then all the settings will fly, but this should not happen.
because the additional field has a unique number #, then everything should be tied to it, so that the settings of actions or the interface do not fly off. and the identifier should work like the name - if you change it, then in all actions and interfaces - there should be no changes.
hope for understanding.
I hope this will be taken into account in the new version.
ps check out coda.io, there are some interesting things you can borrow to make boxing cooler.
At the moment, the logic of working with additional fields, as far as I understand, is as follows: the additional field has the number # - the name and identifier with which we work. if you change the name, nothing will change in the already configured actions and business process interfaces. but if you change the identifier, then all the settings will fly, but this should not happen. because the additional field has a unique number #, then everything should be tied to it, so that the settings of actions or the interface do not fly off. and the identifier should work like the name - if you change it, then in all actions and interfaces - there should be no changes. hope for understanding. I hope this will be taken into account in the new version. ps check out coda.io, there are some interesting things you can borrow to make boxing cooler.
Please join the conversation. If you have something to say - please write a comment. You will need a mobile phone and an SMS code for identification to enter.
Log in and comment
Donate
You don't have enough funds in your account Top up