What is the real addition by Automation?

Today, I throw several posts about the Automation after spending hours with it.
When I firstly contacted with Automation, my question in terms of "what is the difference exisitng Action/worklow VS automation will bring to us? Even after just spending hours, I found Automation is complex and difficult to learn and get used to it. Maybe because i m old Appsheet boy, familar with the existing action/workflow combination to achieve what I want to do.
Yes, current Action/Workflow is quite poweful enough, almost anything we want. Based on my past experience with it, I expected Automation will add more of the fuel to do more, but I could not find anything like that. Sorry to say, it is making easy story more complicated.

Having a look at premier document. The sample case, to get a new lead. Conditionally check the value. and make a branch to change the jobs based on the value given by the new rows. Apply the “wait” operation. Stop with Return value.

Without those of new features, we are able to do it in a more fancy way and most imporatly inituitive with action and workflow. Workflow can easily set up to fire or NOT to fire conditionally.

Automation seems to trying to make all those different task and operation into ONE chunk.

With current Action/workflow, we simply create the separete workflow based on the several condition to fire or not. Again, Automation is just trying to make a single chunk of operation, to accomodate the different conditions to fire or not.
But workflow/action, we just make them alive separately, where they dont conflict with each other.

Back to the sample use case on premier document, once the new lead to come, then it makes different stream lines, based on the value of the new rows. If confirmation is NOT required, then move to next process. If not, WAIT until the value is changed to what we want.
Actually, we can make those conditional process and logics far more easily with current Action and Workflow without any complex logics.

I m sorry, but I feel Appsheet may become difficult to handle with new features … Huge concerns with me.


Which begs the question, is Automation “no-code”?

1 Like

Largely current confusion with me coming from my perception and mis-understanding that WAIT step could be similar to async/sync kinda of things, but actually it was not. But there is similarily that operation is ceased until X values turns to Y.
Returnv values is the same. I assumed we would get the variable stuffs, but seemingly not.

However, the fact we are talking something like this is already indicating that Appsheet is starting to be leaving from No-Code world, but getting out to coding area.

Probably this is because of my mis-understanding to new Automation though.


Hi there, I’m the UX designer on AppSheet and would love to learn more about your thoughts on the Automation feature

Can you please expand? What did you find difficult and complex to use?

Can you please expand? Why is this good or bad?

Any other thoughts?


1 Like

The main quibble I have with it is that it has caused confusion and complexity by introducing a whole vocabulary and introducing a whole slew of questions about what works and what doesn’t and why/how it is better than actions+ workflows which we have been used to for years.

It is not clear why we should think in terms of automation rather than the old way.

The UX suggested things add to the confusion rather than alleviate it.

Many things are still broken and evolving which doesn’t help.


To me it’s just worflows/reports 2.0. I’ve moved all mine over, not that any of mine were complicated. It’s a modularized workflow, and a little bit easier to visualize a branching workflow. I just wish they could also be used to force UI view changes, and a “Wait for X amount of time before proceeding to the next step” without having to actually record a timestamp somewhere.


That’s what I’m getting from it as well. They’re taking these elements, and making them more universal - so instead of having the trigger for, say sending an invoice, ONLY live inside the workflow… now it’s it’s own thing that can be used elsewhere.

  • So I can use that trigger to do a whole bunch of other stuff too.

But I agree with @tsuji_koichi

I’ve actually never really gotten anything to work over there, despite several “let’s give it the old college try” attitudes - and spending at least an hour each time trying to get something to work.

@gmoura I found the whole process of filling in all these bits to be… confusing.

  • I get the idea, and it’s a good one (to split things up so you can use one trigger for multiple things), modularize everything…
    • but to me it’s creating a collection of “stuff” in the app - and I find myself thinking… where’s this… where’s that… how do I do this… is that under this heading, or that one…
    • There’s just all this… stuff now, and it’s all over the place (inside the Automation panel).

When building a workflow, or report… it’s all right there - no muss, no fuss. Everything is inside the same container.

I’m sure there’s going to be some gold over there, once things get smoothed out.


Hi @gmoura

Let me explain further about my personnel opinion over the impressions after first contact with new Automation.

First of all, things are getting complex too much, even for the veteran of Appsheet like me, probably even more difficult to understand for beginners who start Appsheet from now on.

