Introducing: Unlinked Automation Components

[Rachelgmoore]

When we launched Automation in mid-2021, you gave us feedback that the reusability of events, processes, and tasks could be useful – but that it was confusing to implement. While some found it useful to be able to create a single automation component and use it across multiple bots or processes, making even small changes to one of these “globally” used components could have large, unintended consequences across every location it was used. You also told us that while the new system allowed for more complex flows, it actually made simple ones more challenging to build than with old-style workflows (i.e. those circa 2021 and before).

We heard you, and have been working on a variety of changes to improve the usability of AppSheet Automation for all users: from those who want to build a single-step trigger-and-response all the way through to folks who want multi-faceted business process automation and beyond.

Today, we’re rolling out the first of those changes aimed at simplifying the automation-building experience: Unlinked automation components. This change impacts how events, processes, and tasks work moving forward.

Unlinked automation components introduce a new concept: locally-scoped components. Locally-scoped events, processes, and tasks are components that exist as a unique step in the scope of a single bot*. Previously, all automation components were reusable (“global”). As of today, we’re calling these reusable tasks, processes, and events “linked automation components". Moving forward, app creators can decide whether an automation component is linked or unlinked (global or local).

Whereas previously, all automation components (events, tasks, processes) were reusable (global) components centrally available in the relevant tabs, now, only components with linking turned ON will be reusable across multiple automation components:

An event with linking turned on:

If you’re a current AppSheet automation user, you’ll recognize the behavior of components when linking is turned ON was previously the default behavior for all automations. However, with this release, we’ve effectively changed the default: now, the default state for all newly-created automation components within a bot will be “unlinked:”

An event with linking turned off (the default state when a new task, event, or process is created within a bot):

This means that the bot, process, event, or task created as “unlinked” (i.e. with linking turned OFF) will only be usable once, rather than across multiple automation components.

If you would like to reuse a component across multiple automation components (or if you’d like automations to behave the way they used to, before unlinked automations were available), simply flip the toggle switch to “ON.” From there, you’ll see that component appear in the list of suggestions when adding a new step and be able to use it across multiple automations.

Important note for current Automation users : All components created before Unlinked Automations were available will continue to behave as they did before (i.e., act as “Linked” automations). They will now appear as “linked,” and you can click on the link icon to view all bots* where the component is used:

The goal for this change is to offer app creators flexibility in how to reuse the components they build as part of their automations. For commonly used components, marking them reusable will make it easy to share functionality and drive consistency across bots. When a component is only relevant to a particular scenario, the new behavior will allow creators to keep the component alongside its context, without cluttering up or creating confusion for the shared components.

For users who need (or have been missing) a less atomic model of automation creation, Unliked Automation components are for you.

For users who appreciate the ability to create and reuse modular (global) automation components – never fear! You can simply toggle “ON” linking for any component you’d like. You can even retroactively turn OFF linking for a linked component, or, conversely, turn it ON for something you would like to reuse after all.

We hope this feature makes it simpler to use AppSheet automation for discrete, locally-scoped, “if this, then that”-type workflows and improves the safety of the system to prevent users from accidentally editing, deleting, or otherwise altering unknowingly-reused components.

Want to learn more about how to use unlinked automation components? Check out the help documentation here.

Phew! This is a big change to the way AppSheet Automations work. We’ve got more in the works, but we want to hear from you: does the ability to create unlinked (e.g. “local”) automations make your life easier or harder? How does this change your workflow? What would you like to see added, changed, or removed? Please let us know in the comments.

Sincerely,
Rachel on behalf of the AppSheet Team

*While most users will work with unlinked (local) components in the context of building a single bot, technically, they can also exist within individual tasks or processes, as well.

[SkrOYC]

Looks good, although it seems that applying new changes to the platform without community feedback is the new norm or I did not see the post asking for feedback?

[takuya_miyai]

@Rachelgmoore
I understand the overview of the features, but when will the changes be released?
I could not see this feature yet in either my Free plan or AES environment.

For commonly used components, marking them reusable will make it easy to share code and drive consistency across bots.

I am also curious about the wording of this “share code”.
AppSheet is a no-code platform.

Yes, of course I understand. It’s just a minor word difference.
But I feel this is also an important difference in awareness that has been created between App creator and the current AppSheet team.

I am concerned that the current AppSheet team does not share the vision of No-code.

@Koichi_Tsuji
@Steve

[Rachelgmoore]

Good catch @takuya_miyai ! The term “share code” was meant to convey “share functional components.” I’ll tweak the language of the post to better communicate that. We are fully aligned with the vision that AppSheet should be no-code – and if anything, it should be MORE no-code than it is today.

The change is slowly rolling out now; you should see it in the next few days.

[takuya_miyai]

