I thought this feature was supported and wouldn’t be deprecated. Was it suddenly disabled? This will be a pain, as I’ll need to change hundreds, possibly thousands, of formulas across the app.
[Let’s assume we want to ask the app user to provide the notes that will be saved in the Details column. To do so, for the Change Status action, expand the Advanced section and add an input value, such as Notes, with an initial value of n/a. For example:
When the app user clicks the Change Status button, they will be prompted with a dialog that asks them to provide the details. ](Actions: The Essentials - AppSheet Help)
So this is basically a disconnect between the original design of the INPUT function and the way people tend to expect it should work. Providing a “default value” was required both to infer the value type and to use as a fallback value in contexts where
no value was bound to the input (e.g. running the action directly rather than through a ref action), and
the user could not be prompted for the value (e.g. when the action was run in an automation, or the INPUT was used within a larger expression (showing a form is only supported when INPUT is the root of the expression)).
Perhaps it would have been better to call it “fallback” rather than “default”.
When the user is prompted for values, since the action is updating an existing row, the form that’s shown is basically a kind of an edit-row form where the fields initially show the preexisting values from the row. In the same way Initial Value expressions only apply to add-row forms and don’t replace existing values in edit forms, default values of inputs don’t overwrite existing values when the input form opens. However I can see how this could be unintuitive, especially when the preexisting value is blank, as “default” seems to imply pre-filling the form input.
The current behavior effectively leaves it up to the user to decide which input fields to update, as anything they don’t update retains the preexisting value. Changing it to pre-fill the form with input defaults would make it difficult to maintain this flexibility, as the user would no longer have a way to avoid updating a field that has a default. I doubt we could make such a change unless tying it to a new setting to make the new behavior opt-in.
To those of you who would prefer to see the defaults pre-filled into the form, would you expect that to happen even for fields with preexisting values, or only fields where the preexisting value is blank?
@Adam-google thank you very much. I now understand that the default value is more a “fallback”.
I think you can leave it as it is. But you should enable the “Reset on Edit” for Input Forms. Then also the “Initial Value” would work in Input Forms.
We could control the “Reset on Edit” via CONTEXT(). If we want it only in form view we can use this expression in “Reset on Edit”: CONTEXT(“ViewType”)=”Form”. Otherwise we can just enable it and it would work also for Input Forms.
With the 3 action set, we can give the initial value for input as a workaround we have.
First we place a physical column apart from column which is a target column for input action (let me call this column as TEMP column. Let me assume to pass the TODAY date for the target column input. (while the target column is null to get start)
Grouped Actions
Set value of TEMP column to today().
Open Input Form against TEMP Column.
Pass the value from TEMP column to Target Column
This action is only available where the target column stays NULL.
Then create another simple INPUT action against target column whose action is only available where the target column is NOT null.
Your work around is not making sense to me. Think about the case where the user cancel the action.(not save the form dialogue) Even cancel the action, then the new value is saved to the column which is not intended.
Thank you very much @Koichi_Tsuji I didn’t think about that. I updated my OP.
@Adam-google with that in mind I would recommend even more enabling Reset on Edit and Initial Value in input forms. With that we could do it without the workarounds.
Thanks to everyone for the feedback, glad to see there is some support for the existing behavior.
@Fabian_Weller Regarding reset on edit, are you requesting that it should reset to the default defined in the Input? Or just run the Initial Value expression as a normal edit form would? It looks like you meant the latter, but it seems like we already do that. At least, we do at the point where the user edits something in the form. This is one difference with the regular edit form where it runs initially upon opening the form. Is that the behavior you’re referring to?
I would like to share my thought here. To deal with this issue, receiving manual input from the end-users, i’ve decided to follow the Appsheet design and tried to educate the end-users instead.
Here is my “workaround” solution.
If there is a must to pre-fill the “default value”, then I create another Form view using the LinkToForm action, despite of having more work to do.
From my point of view, displaying a “default value” is just a pin-point as a based-on value for users, and eventually, they will input a new value anyways (else the value would be automatedly entered).
So, i put the “default value” in the Concatenate() in column’s Description field as a suggestion / info-service with some text as a guide and teach them / especially notify them about that.
The most important thing is to show this workaround to the users and let them understand the main purpose of doing it, well, in my cases at least.
I would prefer that the behavior of a normal form view and an input form view to be the same.
So when we enable Reset on edit and enter a value in initial value this initial value should show up when we edit a row via the normal form view and when we edit via an input form view.
We could control the “Reset on Edit” via CONTEXT(). If we want it only in form view we can use this expression in “Reset on Edit”: CONTEXT(“ViewType”)=”Form”. Otherwise we can just enable it and it would work also for Input Forms.
Right now this works when we edit a row via the normal form view. But in an input form view, the Reset on edit and the initial value is ignored.
Hmm, it sounds like we’re getting different behavior somehow or looking at different scenarios. Here’s what I’m seeing:
I have a field with an initial value and reset-on-edit enabled.
If I include it in the Action assignments (so it appears in the input form) I do see its value reset to the initial value when I update some other field in the input form (the new value appears before saving the form).
If I omit it from the Action assignments (so it’s not in the form) I still see its value reset after saving if I use the Input form to update some other field.
I don’t see any difference between desktop, mobile or new mobile framework.
Again, one difference here vs normal edit form is that the reset only occurs after some other value changes. But it sounds like you’re not seeing the reset happen at all, even if some other value changes. Am I understanding that correctly? Can you describe the specific setup you’re working with?
