Pile of overlay actions


Although they are very useful but many times they block other useful info on small mobile phone’s screens. I don’t know if there is an option to contract(into one icon)/expand them with tapping.

No thats not really an option. But you could show or hide them based on some condition. You could also try using them either inline or promenently

1 Like

Those are for different purposes. Many mobile apps have this feature (to hide/show overlay action icons by users).

AppSheet does not.

1 Like

You can have different buttons showing depending on who is using the App by using the USEREMAIL() function

1 Like

That’s not applicable to my requirement & situation.

I am sure your requirement will be very specific. But something like this could be achieved with of course some workaround.


Wow please advise how to do it. BIG Thanks :heart:

Okay I think that a special table or column may be required to save the hide/show state of all related actions.

Thank you.


One additional column and two actions.

  1. Add one Yes/No column called say [Display Overlay]

  2. Add two overlay actions called say “Show Overlay” and “Hide Overlay” of type “Set the values of some columns in this row” with [Display Overlay]=TRUE for one and [Display Overlay]=FALSE Condition for these actions is reverse, [Display Overlay]=FALSE and [Display Overlay]=TRUE so they show alternatively.

  3. For all other overlay actions have the additional condition as [Display Overlay]=TRUE with other conditions if any.


The drawback of this approach is that it increases the sync queue. It may affect user experience if the toggle action is tap/click many times.


Well, that is why I said “workaround” :slight_smile: Workarounds always come with some giveaways.

Also as per my understanding, the user experience is not likely to suffer so much unless the user interaction with the app is overwhelmingly with those overlay actions only. Also, as per my understanding, update a value in a row type actions shows the changed value immediately in the device before sync completes, so not impacting the user experience.


Another limitation of this approach is that I think it’s not working on deck & table views.

1 Like

You are correct. The approach shared was applicable for row-level actions. So it could work in row level, so detail view only. I believe the workaround concept can be extended to non-row level actions and summary views such as table and deck also as shown below.

Here we use navigation actions and CONTEXT() functions. The Orders view in fre example below has those overlay actions expanded /collapsed.


Well I think the view transition like in your vdo would confuse users of what is happening. Naturally clicking/tapping to expand an action, users would be expecting to see changing of the action icon only.

Thanks for kind sharing all the approaches.


You are welcome. I respect your opinion. I typically am aware your stringent specific requirements. Just completed the thread so that someone reading in future could get some ideas if the approach works for them. The Overlay actions related this requirement keeps getting posted once in a while.


Currently I’m using an approach for controlling the visibility of overlay actions globally across all views.

By having 1 additional table (named “Setting” as in below sample expression) storing a switching (enum) column, like Basic and Advanced. There is a detail view for the table providing users to quick edit of the switch between Basic & Advanced.

Also, the actions to be shown/hidden contain the expression responding to the switch selected by users in their “Behavior > Only if this condition is true”.

Note that the “Setting User” is a slice to filter per-user selection (sign-in required).

In my case, there are actions some users may not require to see or use them very often. So, this approach is working fine. The users are not confused because they know which mode they are in.



1 Like

Thank you for sharing. Good implementation. Good to see you have extrapolated the shared ideas of conditionally hiding the actions. The detailed approach and implementation will of course differ from app to app.

The update that all the users do not need all the actions that you shared in latest post. Nice to see you adjusting the approach to your this specific need.

The approach can have various small variations. You have created an additional table and view for user settings. I believe one could simply use USERSETTINGS option instead.

Thank you for sharing another variation of conditional hiding approach of actions for anyone who refers this post in future.


This story began when I’ve got a question from a guy regarding this requirement. I believe he is just making a prototype app and if I’m not wrong the USERSETTINGS option is available only for users in subscription plan. So, I tried to help them with the workaround.

1 Like

Thank you for this additional information. As I mentioned earlier each specific implementation will differ. The more details one share the more tailormade the approach will become.

Could you define what you mean by prototype app? I believe all features are available till the app is deployed. Then one can go for the desired plan as per features used.