Forcing the execution of an action in a group


Does it makes sense to expect every actions in a group to be executed even if one action (except the last one) has nothing to do?

Lets pretend I have a group of 3 actions where each of them change a value/state on records for different tables, lets also assume that a user modifies the value/state of table manage by the second action so this one has nothing to do anymore, then the 3rd/following action(s) will not be executed.

So it appears that a group a action can be used to sync/validate data globally.

I agree it’s not desirable or intuitive, at least to me, coming from a technical background. But it is what it is, so we have to work with it.

Best I’ve been able to determine, for a data-change action, if the row isn’t changed, the action failed. What I’ve found seems to work is setting an Only if this condition is true expression to verify that the action will produce a change. For instance, if the action sets Column to "", the Only if this condition is true expression might be ISNOTBLANK([Column]). If the expression evaluates to FALSE, the action is skipped but not considered a failure.

Hi @Steve

Thanks you for you valuable input on this matter!

Overall from a process perspective there is no exception. Your wise strategy is to put conditions/exception everywhere to prevent the process from failing. It sounds like a lot of overhead. At this point it seems we have no choice.

You strategy assumes that all conditions are known to build the Only if this condition. I will see how far I can go with this stategy. I have already 40 actions in my application and I believe I have as many to build. It is getting difficult to manage.

1 Like

I sympathize. :frowning:

1 Like

If I may offer one observation/suggestion. If your app is getting large like you indicate, don’t rule out creating multiple apps each with dedicated functionality. You can create several apps with no additional fees involved. AppSheet does provide the capabilities to navigate between the apps seamlessly and an App Launcher feature to allow direct navigation into each of the apps within the “system”.

This approach will keep related functionality contained within an app and will be easier to maintain. This should also help keep data in each app minimized to only what’s needed by the app.


Hi @WillowMobileSystems.

Thanks for taking the time to share this strategy I was not aware of. It might provide insides/options for problems I have not deal with yet like Admin versus User access/views/content security differences.

In a scenario where you need to plan work, then to supervise and take tactical decision and for employee to report on their progression, would you use this strategy to provide different user environments and deal with data access concern and different data content in views?

1 Like

Generally speaking I would say yes. But there are several factors that will drive the decision of having a single app or multiple apps. When you mentioned you expect upwards of 80 Actions in the app, that is a signal to me that the app is very large or very complex or both and a prime candidate for multiple apps.

Let’s assume you have a group of people responsible for planning and scheduling projects as well as maintaining a backlog of projects. They typically do not care about the daily progression of the active projects. They really only need to know what status active projects are in so that they can plan for release of the next project.

Managers, supervisors and employees actively working the projects don’t really care about the daily management of the company-wide backlog, planning and scheduling of projects. They do probably want to know scheduled projects coming their way soon and have a smaller need to manage those!

So, I would create at least two separate apps Project Planning and Project Execution. Each app has mostly self contained data with only a slight overlap.

Then within each app you can apply Security Filters to limit the data to only what each company employee needs to see. For example in the Project Execution app, employees see only projects they are assigned to, supervisors see all the projects for all the employees they supervise and managers see all the projects for all the supervisors they manage, etc.

Similarly, you can turn on/off certain features based on employee roles…such as the Admin and User roles provided in AppSheet OR your own custom set of roles you build.


Thanks @WillowMobileSystems for sharing this strategy! I will keep it in mind as I move forward.

1 Like