Apps Script Tasks are now available: Call Apps Script functions in AppSheet Automation

[nico]

We're happy to announce that Apps Script Tasks be rolling out for all users in AppSheet this week! This will allow you to natively call Google Apps Script functions within your AppSheet automation workflows, enabling your apps to tightly integrate with over 30 Google Workspace apps and APIs like Drive, Calendar, Gmail, and even external services.

Example uses:

• Create a calendar appointment when a button is clicked
• Add a slide to a presentation when a new row is added
• Save photos to Drive and share with specific individuals when uploaded via a form
• Create an audit log by generating a Google Docs file with data from a table

The feature will be rolling out to everyone this week (starting April 12th) and be available to all users later this week. 

What should I try out?

We would love for you to help us validate and give us feedback on:

• Task configuration usability
• Authorizing a script
• Any problems with parameter passing or task execution
• Any error states and edge cases 
• Any specific use cases you will find useful to test
• Important note: please do not use production data for preview features

Find code samples and our walkthrough video in our Help Center.

How can I configure an Apps Script Task?

1. Go to the Automations page in the AppSheet app editor.
2. Create a Bot (AppSheet Automation)
3. Create a new task
4. You will see a new top-level task type: Call a script in the task configuration panel
5. Select an Apps Script project from your Google Drive. Note: you may have to authorize the Script with the “Authorize” button in order to execute it
6. Finally, select the function to call, and specify the expressions to pass as arguments

You can also click the button to open the Apps Script project in a new window, which will bring you to the Apps Script editor, to edit the script directly.

Limitations

• Apps Script executions are subject to standard Google Workspace quotas
• Apps Script tasks are available to all creators in the prototype phase and available for deployed apps for the AppSheet Core plan and above
• Return values from the function are not yet supported
• Running Apps Script from a Service Account is not supported
• Please visit the Help Center article for details & limitations

How do I give feedback?

Please add comments/reply to this post!

We'd love to hear if you have any specific use cases in mind for Apps Script Tasks. If you have any other feedback, please share it in this thread as well!

[Koichi_Tsuji]

@carlinyuen 

My suggestion to you is to start you developping works for new features by taking into account the feature requests from ths commumity place. It is obvious that our voices are not reaching out to your teams.

It is obvious for me that your team is asking feebacks from the community after releasing new feaures (preview though) to sound the opinions from users......

From myself, it is opposite direction.

Taking the voices from users (this community place) first ane examine such feedback first, then pass it onto development works.

These days, I feel the way to do is completely opposite. 

As far as I remember, before the Googe aquisition is to happpen, ti was like that. 

But after that, the thngs are up side down......

Whatever we claim on the feature request, then strange new features are added and we are asked for the use case for you newly developped features.

For me , not making sense, so this is making me gone quiet on this community place, as I noticed our voice in this new commuity place is not reachinhg out to you guys.

[carlinyuen]

Koichi, I hear your frustration and I appreciate that you are explaining from your perspective in terms of what you see and feel.

From my perspective as a relatively-new person to AppSheet, it is not that we have thrown out all process of listening to customers and are just developing whatever we want -- we do look over feature requests in the community and track them in our internal roadmaps, and perhaps the team can do better to make sure the community knows that these requests are heard.

In my opinion, to give you a sense of why things may feel like they are changing: we now have an expanded set of customers and requirements who are not always on the community. I understand most folks here build apps for your own customers, or are the primary AppSheet champion for a larger company -- which is amazing and we appreciate the feedback and sharing of use cases, etc. -- but imagine if you suddenly get a very large influx of new customers/users with different needs. We're just trying to balance the requests from both the community as well as many other channels, and it sounds like we could do better to share why some things are prioritized over others (in addition to what I said about making it clear we are hearing and tracking the existing requests).

As my own personal suggestion, it may help us prioritize feature requests from the community if you could share how many expected new users or customers you expect to get as a result of a particular feature, for example, or if it would unblock use of AppSheet for a significant portion of use cases that can create a lot of potential use. This would let us prioritize these requests more heavily compared to others.

[takuya_miyai]

@carlinyuen 

I feel it is not your responsibility, but with no response to this ticket, I feel similar to koichi-san impression.

https://www.googlecloudcommunity.com/gc/Community-Feedback/Looking-forward-to-further-Feature-idea-s...

@AndrewB 
@Lauren_vdv 
@Pratyusha 

@Koichi_Tsuji 

[carlinyuen]

Understood, Takuya, appreciate you sharing that example -- we are aware of this but it's a bit of an interesting issue because we get hundreds of requests also from Intercom, our sales team, etc. and we are trying to track in one place, but want to avoid having to go to multiple places to update all the statuses everywhere (imagine updating 1400 requests, with no API to do it, and then having to do it in two places).

I'll bring this to the product team and see how we can improve on the side of communicating and making sure folks here know they are heard. Internally, we often link to these exact posts and feature requests in our trackers and in our requirements documents, but I think perhaps with the community migration and recent changes (both in team and processes), we have not been consistent with engagement.

[SkrOYC]

---

@carlinyuen wrote:

we now have an expanded set of customers and requirements who are not always on the community. I understand most folks here build apps for your own customers, or are the primary AppSheet champion for a larger company -- which is amazing and we appreciate the feedback and sharing of use cases, etc. -- but imagine if you suddenly get a very large influx of new customers/users with different needs. We're just trying to balance the requests from both the community as well as many other channels,

---

I think that this confirms what I fear since the beginning.

We are not important for Google

We are just part of a big wave of users from AppSheet's POV.

At least now I know that I'm not losing anything if I leave the community. Before, the community was the main area where the most passionate and experience creators were, now it's clear it's not the case, at leas that's not what Google thinks of the community. Google is misunderstanding everything here, but hey! I never expected Google doing the right thing, they have always been the evil for me.

You are making a big mistake here. Well, you already did it.

[Koichi_Tsuji]

Only simple suggestion from me is to go back to Appshee team (what they did before Google) to listen words from actual users first. Then pass it to new deveopment works to make the patform better and gain more peope getting onboard.

I bet you it was before , but now i never feel such.

Your team (google) goes in a way you believe it is right, but leaving us (actual users ) behind.

It is a danger 

[Steve]

Likewise, I trust you understand that ill-informed, poorly-considered decisions on your end create problems for app creators and those of us who support them. Changing design decisions after they make it into the wild is extremely difficult, since those fixes will break apps that have come to rely on the broken behavior. It's frustrating to watch AppSheet make mistakes that have been made by so many others before.

[takuya_miyai]

Hi @nico @carlinyuen 

I ran a Task that uses Apps Script on the app copied by the new owner.
The Apps Script is still in the original owner.
Nothing succeeds because execution permissions are not shared. So far so good.

However, when I check the Automation log, everything is Complete.

 

Since I can't get a return value yet now, I would expect a Complete log to be left at the point where I call AppsScript with no permissions.
Am I correct in my understanding?

[carlinyuen]

That's a great catch, @takuya_miyai ! We will look into this, thank you!

[nico]

A bugfix that should properly show these executions as errors in the Automation Monitor will be live after our deployment scheduled for today, if you still hit this issue after that, let me know. Thanks for the report!

[takuya_miyai]

Thanks @nico ,

I will try it if that is released.😁

[takuya_miyai]

Hi @nico @carlinyuen 
It may be just my environment, but the instanceof String in the createHourLongCalendarEvent function is not working as expected.
Even if I pass text, it is not determined as a String and all events are created with "My event".
(It may be a potential bug in the Apps Script.)

https://help.appsheet.com/en/articles/6048533-use-apps-script-to-create-a-calendar-event