Thanks @Rachelgmoore

I too was thinking that a “shared component” would be appropriate.

But I can understand why you would use the word code in explaining the global and local concepts.
Let’s expand No-code together!

[Rachelgmoore]

Huzzah! I’d like this a million times if I could

[Koichi_Tsuji]

I see this new feature is rolled to free account, and just quickly did a hands-on test.

Once we make a Process not to be reused, then there is no way to turn this setting back ON, as this process is disappearing from the Process tab. There is no toggle UX inside the bot | process config.

Or is something I’m missing from?

@Rachelgmoore

@takuya_miyai

[Koichi_Tsuji]

@Rachelgmoore

Quick suggestion is to place toggle button somewhere here?

@takuya_miyai

[Koichi_Tsuji]

@Rachelgmoore Once again, I quickly played around.

My honest opinion is still complexity is down there, not really easy to handle.

When the automation was initially introduced, I pointed out re-usability is just adding complexity, so we dont need such an option. In case we need to reuse the component, then we have option to “copy” them and then use in the new bot. That is much more simpler.

[Koichi_Tsuji]

Reply to my previous own post.

I found a way to do this.

Was difficult to find a way out.

[lizlynch]

@Koichi_Tsuji Great feedback about enabling processes. I added notes to the section to call out the fact that for processes this setting need to be configured on the Automation > Processes tab (and that you may need to click Show all) and for actions this setting needs to be configured on the Settings pane.

Thanks!

Liz

[Koichi_Tsuji]

Step, event (2 x main component for Bot) can be controlled from individual component, inside the single bot. However, we dont have control over for proess from single BOT. To be consistent, better to have :

type of control inside each BOT.

[Koichi_Tsuji]

It could be repetive suggestions as what @takuya_miyai said earlier here. ( Basically I m echoring him here)

“Global Scope” or “Local scope” are definitely programming specific terms. If we assume the majority of the member here who watch this threads are Citizen developpers, who probably do not know what Global/Local Scope mean.

Without exception, I dont have any engineering or programing experiences before. (Only self-learned)

By adding such a specific terms and words, it will add more complex to the average appsheet creator (citizen). We hope AppSheet will stay completely no-code platform. Even to deliver the new features, better to avoid to use such terms, as majority of the members here wont understand.

As I repeatedly said here, my absolute suggestion to Google team is to drop this 'modulalty" or “reusable” features. Then Automation is getting more simpler.

IF someone (1% of appsheet creators or 1% of occation where we wish to reuse the existing module) then let them copy…

[Koichi_Tsuji]

After testing new features with our free accouts, we notice bunch of bugs or odd beharivor. We simply fed up with reporting such to support / dev teams so I stay quiet.

Just keep fingeres crossed that those bugs will be fixed by someone else notice and report back to yu.

I would say “Simple is better, beautiful and more functional.” , as ex-Appsheet before Google was like that.

I would suggest Appheet/Google team do a poll to see how much and how frequently the app creator “re-use” components when it comes to Automation… Based on my past experiences, there will not be much. If it is needed, I simply copy the step/event or even creat new ones from scratch.

By copying with this reusability and modulalities, we currently have too much heavy functionalities, which are leaving the complex to our day to day developping works.

Comparing benefit and loss, we are losing much more by Google/Appsheet team pursue too much for the modulalities.

Consider new “citizen” developper get onboard AppSheet and touch Automation, then they are not aware of modulalities stuffs. As they build new bot, then face errors (because of complex config due to mobulalities stuffs), then they will move away from AppSheet as they dont know how to fix the problem. Not good for Google,as they will lose the potential customers just because of that..

Google is saying GAS is low - code (not No-code), which is understandable. However, my concern is Appsheet is getting closer to low-code instead of no-code, to match with Google;s basic notion to stay low code.

Whatever Google does, espcially in terms of automation, better to recall how it was easy to deal with ex’Workflow", which was easy-peasy for first day users who started to use AppSheet. Yes, I admit the automation is getting adavnced to deal with the more complex use cases, but the way to set them up should be in no-code way and intuitive, even for who get onboard appsheet on the first day.

The new feature here in this thread, I understood how it works, just becaure I spent too much time (5 years +) with Appsheet. But honestly speaking, it is super difficult for new comers.

At the end (to close this my own post), I m not sure why Google/Appshet is deeply stick with modulalities and re-usabilities too much… It will sqeezing own neck, while we user not feeling much of benefit for that.

[Marc_Dillon]

I think the description of this change / new-feature is massively confusing, and seemingly pointless. But I think the new process for creating a brand new self-contained bot has definitely been improved. To clarify, that’s bad feedback on the presentation of this change in this post, but good feedback on the actual change.

This post focuses a lot on this linked/unlinked aspect, but I think essentially this is now an advanced feature/setting that should be mostly tucked/hidden away, sort of like the “trigger other bots” options, and only used by advanced users when needed. I think this post would do well to highlight more about how the new process for creating a bot is more streamlined. Allow me to try to do that myself.

1. Create a new bot, same as before.
2. Inside the new bot, create a new event, same as before on the surface, but now comes with the default “unlinked” setting, which effectively just hides this self-contained event from being used by other bots, or even seen in the “Events” page by default. That’s just ok.
3. Now you have 1 of 2 options.
   1. The most obvious is the big blue button to add a new step. Same as before. But then automatically starts as a auto-created “custom task” that shows up in the right panel. Both the task and the process do not require their own names. In fact I’d guess most new users wouldn’t even notice the “PROCESS” section, which now doesn’t really matter. This is great, and a lot more streamlined.
   2. For those in the know (or maybe very curious new users), you can click the little down arrow next to “PROCESS” to re-use an existing process. Or there’s the option to create a new self-contained one, I don’t get the point of this option though? This seems pretty good, tucking the more advanced option away.

Here are a couple small issues that I found:

1. Clicking on the blue “Go to: Process” link, on an unlinked process, takes you to the “Processes” page, but unless you already had the “show all” selected on that page, it doesn’t actually take you into the process, so that is super confusing.
2. On a linked component, you get this nice list of all of the related components that use it, and they are navigation links directly to those other components, which is great. But once you unlink a component, you no longer have that handy link. I would still very much want that quick link, like from a process/event to the bot itself. 2 screenshots below to clarify.

Overall, good job, I think this change will alleviate some confusion, and just simply make bot-building more convenient and faster. But I think you could have done a lot better job presenting this change than what is in this post.

[zito]

Thanks for the feedback, for what it’s worth, I agree with you that the modularity is powerful but can be overwhelming for new users. Part of the impetus for this change was as a first step towards abstracting some of that complexity away - community feedback and user research showed that the reuse of components was a source of confusion, and the data we had suggested that only a tiny percentage of automation components were shared across different bots.

This is definitely not the end of work to simplify automation, just one incremental step. We want to be easier and more “no code” than ever, while offering “low code” options for users with more complex use cases, or bespoke requirements.

[Aurelien]

Hi @Rachelgmoore

In addition to what have been said before, here is a very minor suggestion: when a component is “not linked”, it remains available with the button “Show all”, which is great. And when clicked, we see the button “Hide not linked”.

Could that be interesting to use the same words “Show not linked”, for consistency ?

(As it is for “show system actions”, “hide system actions”)

[Erik_Ferm]

Overall, this looks like an improvement and it makes the scope of the process/task very clear.

Just a note in case others have the same issue;

I had a couple of processes where tasks were now suddenly marked as linked. I can’t go back and look but I think you used to be able to specify right at the bottom of the task pane whether they should be reusable or not and I am pretty sure these ones weren’t re-usable. Nevertheless, a couple of tasks were now marked as linked.

This is not a problem per se unless you are using values calculated by a process called earlier in the bot. If you do, the task won’t be able to reference the variables returned by the process called earlier. In my case, a template used to create a document suddenly stopped working and returned an error (without me changing anything) as it was using variables returned by a process in the bot.

So if you are using process calls to set variables in your bots, it is worth checking that all tasks referencing the variables are un-linked.

[Steve]

@zito

I agree with you that the modularity is powerful but can be overwhelming for new users.

How did nobody see that from the beginning?

Part of the impetus for this change was as a first step towards abstracting some of that complexity away

Had to blow it all up to realize the old way did, in fact, work.

community feedback and user research showed that the reuse of components was a source of confusion,

Intuition should have been enough. Again, does AppSheet consult actual in-the-field app creators? And I don’t mean Praveen.

and the data we had suggested that only a tiny percentage of automation components were shared across different bots.

Again, that’'s to be expected given the “no-code” nature of AppSheet. A “no-code” developer doesn’t think like a developer, so of course they aren’t going to develop like one. Intuitive.

This is definitely not the end of work to simplify automation, just one incremental step. We want to be easier and more “no code” than ever,

We had something vastly easier and “more ‘no code’”: workflow. You’ve got a loooong way to go to make Automation anywhere as easy as workflow. A long way.

while offering “low code” options for users with more complex use cases, or bespoke requirements.

This seems oddly inconsistent with the development of so many other features, which seems to cater only to well-articulated use cases.

[Rachelgmoore]

Thanks for the feedback, Marc! Your reframing of the announcement post makes a ton of sense.

Glad you’re finding the feature alleviates some confusion, but you’re right – lots of work left to be done to continue to improve the automation experience. We’ll take a look at the two issue you’ve called out here in particular!