Imaging we are watching a love story where just two chartercter is acting, ACTION and WORKFLOW. Just two characters are playing to do bits and pieces. But this new drama for Action, there are bunch of characters came in play. Action, Workflow, Task, Event, Bot, Process… Hmmmmmm. The number of main characters is already indicating the possible complex. Triangle relationship bra bra bra…
Okey, the basic relatinship among those characters are summarized

  • Event will listen to even where the things to be fired. Event will be standing on the top tiers of Bot to fire all the rest of process. Bot is strong. Event is under of Bot. Bot is also wrapping Process. Process is including task. Tasks are wrapping bunch of actions All in all, bot is wrapper for everything.

Fairly enough it is too much complex (again at least to me)

In terms of UI, yes, it looks fancy at a first glance, as process is “visualized”, but just a first contact destroy my expectation. Clicking the dropdown is initiate the presentation of bunch of “options”. Just read through all the option. Okey, none of them it will help me what I want to do, then what can I do to do the stufs I want. After spending sometime, find a way to add custom name and process. But this noisy drop donw keep presented all the time. Just noisy, and sometime dropdown works oddly.

We need to keep going back and force betwee, action, task, process, bot event all the time. Annoying.

To start to create new process, it is always complex to find a right thing to do. To add task, then it is actually selecting options what Action or Workflow we wish to create. From task section, we create new , then it will add actions and workflow, which are confirmed later on the action/workflow tab. Yes, it is natual, as we are adding new action or workflow in old style through task section. But this processs is not gonna intuitive at all.

And more.

Once again, to do the same thing we can do now with action as well as workflow, we need to convert the same through the complex set ups. yes, we can modulize the set of action/workflow and later use the same, which sounds useful, but to do that we are sucrifacing too many stuffs, throw away intuitive and easy process, do bunch of works to set up single module. Even after we made a module after spending hours, not sure if we are going to reuse it or not. Probably the frequency is not often. If we have similar process, I would do just copy action and workflow and duplicate the process and push the alternation, which is far more easier and short- cut.

If we gave up the current process (where I dont have much of complain) and move to other new things (which is more complicated), it is fair to guess we are able to get the more of benefit to do so. But again, I dont see much of new and interesting stuffs, which Automation is going to throw over us/

To move to new Automation, it is just increase amount of time to develop single app.

To do this complex job ove the computer screen, we are only allowed to utilize the tiny space, upper right hand corner, probably 1/5 size of our screen, which make me crazy and frustrated asw well.

All in all, automation is just adding complex to me. By sacrifacing the intuitive and easy process under current Action/workflow set up, the positive things we can gain is limited. So it is not a fair game to me.


@tsuji_koichi just like workflow rules, processes work on a row of data at a time (Bots trigger a process based on a matching event). The WAIT step pauses execution of the process until the condition specified (on the current row of data passed to the process) in the expression is true. That is what the WAIT step is designed to do.

Its still a no-code platform with a more powerful grammar, better visualization and more importantly support for external events that wasn’t in the product before.

To the comment regarding having many new components (bots, events, tasks, processes) the focus is on modularity / reuse. This allows you to re-use components at multiple levels. Our view is that users can configure most of what they need from the Bot tab and only navigate to the other tabs (events, tasks, processes) when they need to create components that they plan on reusing elsewhere in the app.

Automation does present some new powerful constructs that can help support additional use cases than before. We are constantly working to improve, simplify the Automation features as we go along. Please continue to share your use cases, comments, concerns @MultiTech_Visions @Bahbus @Bellave_Jayaram


Hi @prithpal

For me, current appsheet action/workflow is super powerful enough to achieve what we want. Still dunnt know what is the Automation is going to exactly adding new feature which is currently missing from.

Yes, make proocess a module and reused it, but I dont see much of use case, even if there is, the frequency of use is rare. and even know, we just copy action and workflow, to duplicate with slight amendment to manage.

So once again, I m now answering to my own question, what is going to real additional benefit to us by using Automation.

Yes, we could monitor the change in data directly made to googlesheet rather than change made by Appsheet app. But again, this is new feture, but probaly I will not use. This is because if we allow the user or someone else access to the spreadsheet which is source of appsheet app, they may take a mistake, deleting rows in bulk by mistake, or delete and add columm etc which all break up apps. So i always not to present original data set visible and available to someone else for protection.

Apart from that, I can not find any new additional feature and benefit, unless I see exact use case your team present to us.

sorry for it.

In my opinion.


My personal perspective …
Today’s workflow rules are an event, a condition, and then a sequence of tasks. Each of these does something. There are some limitations:

  1. It is difficult to do any conditional task in a workflow rule
  2. It is difficult to reuse the same task in two different workflow rules
  3. It is difficult to have one workflow rule call another
  4. Stylistically, this is different from the rest of AppSheet where all components are reusable
  5. In terms of expressive power, this is limited and cannot express workflows that require human input along the way (and therefore have to wait for the human)

For each of these, we have our advanced customers find workarounds. For example, we allow a webhook in one task to call back into other workflow rules. In fact, @tsuji_koichi , you have been pushing the limits of this yourself asking for recursive depths of more than 10 on those calls :]. Customers take a logical process and split it into multiple workflow rules. While this may be familiar for current customers, it is difficult to argue that these limitations are good for the long term. In fact, many of you have complained about the limitations of workflow rules.

The new process automation is a superset of today’s workflow rules. If what you want is a linear sequence of tasks in reaction to an event, you can absolutely do that. But you can also:
*) Branch
*) Wait for human steps
*) Take the results of one step and use it to make a decision/input in another step (coming soon)
*) Call one process from another process (instead of jumping through webhooks)
*) At some point in the future, call a process in another app from a process in this app
*) Iterative actions that loop over data and do something to each row

Now, you don’t have to use any of this, but we hope it will become natural to do so. Likewise, the componentization into Tasks and Processes is a convenience for reuse but you don’t really have to use it if you don’t want to or your use cases are simple. It is tricky to get the UI to handle reusable components but also permit inline authoring. We’re working through these issues, admittedly sometimes clunkily as we figure out what works.

This is some of our rationale and I hope the explanation is useful. It is not necessarily all correct, and it is not necessarily all materialized correctly in the implementation. The requirements come from customers and from what other products in the market offer. It is a preview and we continue to refine and improve it from your feedback.


Hi @praveen thank you for your comment, as always.

Yes, your personel perspective, but it is a voice representing Appsheet :smile:

The absolute goals with us here in community is to make the platform far more better and useful, and the feedback from end users and app creators are always adding the fuel to drive faster.
I appreciate to give us a chance to peek into the new products through the preview or beta release to add our comments and reflect our voice to the final products.

I m sorry Praveen, I most likely stay noisy as usual, but it is by nature. I will give the contact details for my parent, please post the complain letter to them, haha.

In the meantime, I will keep trying to find a time to test those new tools, Automation and new Chart etc and will revert with the feedbacks.



I love your engagement Koichi. And I tell my new colleagues who have joined our team recently — the people who are most vocal in our community are so passionate because they are the most committed. IMO, we are all on the same team together trying to make the platform better as you say.

Also, I will emphasize, the long list of voted features is also being worked on. Just because we do new things like automation, it doesn’t mean we ignore those. You will see things from that list delivered as well. Recently, we did a couple and there’s more coming in the pipeline.


I’m curious how you define “no-code”.


The “no-code” topic is interesting and subjective. Some would say expressions are complicated logic and therefore code (Santiago on our team has said this for five years!).

I cannot go with the definition that no-code == no-logic, because then its impossible to define no-code apps. What we’re trying to do is say logic == what, but code == how. In other words, we want the no-code logic to be declarative defining outcomes versus code, which defines procedural instructions to tell a computer what to do to achieve those outcomes.

Now if you squint at AppSheet, the least declarative aspects of an app definition are the Actions and the Workflow Rules. This is because they tend to be imperative statements with sequential flows. So you can already say, these are the least no-code-y of our abstractions.

Yet there’s another dimension of no-code which is “what is the abstraction level of the logic”. The closer it is to the business semantics, the more it is “no-code”, versus the closer it is to esoteric platform abstractions, the more “code” it is. When you look at it this way, column definitions, and expressions are a lot closer to code than workflow rules or process automation. If you look at the new automation, the logic of the process is very clear and at a semantic level.

So no clear answer. In general, most observers think of data analytics systems and automation systems are naturally no-code, but app building platforms are naturally low-code/code. AppSheet’s innovation was to make app building no-code in the same manner that analytics and automation platforms already did.


