LinkedIn
Twitter
CURRENT STATUS: Rolled out to 100% of accounts
Hi everyone,
I’m very excited to announce that we are launching the INPUT functionality to General Availability. App creators can now define when information is passed from one context to another via dynamic “inputs” so that actions and tasks behave differently based on these input values. Effectively, app creators can now “parameterize” the logic of some of the actions and tasks.
The INPUT functionality enables multiple types of rich and complex use cases, such as:
- Prompting app users with an input box when the app user taps on an action button
- Updating a set of rows from one table using values from the row of another table
- Reusing AppSheet automation tasks across different bots
INPUT example
Probably the simplest example is with an app that lists tasks that have a status field and a comments field. App users are asked to update their task status to “Done” and provide information in the comments field on how they accomplished the task. App creators can now dynamically prompt the app user for that information (and only that information) in a pop-up modal when they mark the task as “Done”. It was already possible to provide a similar flow, but (a) the app creator had to do more work and (b) the user experience for app users was not as intuitive.
A little bit of history
The INPUT functionality unlocks a number of highly requested features that make app creation easier and expand what AppSheet apps can offer. Back in 2021, the INPUT functionality was released to Beta (a.k.a. Preview) but the team had some lingering questions. It is now (finally) Generally Available to all app creators. There are a few changes though. First, the syntax has been updated so that the feature is more easily discoverable, its usage is more explicit, and the syntax itself is more consistent with other existing patterns in AppSheet. Second, its scope has been expanded to now support Automation tasks for reusability purposes.
Many app creators have been using this functionality in their apps since its Beta launch, but others may have been hesitant to rely on it because it was still in Beta and so we are glad to finally make it Generally Available to everyone.
As Liz called out in our release notes on Monday, this is currently rolling out and should become available to all AppSheet users in the next 10 days or so. When it is available to you, we ask that you start using the new syntax.
Old and new syntax for existing apps already leveraging this functionality
In order to properly maintain this feature, we will have to turn off the old syntax in the future. Until then, all apps and automations using the old syntax will keep on working without app creators needing to take action. We also understand that adopting the new syntax in existing apps represents some amount of work by app creators and we want to give you time to adjust. In an effort to turn off the old syntax some time in June 2024, we plan on proceeding as follows:
- Within a few weeks you will start seeing warning messages in the editor for apps that leverage the old syntax
- At the same time, for simple cases leveraging the old syntax, app creators will be able to migrate from the old to the new syntax with a single click and check that everything is working fine
- Starting on March 30th, for simple cases, the old syntax will be automatically migrated to the new syntax if app creators have not taken action
- Starting on April 30th, for more complex cases, app creators will be prompted to use the new syntax when they open the editor for such apps
We will be communicating to you about this as we go through that process.
Let us know if you have any questions (but don’t forget to check the FAQ section below first :))
Thank you,
Arthur Rallu, for the AppSheet team
FAQ
- What resources are available about this feature?
Documentation is available at Doc for input in Tasks, Doc for input in Data Change Actions.
The team talked about this feature in an AppSheet Office hours in September.
I also want to mention this community post by @Kirk_Masden. It walks you through the capabilities of that feature in a very simple way. If you're new to using this functionality, it's a great way to discover it IMHO. The app used to be implemented with the Beta syntax but Kirk updated it recently to use the new syntax (Thank you Kirk!).
Until the rollout is complete, we are keeping this documentation as is. We will tag it when the rollout is complete and add a link to the new documentation.
- Can I use the old and new syntaxes together?
The two syntaxes can be used in the same app for two different tasks or actions, but the two syntaxes cannot be used within a single action or a single task. In other words, in an action with 2 inputs, both of them must be specified with the same syntax.
- During the Sept AppSheet Office hours, the team said they’d publish a template app. Is it available now?
Not yet, but we still plan on doing it. We’ll update this FAQ and add a comment to this thread when it is done.
- When will the input functionality be supported by other data actions?
We are aware of this request, but we don’t have a timeline to share at this point.
Thanks for reaching out Arthur. Happy to help if I can. I saw the same behavior across multiple bots on the app (I think this is the only app I have where I do an operation like this).
But the bot triggers on a new row in Table A, then sends some of those values to an Action via Input that updates values in Table B.
So Bot:
to the Action:
The result I was seeing was that it was always using the default value instead of the passed value (So I would get "In <error>") every time.
The [Status] column where the action was putting the value is an Enum column in which "In <error>" is not a valid value, so that is how I was getting the error and indication that something was broken, but I don't have any indication that it being an Enum was related to the actual issue.
The processes that broke are used multiple times daily and had been working fine. The first instances of breakage I saw were at 6:02PM GMT (or whatever time zone the Monitoring app uses).
Happy to provide any other details that would be helpful. I have obviously switched everything on our production version to use the new format and that is working fine. Happy to look at the historical version and give you anything else you need though.
I updated my old syntax to the new syntax and received this error:
New Syntax:
old syntax:
Note: In my case [missed reason] represents the field's dropdown REF options. I did notice the Advanced area for manual inputs but hoping it's simply another option.
Has anyone else run into this error? I didn't see it here in the string unless I missed it of course.
I think I see the issue. Look again and this illustration of how the old and new syntax are related:
Notice that the "test" that appears in the old syntax disappears from the new syntax.
So, in your case [_INPUT].[Missed Reason] might be what you're looking for.
@Daisy_Ramirez Not sure if related but when I changed mine, I noticed I had to first add the input under advanced section and save before I used it in expression.
Hi,
Where is the support ticket page ? Do you mean "Contact support" ?
Hi @Arthur_Rallu and @Lusha_Wang1
It seems that Appsheet only changes the expression of the Input function but it didn't apply for prefill data in action as I set.
I have been trying to use the solution with no success on a very basic implementation.
Have a Date Time column in TaskSchedule Table called Tempstore.
Created Input tempDateStore of type DateTime. Used Action ( Data: Set the value for some columns in row.) and tried to set value in column TempStore with [_INPUT].[tempDateStore]
When going to the form and press the action, the pop up with no ability to enter a value.
Any help in why this is not working would be appreciated.
Just uncovered why: if the field is set to NOT SHOW :
The dialogue box pops up but the ability to use enter is not rendering.
By making it 'show', the ability to enter is now available.
I am unsure this was the intention of the function for INPUT to be effected by the field having show/or not, but seems not be intuitive to the purpose of the functionality. The Input should still be available as it is independent due to be a collection action from the user. Specifically in that the column can still be selected if "SHOW" is off. The assumption is you can still manage the data.
The use case is to have a 'none visible' ability to store data that will be used for other purposes. In my example, the goal was to be able to use the input and 'add a new row to another table using values from this row' with this data element, as the Advance functionality for INPUT is not available for that Action which I am unsure why it would be available for that action.
If there are other options I am curious for the advice.
The INPUT Type doesn't have REF. What if I want to select from a list of REF
When I use the old syntax, if the column has REF type, the INPUT function will show the Suggested Values from that column:
But I don't know how to use the new INPUT, there is no REF type in the list of INPUT type:
