So to be clear, you are wanting to add an employee to a company by viewing the employee first, and then add them to a company from the employee details screen. I’m trying to decide if I want to revert on my advice to switch which table that delimited list is in. I think it could go either way, but I’m trying to understand how you want your app to flow. If you have any screenshots or a loom video, that would help a lot. I guess I was imagining a multi-select choice component on the company screen, that would allow you to select from the entire list of employees, but I may need to know more before I can give adequate advice. I mean, there are a thousand ways to skin a cat, so anything is possible, but it all depends on what you want in the end.
I think how you answer the above questions would determine how this works, but ultimately, it sounds like you are trying to compare the user profile company directly to the relation? First of all, a relation is a connection to an entire row or set of rows. A relation does not return a single column, even though it may appear that way. If you are looking for a single value from a single relation or an array of multiple values from a multiple relation, then you would use a Lookup column in conjunction with that relation. In your case however, you could use a Joined List column against that relation. A Joined List column is like a Lookup column. It returns values from a specific column in the relation, but instead of returning an array, it returns a delimited text string. With that you could filter your list by comparing where the user profile company ‘is included in’ the joined list, or the joined list ‘includes’ the user profile company. Again, I’m not sure if this is the best route, depending on how you have your app flow set up and how you want it to work. Screenshots and/or video will help me a lot to visualize what you have and what you want.
Yes. RowID is good practice because that allows you to alter details about the employee, such as name, email, etc. and it won’t break the relation. RowID’s will never change, but other details about an employee could change. You want to ensure that you are using a value, such as RowID, that will never change.
So, change history can be as simple or as complicated as you want to make it. There’s a lot to consider as far as row counts and update usage. Personally, in my app, I don’t keep an edit log of any changes. I think it would add a lot of overhead. But, you could probably do something like using custom actions that would not only update a row, but also add the same data to a log table. Or, you can use special value components in forms, which can log the date/time and user email of the last change to a row. I guess it all depends on what kind of history you want to keep and how extensive you want it to be. I guess it would be easier to answer if you had a pretty good idea of what you want for history or change logs.
As far as backups of data, you have a couple of options. One thing that Glide provides is an Export function. This will allow you to export your data as a CSV file. It’s not automated, so you would have to run that export any time you wanted a backup of date. For my primary app, I have all of my data in a google sheet. One advantage to that is that I was able to create a google script that runs weekly and will automatically create a duplicate backup of my data with a timestamp attached to the file name.
You can see the script here: Backup My Data In My Spreadsheet - #2 by Jeff_Hager
In my google drive, I have a folder with copies of my database generated every week, going back 3 years. If I ever need to restore any data that was lost, I have a reasonable chance of restoring it between these backup copies and google’s own revision history.
I think another alternative would be to use the Glide API to retrieve your data, but I think you may need an Enterprise subscription to get full API access to do a mass Get of all data.
This comes up every once in awhile. As long as your Airtable or Google Sheet aren’t performing their own calculations and you keep all computed logic in glide, then I really don’t think there is any sort of performance difference between Glide Tables and any other external data source. If you use Google Sheets for example, Glide still keeps a copy of that data on their servers. Glide acts as a middle man between Google and the end user. Your app will never know the existence of any third party database. The app only syncs data with glide, and glide does the syncing with the google sheet. So yes, glide does keep a local copy.
I don’t have any experience with Airtable myself. From what I’ve read, I think it has it’s own quirks. I think this is especially the case if you are using some airtable functionality that is exclusive to airtable. To some degree, Glide can interpret it, but I think people have had mixed results with linked tables for example. I think if you used airtable purely as a database source, and didn’t use the eye candy that’s exclusive to airtable, then it would work just as well as google sheets, glide tables, and excel. One thing to note about airtable…I think the current connection that glide has to airtable forces them to poll airtable regularly, instead of airtable sending updates to glide. Glide has mentioned that someday, they will get access to a better airtable API, but I’m not sure when. In my opinion, I would at least avoid Airtable if you can. If you already have data in airtable, are comfortable with it, and it works with glide how you want, then go for it, but I would be hesitant based on what I’ve read.
Short answer, no. But, this isn’t necessarily the standard way to create a relation. Glide can’t create a many to many or many to one relation using a comma delimited list. Glide sees it as a single text string and tries to find a literal match…commas and all. That’s why you need to convert it into an array with a Split Text column. However, you could have cases where you have a single value that can be used to create a relation. You also could have an existing array, such as the array form of a Lookup column, an array from a Make Array column, an array generated from sequentially numbering columns in a google sheet, or any other way you end up with an array. Airtable probably performs some magic on their end to convert a comma delimited list into an array…or maybe they don’t even store it as a comma delimited list. Point being, you don’t have to use the text field>split by text>relation method every time you need to create a relation. You only do that if you have a text field with multiple values in a single value text delimited form.