You are Great!! :slightly_smiling_face:

Why can’t a platform be BOTH - no-code and code based?

Here is how I have come to describe it…

Appsheet is a platform that allows fully-functional no-code applications 
to be created quickly either from scratch or starting from a datasource.  
But it ALSO allows for sophisticated extensions to each app to create 
complete custom enterprise-level systems!

Of course the goal of the platform is to make things as easy as possible for quick development. There will ALWAYS be ways to improve the platform in that respect. But there is one inherent side effect of trying to make all things no-code that many don’t realize - the feature becomes less-flexible.

No-code can take an app only so far into feature-rich territory. How far is constantly improving. To create truly great apps, developers will need to go beyond no-code capabilities. I think AppSheet has done a tremendous job of marrying the no-code/code concepts together. So well, that it is often hard to tell when you have crossed that line.


I m using daily bunch of “no-code” or “less-code” solutions all the time, and when I face the problem which is basically connected to the appearance of the app, where it always involves HTML and CSS stuffs.

There are bunch of no-code solutions out there, but most of the solutions are giving options to push own code to add own CSS to change the appearance of the apps.

Even at this moment, I m doing that job, adding own CSS to my solutions where the basic platform Im using is called NO-CODE solutions.

Appsheet is making things easy to tackle with both front/back end service with no-code base, which is fantastic, but I m not happy with appearance of apps.

It is always questionable if you are happy with appearance of the app or not. Some may say I m happy and other may say Im NOT happy based on the given UIs.

New feature is added, which make people happy, but we are always demanding. Once we gain a step, we still desire something more. This is inifinite loops alike. The problems are solved by the no code solution, but there is always some room where the exisitng solutions can not solve. Coding is giving us more flexibility, once again, changing the appearance of the apps, with own CSS.

@WillowMobileSystems , Will, I m not aware where and which sort of the case you wish to use own coding with Appsheet, but for me, UI is pretty much important where Appsheet does have area for the bunch of improvement, but it takes sometime and there would be dispute you like it or dislike . So leave the options to the users to change it over to own taste. For me, I always thinking of, "Oh dear, i wish to change this styling if we could use own CSS…’ All the time.

For the backend service stuffs, I m not coming up with the case where I wish to do coding on our own, as Appsheet current capabilities are looking after all of our requirements.


I agree UI can improve a lot! But what I think many on this platform fail to realize is that Appsheet is, for now, targeting Business or Enterprise usage. Not RETAIL applications.

Businesses don’t truly care about UI styling, it adds extra cost and shortly after using the app for a period, they typically don’t even notice the styling any more. Many savvy businessman understand this and won’t pay more for an app just because of its looks. In fact, I know of some businesses that are still using green screens or spreadsheets to manage the business. They have avoided upgrading because of the cost of prior traditional systems. Appsheet is providing that upgrade ability and more than satisfies their needs.

I have checked out other no-code platforms and I could do awesome stuff with the UI’s. But several didn’t allow access to the raw data for business reporting or migration into other systems. For any serious business these things are a must. Others were expensive so I didn’t get far into them.

Maybe there are other platforms that allow true access to the raw data AND provides great UI capabilities? I haven’t found one yet…not that I’m looking that hard but I do check out other platforms occasionally.

Now, having said all that, I have been working on an app for a client meant as a retail app. It is being built in Appsheet as a prototype. The plan being that if the app takes hold it would be rebuilt in a platform that provides more flexibility in the UI. If Appsheet had more comprehensive UI styling abilities, maybe that wouldn’t be necessary.

1 Like

Agreed 100% - I’ve hit this brick wall with all of my applications at one point or another. Sometimes this can be frustrating when I can see the underlying code or logic, particularly UX things like CSS or HTML, and know that I could do what I want if only I could inject 10 characters into the stylesheet parameters.

However, I can appreciate how allowing this sort of flexibility would be a nightmare from AppSheets perspective. If a portion of the userbase was implementing customizations of this nature, how could AS reliably push new platform updates without breaking downstream applications?

I think, generally, my preference would be to embrace what is possible with AS, knowing that they are committed to ensuring it works to that standard. Less maintenance time for myself. That said, I do wish there was a way to perform more complex customizations for the select few applications which are my babies. I’m holding out hope that the iFrame UX view will make this possible.