function createHourLongCalendarEvent(title, startDate) {
  Logger.log("title is: " + title);
  Logger.log("title type is: " + Object.prototype.toString.call(title));

  const eventName = title instanceof String ? title : 'My event';
  Logger.log("eventName is: " + eventName);
  const startTime = startDate instanceof Date ? startDate : new Date();

  const endTime = addHoursToDate(startTime, 1);

  var event = CalendarApp.getDefaultCalendar().createEvent(
    eventName,
    startTime,
    endTime
  );

  console.log('Created event with id', event.getId());
}

The following modifications made it work as expected.

  //const eventName = title instanceof String ? title : 'My event';
  const eventName = typeof title == 'string' ? title : 'My event';

Thanks,

[takuya_miyai]

Hi @nico @carlinyuen 

Google Chat integration sample required the same modification.😎
https://help.appsheet.com/en/articles/6048427-use-apps-script-to-send-an-interactive-chat-message

function sendMessageInGoogleChat(message) {
    //const text = message instanceof String ? message : "Sample text";
    const text = typeof message == "string" ? message : "Sample text";

function sendCardMessageWithLinkInGoogleChat(url) {
    //const orderUrl = url instanceof String ? url : "https://www.appsheet.com";
    const orderUrl = typeof url == "string" ? url : "https://www.appsheet.com";

[nico]

Thanks Takuya -- you're right, you found another bug in the samples. I'll fix that up.

[ScottE]

ISSUE: Date/Time TimeZones

I have a formula DateTime(Now()), which, when tested in the Expression Assistant, correctly display my current local date/time for CDT USA.  

However, the Apps Script variable received is unexpectedly GMT - 4 hours. 

EDIT: Reverted to Old Script Editor to manually set the time zone for these new scripts to Central, USA, so now it displays GMT- 5 hours.

Is Appsheet supposed to pass (Apps Script to receive) the variable without timezone conversion?   

[nico]

Good question! The `NOW()` in AppSheet is localized to your timezone and the `Date` in Javascript is displayed in UTC time.

The fix is just to use `UTCNOW()` instead of `NOW()` in AppSheet if you want to pass the same time to Apps Script.

[ScottE]

EDIT: I finally realized the variables are NOT being passed as simple text variables, when a LIST is passed, it's received as an array (nice), I just was not expecting it. 

So I'm now converting my dates to UTC in AppSheet       UTCNOW()-NOW()+[Date Time]

Strange that the converse             [Date Time]+UTCNOW()-NOW() throws an error..." inputs of an invalid type 'Unknown'"

Thanks

[nico]

One thing to note is that currently AppSheet passes all dates to Apps Script as though they were UTC time.

To display your local date you can use `Utilities.formatDate(appSheetDateArgument, "GMT", "yyyy-MM-dd'T'HH:mm:ss'Z'")` and this will display it as the date you pass in from AppSheet. See Utilities.formatDate doc for more info. You can wrap that around a `new Date()` if you want to get a local Date object.

Also see Apps Script Working with Dates.

This might change during preview, we should perhaps be adjusting the Date passed to Apps Script based on what's configured in the Apps Script project so that those line up more intuitively. I'll discuss with my team.

[nico]

Hi Scott,

Just wanted to let you know I've updated the code to pass the date as a string instead. So now you can just go `new Date(dateString)` within AppSheet and it'll interpret that date as if it's from your local timezone so that should be able to simplify all the hacks you need to do to workaround this. Appreciate the report!

If you want to force the date to be UTC instead, you can use the `Utilities.formatDate()` trick I mentioned below but I think most people will just want the time in their local timezone.

Also wrote this table about how the types get translated to hopefully make that a little easier.

[Marco_Antonio_N]

Altere o fuso horário nas configurações do projeto

[takuya_miyai]

Hi everyone,

It seems that the url type must also be cast to Text (string).
If the published chat sample does not work as expected, modify it as follows or set Datatype to TEXT.

 

 
Chat integre sample
https://help.appsheet.com/en/articles/6048427-use-apps-script-to-send-an-interactive-chat-message

@nico 
@carlinyuen 

@Koichi_Tsuji 

[nico]

Right now the url gets sent as a serialized object like:

"{\"Url\":\"https://www.google.com\",\"LinkText\":\"Google\"}"

I agree it makes sense to just send the url as a string (so just `"https://www.google.com"`). Will make an update for this in the coming days.

[scott_robinson]

Feature request 😀

Would it be possible to open the schema of the data structures Appsheet holds as constants to be used in appscript tasks? 

For example, currently I am passing the sheet id and column numbers into various scripts so that values can be manipulated.  Of course the column numbers may change as I add or remove columns from my sheet schema.

What I'm asking for is a way for Appsheet to provide the column numbers and sheet id based on what it knows about the schema? 

[This sheet].[Id]

[Myfield].[Colnum]

That sort of thing.  It would make it much easier to copy apps that copy the schema rather than use the same data?

Just a thought 🙂

[carlinyuen]

Hey Scott, that's a really interesting idea! I've added it as a request to our internal tracker as a suggestion for the team that works on expressions/etc. Thank you.

[Koichi_Tsuji]

I always welcome any additional new features to AppSheet, including this integration with Google Apps Scrips for sure.  However, I m also personnelly puzzled to find out what is going to be real addtion to App Creator by this new integration. 

My point is AppSheet is by nature "No code" platform.  Thanks to the beauty of AppSheet, we coud managed to achieve what we want to do "without coding" at all. Before AppSheet, only those who have knowledge for coding managed to do something fancy. But AppSheet breaks it through. The person like me, without coding knowdge, managed to do more what coder could do within the same amount of time flame. 

It was my understanding that AppSheet is delivering new no-code solutions to no-code based developper to do without coding. Yes. indeed Appsheet succefuly achieved this task.   In terms of integration with Google workspace products, AppSheet is now making it to happen without coding. Then the question is this new integration with GAS from AppSheet is going to add what sort of values?   I spend weeks to come up with ideas in terms of the possible practical use cases where the app creators and users feels the tons of benefit through this integration, but unfortunately, i come up with anything at this moment.  

Yes, i got an idea. But actually it can be done without GAS, but achieve by AppSheet no code solution.

It is always happening no code solution including AppSheet can not satisfy the business needs. Then . we need to move to the coding solution to fill the gap.  

These days, both no-code, coding solutions are developping everyday.  Once we see a new day (tomorrrow), it is possible we can manage one task without coding with Appsheet, while it could only be done by coding.      No-code/coding is always competing.  Once the coding add new solutions, then no-code solution can not compete such.  Coding wins.  Then after days, no-coding solution provide new solution to achieve the same. Then coding solution is getting old-fashoned.  Then no-code come up with new solutions. Then no-code solution lose this game as it can not manage such.... It coud be ever-green kinda story.

All in all, I wish to sounds the opinion and notion from Google development team why GAS integration with AppSheet is believed to be real-addition to the values for AppSheet average "non-code" developpers, including the use cases we can consider to employ this new integration during our daily activitives with AppSheet to develop new apps.

Taking a look into the sample GAS code, i could not find any of them which is going to be found useful.  Adding new event to calendar.  Yes, we can do wihtout coding, by adding google calendar as data souce to appsheet.      keeping data change log by using Logger.log() method. Okey, we have audit log.

Again, i m not able to come up with much of practical use cases with gas integration.

What we are missing "GET" verb with Appsheet.  

If we could use the custom function made by GAS, which "RETURN" some value, and then we could use such GAS made function withing Appsheet Editor, I wil bring MASSIVE number of new use cases for sure.

I just wondering where AppSheet team want to bring us (appsheet creators) with this integaration.   At least, it looks like the new integrataion is contradicting what AppSheet claims "We provide No-Code solutions".

@takuya_miyai 

[Koichi_Tsuji]

I only come up with possible benefit  with this integration once.  Sending bulk emails (like 10k email) With appsheet automation, it faile due to Automation limit. (such as 2, 5 mins limit or restriction made by Google Chime  services to deliver mails).

However, I found out the quota of Google apps script is poor.  We are only able to send mails with scrip, max 1500 per day......  Not gonna work.

[SkrOYC]

I completely understand this POV.

It seems like lately the main goal from the Google team is to integrate AppSheet to Google's services. Google Drive docs, Google Calendar, now Google AppScript. Things that for me (a non-Google user) is absolutely useless.

While, at the same time, features that would benefit all users like the Desktop UX/UI, more databases support, support for response parsing on the Webhook, GET HTTP Method, etc, are left behind

[Koichi_Tsuji]

As far as my opinion is concerned, triggering GAS with this new integration is not adding much to us.

We can trigger GAS by another mean.

Real benefit in terms of integartion between GAS and AppSheet is make GAS function as custom AppShet function to GET data whatsoever.  I mention about it 3 years ago.

[Koichi_Tsuji]

If we (appsheet) deeper the integration with Google Workspace produce, it must be "NO CODE WAY" at last. that is my understaing when it come to dealing with AppSheet..... Otherwise it contradict with what we (Appsheet) appeals.

[SkrOYC]

To be honest I left my idea of AppSheet as a no-code platform while ago, almost when I started.

I think that there is no such thing as no-code if you have to write functions/expression and some may debate that the average GSheets/MSExcel user is a coder in that case.

But I strongly think that AppSheet is rather low-code, at least if you don't use Webhooks, then it starts to go up into coding.

Even templates for the reports are waaaay better when they are made using HTML/CSS in comparison to the common GDocs/MSWord.

In other words, it's hard to provide a real no-code solution, and I'd like to see AppSheet advertised as a "almost no-code" rather than a no-code platform, since the last part sounds like a lie

[Koichi_Tsuji]

There is always (forever) the gap between coding and no-coding. It will be probably for another thousands years.

So we need to have a "Bridge" between no-coding and coding. So I advocate the integration between GAS and Appshet is welcome to fill the gap. Such an integaration is welcome, in order to fill the gaps, which are always there.

But from AppSheet perspective, the way to do must be "no-coding way".

On coding side, yes it is always coding skills are required, as we need to write codes.

But once the code is there, the way to call such function must be in no-code way.

My absolute dreame is no-coder like me just copy (or slighly amend the code) and save as script file. Then  call this function from AppSheet to GET data.

Again such a process must be as much as NO CODE way.

We are taking about Coding and No-Conding at the same time. So the gap never gonna be filled. I m not talking about it.  

As a target, where we need to write a code, just leave it . But when we need to CALL them from Appsheet, it should be no-code frendly as much as possbile.

Current integration with GAS (preview status) is away what I dreamed. Furthermore, not able to find out what they are brining read benefit to "citizen developper (no coding skills and knowledges).

AppSheet team's major task (should have been to) deliver the non-coding solutions. Then, now what is going to happen after this new integration?

Majorities of the community member here in this commuiny should be non-coder. Then. what they feel like by reading those thread? Feeling noghing jsut close the tabs on browser as it is beyond their knowledge.

[Koichi_Tsuji]

The main point I wanted to highlighted as my personne opion was Appsheet is likely to be departing from the position as no-code solution, but getting closer more to pure developper tools.

I feel such a risk for the moment.

[Koichi_Tsuji]

If this is a target set by Google (to make AppSheet as dev tool), I have no way, but to learn programming languages to deal with Appsheet.

[zito]

Hi folks,

I wanted to address a few of the different comment threads here, and rather than jumping around, I thought it better/easier to write one response in aggregate.   

On the topic of "is AppSheet becoming a developer product", I wanted to reassure that the answer is an emphatic "no". When I joined the team, I also had a mental model of "AppSheet = no-code" and "Apps Script = developer", but when we started talking with the Apps Script team, it turned out that we're actually serving largely the same user base.   Apps Script creators are primarily business and process owners trying to solve a problem, not developers who want to write code.  In fact, from research we conducted, a higher percentage of AppSheet users were technical or had development experience than Apps Script users - more than half of Apps Script creators had no previous programming or development experience.  On top of that, one of the most common uses for Apps Script is automation of a process within Workspace, rather than building a full application.

The purpose of offering Apps Script support within AppSheet is not to shift AppSheet more in the developer direction, but to offer the same people another tool in the toolbox - if you want no-code, AppSheet is there for you.  If you want code or want to do particular tasks within Workspace, you'll use Apps Script.  If you want to combine those, we have the tools to enable that.   In addition, while it's true that you could already connect to Workspace from AppSheet via a few different existing capabilities, there's a lot of sample Apps Script code that is already out there to accomplish various common tasks, and we do expect some new users to find it easier to copy a snippet of code as part of building an app than figure out how to interact with APIs.  

That brings me to the second point - our commitment to the community.  I wasn't here for the pre-acquisition days (obviously), but I know that Praveen and the rest of the team were very active and engaged,  with a lot of focus and investment on the people here.  As an example, Carlin and I happened to be meeting up with Santiago yesterday while he was in NYC, and when the subject of the community came up, he spoke in detail about how closely he's worked with a lot of the people active here and how much you have contributed to the success of the platform.  If we use that as the baseline, it's painfully obvious to the team and me that we have failed to engage at any level approaching what it should be, and it's completely understandable that there's frustration around seeing a feature like this launch in the absence of any other real engagement on the requests that have been made here.  And I'm sorry that's where we are.

I've been working with the team to put together a plan for how we're going to rectify this - I certainly can't promise that we're going to be addressing everyone's asks and requests, but we can be as transparent as possible on how we're taking feedback from folks here and what actions we are taking based on that.  We just want to be thoughtful about it - there are some legal issues around publicly committing to features (e.g. someone reads a post here, sees that we said we were working on a feature, buys AppSheet because of that post, we end up not building it, suddenly there are legal implications),  and in many cases we might bundle something into a larger feature that requires a longer time horizon to build.  

Next week, once we finalize things, we'll start a new thread to talk about our 2022/2023 plans, and how we plan to partner with you going forward.  I realize that's an easy statement to make, a more difficult one to deliver on and commit to long-term, and will probably require some iteration and evolution, so I understand any skepticism you might feel (I would feel the same in your shoes).   The office hours program that Peter kicked off is a good step in the right direction, and he's already planning a bunch of great content primarily targeted at folks here, but we can get more specific about what we're building and why.  

This post is quite long already, and I'm conscious that it's not the original point of this thread, so I'll wrap things up here.  We'll share some more details next week in a new thread and start a conversation there, but I'm happy to continue to engage here in this thread (or privately via email- zito@ google.com) - I'd just ask that we try to keep the feedback about the feature constructive.  Carlin, Nico, and the crew care deeply about shipping the best features possible, we want to get it right, and we're asking folks here because we know that you have the deepest knowledge and understanding that can make it the best it can be.

Thanks for everything - Matt

[Koichi_Tsuji]

Thanks Zito for your detailed comment, I appreciate.

I do not intend to argue, but I just wanted to share my honest opinions here in this community where I have been here for almost 5 years time, since 2017 as AppSheet partners.

Firstly I wished to highlight "who are active appsheet creators for the moment?"  

>

In fact, from research we conducted, a higher percentage of AppSheet users were technical or had development experience than Apps Script users - more than half of Apps Script creators had no previous programming or development experience.  On top of that, one of the most common uses for Apps Script is automation of a process within Workspace, rather than building a full application.

>

Since the new Automation is introduced (to replace the old workflow), the process to set up Automation is getting more "coding nature" rather than pure no-code solution. Yes, we admit the Automation brought us more flexibilities and options to automate things, more than old workflow. However, UX/UI is naturally getting more complex.  If AppSheet is designed for "Everyone", not questioning to the level of literacy for codking skills. Then AppSheet started to deviate from that since Automation introductions.

We are running Online platform to educate and encourage no code developper here in my countery.They are basically not carrying any coding experiences before.  They are equally claiming Automation is difficult to understand.

Yes, for those who have coding experiences and knowleges, it is rather easy how Automatin is gonna work and how we should them them up.    

Im not blaming Automation only, but this is one of the examples.  Once the new app craetor gets onboard, then they found out Appsheet is difficult (not only because of Automation, but it sould be one of the reasons)  Then it is also possible they drop off as app creators (They forget about appsheet as they may find it difficult to deal with)

At the end, the remaining app creators now wokring is left to the group of people who have past experiences or least knowledges about coding (inc. Gas capabilities).  

My point is your stats may reflect the result of this ????  I personelly and highly doubt about it. If stats shows the majorities of appsheet creators may have coding skills....  , this should be taken as nagative sign rather than positve, as basic notion of appsheet is it is for no-coders. If majorities or high percentages of app creators are carrying least coding skills, then Appsheet is no longer called as a tools for "Citizen Deveplopers" Yes it is also disputable subject how we define who is "citizen developpers"  Taking your comment, it appers to me you admit the citizon developper needs to have least coding skills to deal with AppSheet. Then from my point of view, we are not able to push AppSheet to the public as citizen developper tools, as my definition of citizen developper is totally different from yours.

Again, I welcome any new features including GAS integration. I m happy with that.  However, we may need to address such a features as DEV tools in order to put the line between coder and non-coder, rather than mixing up all and say everything is for non-coders.

But I m now deviating from the original point I wanted to initially highlight through my post.  

As a result of the integration with Appsheet and GAS, what we could achieve the best?   The sample gas is just prepared for demostration purpose, and not prepared to solve the busines challenges. As I mentioned before, things are soved with Appsheet native no-code solutions. What is a "top up" to it by GAS integartion? 

Maybe the community will tell from those who find out the solutions which solves the common business problems which the community member here may have. But again as I mentioned in my past thread, I m not able to come up with any new idea what sort of new GAS code (integrated with Appsheet) will bring tongs of new values to the appsheet creators.

From my point of view, new features need to carry new values to the users. But for now, I m not able to come up with anything, super honesty speaking.

I welcome Appsheet team to educate me to coach what is the most effective and efficient use cases where we use this integration.

[Koichi_Tsuji]

In terms of new features which have been added, I see much of new features which are taking the voices from the community (reflecting the feature request the community members post).  If the Appsheet new features are driven by the own "reseach" reather than post for "feature idea/request", why we need to throw our idea to that category???

The feature idea/request category is not really attended from my point of view.   Before (at least aquisition), our voice was instantly reaching out to Appsheet team, and next week we see new feature.  It was good time.

[zito]

This is one of the things I'm working with the team on a plan for - figuring out a way to track which asks from the community are being worked on, share updates, etc. without adding a significant burden on the team or missing things.  Before the community migration, it didn't make sense to put in place something that was going to change once we migrated, and we're simultaneously working on consolidating all of the various sources of feature asks - as Carlin mentioned, we have a number of different input streams for feature requests, and we are trying to trim that down to something more manageable. 

None of this is your problem, of course, and I see your point that there's no point in contributing feature requests if the community sees no engagement on any of them.  We will start a thread next week to talk through this, and we can see what we can do to manage the content that is there currently.

[zito]

I appreciate your thoughts, I don't see them as arguing.  For what it's worth, I agree that the usability of AppSheet leaves a lot to be desired, automation in particular, and I also completely agree that the learning curve is one of the things that lead to a higher percentage of AppSheet creators identifying as technical.  We are investing a significant amount of effort this year in improving the user experience for both the app UI itself and the creator UI, and I hope to share more details about that soon.

Similarly, I don't think our definition of citizen developer is different - we want anyone to be able to build an app, automate a process, etc. without needing to have an engineering background or experience developing software.  I don't think we're hitting that goal today.

As far as whether code != citizen developer,  (just speaking for myself) I think it's not a black or white distinction.  If I put =sum(a1:a28) in a spreadsheet, am I writing code? To me, that seems to not reach the bar of "coding", though Excel is Turing-complete.  Similarly, a simple AppSheet expression seems like something anyone who understands how to use a spreadsheet can learn without needing to be technical or a "pro-developer".   And then similarly, while it is true that it is possible to use Apps Script to build full applications,  most of the Apps Script usage that is written by non-technical users are fairly simple and short scripts, and most of it is copied from scripts written by others.  So, to me, in the same way it's possible to have a formula in Excel that's easy enough to not be coding AND possible to have a complex enough formula that you have to be a software developer to write it, it seems possible to have simple Apps Scripts that don't reach the level of "coding".  That's just my opinion, though.

Back to your question, in terms of activities that you can complete with an integration with Apps Script that you can't already complete with AppSheet, I think there's two high-level categories of usage:

• As an AppSheet creator, I want to use an Apps Script written by someone else 
  • In this particular case, I very well might be able to accomplish the same functionality today in AppSheet, but I have a provided script that does the task already.  Perhaps it was written by an admin or pro-dev, or perhaps it's the organizationally approved way to accomplish something, or perhaps I found it on the web.  Apps Script has multiple orders of magnitude more users than AppSheet, so it's not uncommon that someone on a team might know a little bit of Apps Script and can give me a snippet of code to do something.
• As an App Sheet creator, I want to use an Apps Script because it's more streamlined than doing the same activity in AppSheet
  • One example that comes to mind is generating Google Docs and other types of Workspace documents.  AppSheet can generate PDFs, HTML, etc. of course, but can't easily generate Google documents, whereas Apps Script can do this natively.  I know some folks have found ways to do this in AppSheet, but none of the solutions I've seen look straightforward
  • Another example might be to interact with calendar appointments at a more fine-grained level than AppSheet facilitates today - for example, I don't believe it's trivial to accept or reject an existing calendar appointment.
  • Other Workspace services where AppSheet does not today have native integrations - Google Group management, for example, is a very common automation scenario, and most of the ways I've seen to do that in AppSheet involve manipulating a Google Sheet that itself has Apps Script that triggers the group management.  That works, of course, but as part of a larger workflow for onboarding a new team member, it feels messy and potentially brittle.

I will freely admit that my experience with AppSheet is much more limited than anyone participating in this thread, so it's possible there are clean and easy ways to do some (or all) of these things that I'm just not aware of, and I'm happy to be corrected if so.   I eagerly look forward to the day when I can go toe to toe with anyone here in terms of AppSheet expertise, but that day is not today. 

The higher level perspective is that AppSheet is incredibly powerful, so it can be made to accomplish so many things, especially as a creator's expertise grows - but many of those things can require significant effort to get right, even more so for less experienced creators, and Apps Script can bridge some of those gaps.  

Thanks for the feedback and the perspective.

[Steve]

---

@zito wrote:

• As an AppSheet creator, I want to use an Apps Script written by someone else 

As an AppSheet creator, I want to reuse and share parts of my app configuration. I can't even do that. Why would I want to branch out into a completely different platform? Why not focus this effort on the many flaws AppSheet has?

[Steve]

---

@zito wrote:

Next week, once we finalize things, we'll start a new thread to talk about our 2022/2023 plans, and how we plan to partner with you going forward.

And?