discrete team datasources with single AppSheet app

I am building an Event Management app (for internal users only) that has nothing to do with actually scheduling or user enrollment of the event (we want to handle that with our CRM), but rather management of the sessions (where users are assigned to attend, not self- enrolled etc), so its akin to a Conference Agenda app. I have yet to figure out how to integrate with the CRM backend (tables, etc) for this question, let’s just assume a single, event-specific Sheet (DB) with multiple sheets (tables) is generated for use and editing by event-specific (not organization-specific) admins. Let’s also assume that the CRM (website) will take users to the correct “instance” of the event app.

This awesome how-to How to use Security Filters to allow multiple companies to use the same appfrom @MultiTech is in the general vein of what I want to do, however,

  1. there will never be users or events (companies in the tutorial) added from the app (the CRM will always handle both of these tables)
  • not a problem- just skip that part of the tutorial1. There is nothing confidential in which we need to shield users from Event 123 from seeing Event 789, thus complex security features/filters are not needed
  • However, it will be just best practice that a user needs to be in the user list for an event to have access to it1. user roles for the same user may be different for different events
  • ie, John Doe is an admin for Event 123, but just a standard user for Event 2381. Datasiurces will pre-exist as “templates”, which again, the CRM will handle
  1. The tutorial was not clear in how it handled all of the data coming in from different companies running the app, however:
  • Mixing data into master tables from different companies (or in my case, events) is just unwieldy and a complete non-starter (I’m not meaning to suggest this was recommended anywhere)
  • Mixing tables from different (yet similar) Events would be equally unwieldy as we are taking a couple hundred events annually

At the end of the day, the logical programmatic perspective would be to:

  1. store variables in the App as placeholders to point to a different datasource(s)
  • I do not believe that AppSheet provides this functionality for datasources?
  1. pass values (from website/CRM) into said variables upon invocation
  • I have now discovered that there is an AppSheet API, but in the little help I have found (admittedly not much time spent doing so), I am not even certain that this will provide what I am looking to do?

While this post may have been wordy (not sure why my indented sub-bullets have an extra line spacing?), I don’t believe what I am trying to achieve is really too far out of expectations for what should be a functional application of the tool. Any help here is greatly appreciated.

#1 - AppSheet has a feature called Partition where you can select the different data source based on your data in the app. The column structure needs to be the same and the data provider as well. Meaning.. you need to have the same data source like Google Sheet for all partition. Or SQL for all of them. So you can’t mix them.

#2 - If you need to send the data just from your CRM to your App using webhook, you should be just fine.

EDIT: The partition feature needs AppSheet Enterprise subscription.

3 Likes

Hey @jharkless , I’m glad you’re finding that resource helpful!

Sounds like you’ve got a good handle on what you need and how you can make AppSheet do what you want.

As mentioned by @AleksiAlkio , you can use partitioning if you’ve got an enterprise account.

But in general, the practice is to leave everything in one data source; this makes everything dev-wise much easier down-stream.

When you say something like, “unwieldy” it makes me think that you’re still using the spreadsheet as a “source of truth” - which is it. But when you bring AppSheet into the mix, you actually do yourself a disservice by “going to the spreadsheet” to do/find XYZ. There are several reasons which I won’t get into here, but mainly it’s due to the fact that you’ll have ref values (IDs) that might not be human readable.

Thing is: now that you’ve got AS in the mix, it’s actually easier to do a bunch of stuff in your app than you might think.

  • Need to see all the stuff for an event?
    • Go to the event record, all the child data is there easy for whatever.
    • Now it’s just a matter of engineering the UX so it’s easy for you to do whatever you need to.
  • Need to update a bunch of records because you make some change and now things in the data need to be fixed?
    • Make a slice to isolate the specific records in question
    • Make an action to accomplish whatever you’re wanting (which could actually be a stack of things)
    • Use a scheduled automation to run that action on all the rows in the slice
    • Delete everything (no need to keep it, it served it’s purpose).

