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.

9 25 1,281
25 REPLIES 25

Steve
Platinum 4
Platinum 4

Which begs the question, is Automation โ€œno-codeโ€?

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.

Former Community Member
Not applicable

@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.

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!!

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.

The aspects of the UI/style you may want to tweak arenโ€™t necessarily for aesthetic reasons. For instance, you may want to hide the โ€˜Viewโ€™ button for an inline REF table view. Or, you may want to disable the hamburger menu in the top right which only contains an โ€˜editโ€™ action, when that edit action is also already available as an overlay.

In so many cases with AppSheet, these tweaks can be achieved with a simple display: none; CSS parameterโ€ฆ

It would be lovely if AppSheet would allow us to inject CSS parameters to some of these application DIVโ€™s, similar to how we can logically tweak the applications Localization texts.


Edit

Those darn AS devs are preventing all my fun

Oh no, I get it and I totally agree. I knew this response was coming but removed a comment about it.

A perfect example that comes to mind for me was the view you created with SVG, I think, where you had a couple charts side-by-side with some data elements below them. You used styling to create a compact way of disseminating important details, compact = time saving. Those, and what you mentioned, are the kind of capabilities we need. These are more functional in nature

The styling discussed here seemed to be more comprehensive look-and-feel kind of styling. And donโ€™t get me wrong, I would love to add that to my apps as well.

But Iโ€™m here to tell you, if you asked the client about the app after several months of use, the conversation would be like this:

Developer:  "Hey, what do you think about the app styling?  We spent 2 hard 
             weeks crafting it to make the app look awesome."

Business Client:  "Oh yea, looks great!  But can you look at this?  
                   These numbers don't add up!"

Bingo. The UI is a set back for me as well as i have built modules just to show what i need and then an app was created from scratch with much better UX

Agree. All my best enterprise clients, quickly realize thisโ€ฆ

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.

gmoura
New Member

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?

Thanks!

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.

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.

Bahbus
New Member

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.

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

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.

Koichi

Such a great word!

Hi @praveen, I really appreciate your clear and logical explanations in this community.

I also generally embrace change, and can maybe see the path AppSheet is headed down here with moving from Actions/Workflows/Reports across to Automation, although from this item 5. only at this stage:

Today I notice that we can now only edit existing workflows and reports and not create them in the traditional way. It seems that experienced users are being โ€˜forcedโ€™ to stop building in the โ€˜traditionalโ€™ way, and across to the automation area; for reasons on โ€˜difficultyโ€™ and โ€˜styleโ€™ associated with the traditional/old way:

โ€ฆ

Is something fundamentally changing in the way actions, workflows (logically linked and conditional actions) and reports (scheduled, and/or multi-row repeated actions) are created? Or would it please be possible to keep the option available to create workflows and reports the old way:

Please keep these as available options?:
3X_a_8_a887ae9bdd7201bf1177a459f35351bcb772def9.png

3X_c_3_c36b4eea4585f539d76163b2634420e74f4b9271.png

(I also have a fear, that the โ€˜+ New Actionโ€™ button might render in the above manner soon tooโ€ฆ???)

Couple of frustrations with Automation so far:

  1. (maybe Bug / not intended?) when you copy a Bot it automatically creates a duplicate event โ€˜event 2โ€™, duplicate processes โ€˜process abc 2โ€™, โ€˜process xyz 2โ€™ and duplicate tasks โ€˜task abc 2โ€™ and โ€˜task zyz 2โ€™ for example if the Bot has more than one process in it and a process has more than one task in it. It ends up creating a bit of a mess. Can this be resolved to just copy the Bot and name it โ€˜Bot name 2โ€™ and then just pick up the same events, processes and tasks?

  2. With Scheduled Events - it would be good to not have this specific to a single table. As it stands if I want to run a process on one table at 7am in the morning, and also run another process on a second table at 7am in the morning; I have to create two separate โ€˜eventsโ€™. It would be good to just have the event being that it is 7am. Then, that event could be readily re-used to trigger different processes which work on different tables. As it stands I have to come up with many different ways of labelling my 7am events differently (unique names). Like โ€œ7am for this tableโ€, โ€œ7am for that tableโ€, โ€œ7.00amโ€, โ€œ7AMโ€โ€ฆ

Iโ€™m happy to move across to automation over time, especially if we can fold in โ€˜listening for outside eventsโ€™, but it doesnโ€™t seem ready yet and provides (me personally) no benefit (yet). I have some very complex processes running well; built on the current/old methods - and would really like to see both options remain.

Thank you for taking the time in this community, you are right - we are passionate - because of the power of AppSheet, and your engagement!

Kind regards,
Ed Cottrell

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.

Top Labels in this Space