Just like it says in the title
- Try this:
As far as I’m aware, this is completely allowed… but it’s not working when I try…
Maybe I have missed something…but I have always understood the USERSETTINGS to be a device side set of values ONLY. Since automation only runs on the server, it wouldn’t be expected to “know” about the user settings - especially since the server knows nothing about the the logged in user.
Again, my understanding is that each automation runs under the identifier of the App Creator.
I’ve never used a User Settings column to capture an email address nor to populate the To property of a Send an email task.
Nonetheless, with other data types, my understanding and observation is that User Settings are indeed available to an automation triggered by a user data change event, although, as you note, scheduled automations are indeed run using the identity of the app creator.
Sounds like we have a mixed understanding. Let’s call in the big guns…
@Steve or @Marc_Dillon HELP!!!
I played with this and get the same behavior @MultiTech gets.
I also found that I can use USERSETTINGS() in the automation trigger criteria. This blows my mind a little.
If USERSETTINGS are only available on the device side, does the above mean that triggers are actually executed on the device side as well??
Interesting. I can see both ways. I guess I’d lean towards it being reasonable to be able to access user setting values in data-change Bots. They can already know the USEREMAIL() of the user that triggered the bot, so it feels like it’s only 1 step away.
Without time right now to do any thorough testing, I briefly spot-checked a couple of the automations where I was recalling this was the case. It turns out those all reference values that sort of originate in User Settings but pass through the lens of a slice or Ref type column of an actual table. So, my statement might be erroneous. I may have been conflating this with the AppSheet API feature where you can specify User Settings values when you invoke the API.
I do still wonder how security filters would be applied within automations if User Settings values aren’t available since those expressions can reference User Settings (not to mention security filters themselves, which are also processed server-side outside from the context of automations). For an automation, maybe the client device sends to the server all the rows from the table that had been security-filtered before downloading to the device?
As far as I know, the usersetting values will be only respeceted by the automation when we run “data change action” as it is said in the documentation.
Recently we had an internal dicussions about this subject.
you are trying to add value of email address, coming from Usersettings, but it is not data change actions, where AppSheet automatoin (formally known as workflow) to know those value. If we carefully examine the documentation, it says usersetings value is only recongnize when we run the data change action through the bot.
To make our life difficult, the documentation is saying the usersettings value can be reachable by other steps, such as sending email or others, but as far as our quick tests are involved, the usersettings value (client side) is only respected when we run bot with data change actions.
Maybe I m wrong, though.
I am really confused right now about scoping of the various (discussed here) app elements with regards to client versus server side.
Obviously, we will all get by and achieve our goals but it would be nice to know to help formulate and design future apps.
A couple questions:
To be clear about my use case:
I’m trying to send an email from a data change
That’s what I expected to be honest, but actually AppSheet is not behaving in that way, not sure why.
I m just on the own belief, based on the document for Automation in terms of AppSheet API (other automatoin should be using AppSheet API to do bits and pieces), it says the usersettings is respected when we invoke the data change actions.
This made me believe that the usersettings will not be respected when we simply run the tasks such as sending email, creating files as they are not data change actions.
Data change events should have access to user settings. Scheduled events should not.
Why is this?
I have always thought of actions as dual-purpose - client and server side. Meaning there is a copy of that action on BOTH sides. When running actions from Forms and buttons, the client side version runs. But when running based on automation, the server side runs the server version.
But this is only an explanation to make sense of things in my mind!
It would be nice to know definitely where the scoping division between client and server actually is.
Use settings are explicitly stored on and tied to the device. There are no server-stored user settings. How would the user manage those? There’s no way to log into the server to manage them.
For data-change events, the user settings in effect at the time of the change are sent in the change, just as you have the option to send them in a call to the AppSheet API.
For scheduled events, there’s no way for the server to know what the user’s current user settings are. And since scheduled events are performed as the app owner, would the app owner’s user settings (were they even available) be appropriate in all cases?
That’s correct.
