I am looking for advice on the best architecture to adopt with a AppSheet Core account.
The Goal: I want to manage development requests coming from different teams.
Master Sheet: Contains ALL requests.
Sub-Sheets: Separate Google Sheets for team project.
The Requirement:
The Sub-sheets should only contain specific rows (filtered by type of development) and specific columns from the Master Sheet.
Bi-directional Sync: I need edits to happen both ways. If a user edits the Sub-sheet, it updates the Master. If the Master is updated, the Sub-sheet reflects the change.
My Questions:
Is it technically possible and reliable to achieve this physical file synchronization (Master ↔ Sub-sheets) using AppSheet Core (perhaps via bots/automations)?
Or, would it be better to just use a single Master Sheet and use AppSheet Security Filters and Table Views to simulate these “sub-files” for the users?
I want the experience to feel like a spreadsheet (Table View) for my users, and I’m open to others solutions (others platforms, others type of architecture, …)
You’re looking for non blocking I/O DM me I’ve got a hybrid quantum via nvidia Cuda-q and optimization inversion via jax based technique of collapse the wave function and retrieving zero copy security abiding MCP like junction points
@Lou_PAUMELLE Without having to over engineer things, I would simply move towards your own option 2 mentioned.
You can have the master sheet contain all column options for different types of development, then using Security filters to ensure only correct subset of data comes through to user logged in.
On the Forms/Views you can control which columns show based on the type of development for that team.
Here you will have a single source of truth instead of splitting up your backend data.
AppSheet handles slicing of the data for viewing purposes very well. AND…If your app is received well, you will likely be asked by management to provide summations across a portion or even ALL projects. Having the data in separate sources would be a nightmare to re-combine.
CAUTION: we don’t know your data building skill level so it MUST be said….having a single “master” table does NOT mean to place ALL the project information in this one table. It only means that you have a single PARENT table to represent all projects. I.E. You still want a solid data structure to represent ALL projects efficiently.
For example, you might have various types of projects and each one has very different properties to track. So you might want separate child tables for each of the project types.