There are a lot of things that will be much easier to accomplish inside AS because of the parent-child refs and how they’re presented in the app. etc. etc. Obviously I could go on forever about this. (^_^)

My advice is to try and see if you can’t wean yourself off the spreadsheet, starting to think about it as nothing more than a place where the data lives - not a place where you go to “do” things.

(Don’t get me wrong, there’s plenty of things that are easier to do in the sheet, i’m not saying to abandon it all together; just to reconsider how/where you engage with the data. You have a new tool, and it’s incredibly powerful and flexible - begin exploring how you might accomplish whatever data task you were going to do in the spreadsheet through the app instead.)


AS doesn’t support passing variables like you might with, say URL parameters. But yes there is an external API, which allows you to interface with your data.

So if someone confirmed payment, and now you’ve got like a “confirmation token” or something:

  • The original idea would be to pass that token in some way to the next step in the chain (through an object or parameter or something).
  • The AS ides is to send that value in the database in some way:
    • Save it to their user record or something
    • Make a “Confirmation” record in a table that holds this data, ref connected to the user.
    • etc.

Point being, the idea is to push the data into the database first; then when the user gets to the app, at it syncs, it will have that fresh data - and you can build your apps functionality around that (using the Current User system).

  • So that when they first enter the app, before paying (for example), things are locked down
  • When they enter the second time, after paying, things open up.

Hope it helps!

4 Likes

Thanks @MultiTech (may I call you Matt? :grin: ). I certainly did not mean to imply that anything is actually being done directly in a Sheet (there is zero intention of anything being done there). My inference that a single datasource becomes unwieldly is rooted in the fact is that not only is there literally zero value in different events data being stored together, and that doing so only adds potential confusion as each event (table) has multiple sessions (rows) that are a repeat for each and every event. To clarify, they are not identical rows as they will have subtle differences (durations, exact start times, etc) but there is absolutely zero value in the same session for XX events to be in the same table. The same holds true for the event attendees (table) and is even worst since user roles for the same user may be different for different events (ie, John Doe is an admin for Event 123, but just a standard user for Event 789). If we are successful in creating a live/dynamic link back to our CRM, this part goes away.

For help in understanding, I tried to diagram this out, as seen below.

2 Likes

Thanks for your response @AleksiAlkio . I appreciate your pointing me towards the partition feature. I will have to dig into this more, but I would like to ask- when it comes to needing a certain level of AppSheet (in this case, Enterprise), who all needs that access level- just the developer or anyone running the app? (I am going to assume just the developer)

1 Like

Yes, you may call me Matt. (^_^)

At face value perhaps; but once you build this out the way you’re thinking, and you get way down the road and you’re wanting to do other things you’re not even conceiving of right now… this sort of setup will make those things MUCH harder.

  • Like… orders of magnitude in some instances. No joke.

Think about if you wanted to push out some sort of report or something, or if you wanted to use Ai to run an analysis on things or something.

  • Having everything in the same table will make these much easier
  • Just to throw out a couple ideas. :wink:

---------------------------------------------------------------------------------------------------

But you know your situation better; if you feel there’s value in splitting things, because there is a benefit to doing that, then go for it!

I like your digram, nice!

When I think about what you’re building, I see 4 tables:

  • Event_Templates
  • Events
  • Attendees
  • Event_Attendee_Join
2 Likes

When the app needs features from AppSheet Enterprise subscription like partition, the app owner needs to have that subscription. If you have 15 users using deployed apps from that account, the app owner needs to have 15 AppSheet Enterprise licenses.

1 Like

A lot of what we’re talking about here hinges squarely on my (NFP) Org wanting the CRM (CiviCRM, to be exact) to handle as much as possible. This would take on a vary different light if I were to leverage AS to handle the entire process, including posting/creating the event (pulling from a template library, etc), attendees self-enrollment, etc, But given what I am hoping to achieve at the moment., 2 tables (Event & Attendees) are all that are needed.