Uptade the app and check table value and block editing

[Bruna_Hoepers]

Is it possible to use a function that according to a value of a column in the table, does not allow changing data?
And is it possible for the user to update the application?

[Steve]

Bruna_Hoepers:

Is it possible to use a function that according to a value of a column in the table, does not allow changing data?

Yes, there are a variety of ways to control what data the user can modify.

Bruna_Hoepers:

And is it possible for the user to update the application?

This question is ambiguous. Can you elaborate?

[Bruna_Hoepers]

I’ve developed a scheduling application with pre-defined schedules, but the information is overlapping if two or more users edit the same variable at the same time. I defined in the table that when it was marked “Scheduled” would not appear the option in the application, however if two users edit the same cell at the same time, this function does not work. Would it be possible to check the value of the table in real time to block the insertion of the data?

[Steve]

Bruna_Hoepers:

Would it be possible to check the value of the table in real time to block the insertion of the data?

There’s no trivial way to do it, certainly. You might be able to approximate it with a workflow, since workflows are performed on the servers, closer to the data store.

[Bruna_Hoepers]

What kind of flow would make this possible?

[Steve]

I’ve not tried this myself, so this is just speculative.

An action has an Only is this condition is true property that can be used to check whether the resource is already scheduled and only take action if the resource is not yet scheduled. If you apply an action with such a condition within the app itself, you run the risk of conflicting edits if the user hasn’t synced recently, since the action only sees data within the app itself. But if the action is instead applied as part of a workflow, it will use much more up-to-date data than the app itself: the data on the server. Depending on how data is synchronized at the server level, this could drastically reduce or even eliminate the possibility of a conflict. The downside is the scheduling failure would not be visible to the user unless they checked, since the failure happens during a sync, possibly even in the background.

[Bruna_Hoepers]

I did not find an action that would make it possible to block data insertion.

[Steve]

The IF THIS IS TRUE… section.

[Bruna_Hoepers]

Ok, I entered the condition of [Status] = “Available” but is it necessary to associate an action with it? I just entered this condition and nothing happened in the app

[pravse]

Jumping in … if I understand correctly, the scenario is that two different app users both concurrently edit the same row. In this case, they will be making potentially conflicting updates.

In general, AppSheet’s model works best for applications that naturally partition work across users. It doesn’t work so well if multiple users update the same entry (in this case, the last updater wins).

Workflow rules cannot really solve this problem. The workflow rules are applied after the row change is applied in our cloud service. So they cannot really block or prevent an update from happening.