If I create an app in glide where companies can store their software projects requirements, have public email users sign up to access and update the app data for their company including adding new fields to the existing entities that I have created in the app, can Glide actually physically implement that scenario?
If you mean adding columns to your database, then I doubt that would work. If you store it in Google Sheets, there might be a way through an external service like Make to add the column, but you would still have to add a component for that new field in Glide yourself as the builder.
1 Like
ok Thanks. But is there any concept of a company/client specific column that eve I as the builder can add to my solution/app? So all public email login users of the app who are members of the specific company would be able to use/see the column and not other members of other companies signed up to my app?
You need to think about it more in terms of who has access to which rows instead of which columns.
You can control access to rows both securely (with Row Owners and Roles) or insecurely (with simple Filters).
You can allow individual users to store user specific data in a user specific column, but you cannot make a user specific column specific to a group of people. Itās individuals only.
You can control the visibility of a particular column for certain users, but it does not scale well, and would require app maintenance whenever you need to add new columns or change who has access. Also, visibility conditions do not provide data security.
You can easily control access to certain rows, but if you are going to attempt that with individual columns, then you are going to have an overcomplicated mess to deal with and maintain.
It may be worth rethinking your data structure to make it more efficient and scalable in the long run.
3 Likes
Thanks. So it seems that Glide simply cannot do my use caseā¦
Core product in Glide that I can then specialise/tailor with additional columns, per company/org that signs upā¦ but glide does have org usersā¦ but those org users have to use the same columns then?
I mean, thatās just not typical database design. Keep in mind that each new column in a table needs to have corresponding components, actions, and whatever else adjusted to deal with those new columns.
Not trying to tell you how to design your app, but just letting you know that the way you want to do it is not easily scalable. If it were me, I would maybe have a separate table with an ID column, a row owner column, a title column, and a value column. Then relate your normal table row to that new table. Itās essentially how user specific columns work, but this gives you a little bit more flexibility and each company can add as many related rows as they want.
3 Likes
Thanks. (Yes I was thinking of trying something along the lines you suggested there)ā¦
Could I actually/physically use Glide Templates?
(I really believe that with the right marketing for my āone stop boxā product management solution, I can attract A LOT of users to Glide)
So, the overall design pattern I am looking for is: -
CORE PRODUCT => SPECIALIZED PRODUCT PER ORG (customer company)
CORE PRODUCT = Template in Glide where only I control the tables, columns and associated core actions/functionality
SPECIALIZED PRODUCT = essentially a copy of the core product (which users donāt change) + any new fields and actions/functionality associated with new fields that they add.
Is that template restriction available in Glide? If not then thatās a big problem, because a customer could make a copy, make a mistake making an update to the copy of my ācoreā product, and then claim that the core product is faulty.
Templates are meant to be copied. There is currently no option to have a core template that feeds several child projects. You can share tables between different projects, but thatās about it. If you have separate projects, then you would need to maintain each project separately.
Your options are:
- Have one app that serves all of your customers.
- Create duplicates of your App that use the same core tables. (Still requires separate maintenance for each individual app and any computed columns)
- Create duplicates of your App, but with new copies of the data tables. (Still requires separate maintenance for each individual app, as well as separate maintenance for all data).
Then you have to factor in billing and usage limits. Are you hosting all of the Apps in your own account? Are you creating separate team folders to separate billing and usage for each customer? Are your customers creating their own Glide accounts and inviting you to their team to manage their copy of the App?
If you donāt share a template with others, then yes you are the only one that has control of it.
No, not possible to have a template like that.
If you control, manage, and host to the project yourself, then you are in full control of it.
If you are allowing a user to copy the template, and add it to their own Glide account, then itās out of your control at that point. The only thing that may protect you at that point is a written contract, NDA, and anything else to assure that they donāt muck around with the project.
If you are going for a SAAS model, I would 100% want a complete separation of data for security purposes, but thatās just me. With the way that Glide is currently designed, I think you are going to end up maintaining separate Apps at a minimum, and potentially separate databases, with the possible exception of some shared tables between apps projects.
2 Likes
Thanks again Jeff. Yes I am going for a SASS model, and I have a solution which should work on Glide as it is although itās not ideal. Described below in āCURRENT SOLUTIONā. But I really think Glide is missing a trick hereā¦
I think Glide could make the following changes in order to make the platform commercially viable for SASS product/solution providers and therefore exponentially grow its own customer base (alongside the current model of internal/org āpower usersā who simply sign up with Glide āas isā and develop their own solutions. These are two totally separate markets and Glide seems to be shunning the SASS market. Glide may be profitable now in the āinternalā market, but will that always be the case? Look how many competitors there are in this spaceā¦ airtable etc etc. Why not diversify and take a chunk of the SASS market to protect the business longer term?..
SASS MODEL:-
[1] Create an option for Glide Templates to be āprotectedā (as described above in my previous posts above). (These could be marketed or described as SASS templates that developers/SASS solution providers etc could use/create their SASS product. Make it a different templates marketplace maybe.)
[2] Enable a subscription payments to these SASS templates instead of the one off payments Glide currently has. (Without subscriptions to the SASS product it just wouldnāt be commercially viable. Maybe Glide could offer a subscription sharing modelā¦not sure, but something that would bring in the $ for Glide also of course)
[3] The SASS providers then obviously do their own sales and marketing on their SASS product (the Glide SASS template) and sign up users to both their SASS template AND Glide at the same time. (That in itself is a good deal for Glide right? You gain a whole army of people/companies marketing the Glide platform for free) Signed up customers then have their own technical people (or power users) learn Glideās āeasy to useā platform in order to tailor/extend the SASS template functionality, but the core template is controlled by the SASS Provider only who evolves/develops their SASS template/product to provide more benefit/functionality to customers and therefore secure them as long term Glide customers
What I describe above is a standard SASS model that all the big players like Microsoft (Microsoft Dynamic CRM), Salesforce etc implement, so itās well known and tested in the market place.
Having worked professionally with both Microsoft Dynamics and Salesforce solutions myself I can tell you now that both of them are quite clunky and also expensive. Glide is a lot more nimble and easy to use/implement. If Glide implements something like the model above I am convinced that Glide could make a huge dent in Microsoft and Salesforce market share.
In the mean time I have to do something like the following:-
CURRENT SOLUTION:-
[1] When a customer signs up to my App they are registered is a customer and under the bonnet therefore have a company ID. When they get their users to signup up as āPublic email usersā they are added to their company.
[2] All relations in my solution will be implemented through RowIDās. The upper level tables that effectively control access the the related lower level tables (one to many etc) will only be accessible through the related company ID that the logged in user belongs to so signed in users will only ever see their companiesā data. (Could maybe use row owner array columns for that too).
[3] To provide at least some āspecializationā I can implement a Reference data structure for each table where they can effectively tag values to each table if they want to. Itās a bit naff, but it might actually suffice.
[4] As Glide is now not supporting/implementing payments out of the box, I would need to integrate some kind of subscription payments to my app.
Is there a best practice solution within Glide for point [4] above?
See below:
btw, the correct acronym is SaaS (Software as a Service) 
2 Likes
Regarding your second pointā¦If you are relying on the relations as your only point of data security, then you are putting user data at risk. Relations are computed columns. Computed columns are computed on the end userās device. What that means is that ALL data needs to be sent to the userās device to determine which rows match a relation. Someone with enough knowledge can snoop that data and see data from other customers. Only Row Owners will securely prevent users from having access to data that they do not own. Row Owners only allow owned data to be sent to the end user device.
Glide is different because a lot of backend processing, that would normally happen on a server, is actually offloaded to the end userās device. Thatās why Glide is a lot cheaper to run compared to the big CRM players. The big CRMās are not only storing data, but actually doing a lot of backend processing with that data and securely serving it to end users as needed. Thatās a bit different compared to how Glide works, where much of the data is delivered to the user before itās processed.
Thatās why I think these new integrations have a multi-update usage cost. Now that weāre moving some of the processing back to the Glide servers, it puts a higher load on the server. But the advantage is that it provides a much more secure integration to these third party services, because API keys and authentication headers can be properly hidden from the end user.
3 Likes
ok ā¦ I seeā¦ I have to say I am very surprised at that. Glide may work differently, but I canāt see any reason, no matter what architecture is being used, to send an entire table to a users device and then do the filtering. That is hugely inefficient not to mention insecure as you point out. So if I sign up 50 companies but employ filtering on a table on the company ID, then the entire table for those 50 companies is still sent to a users device first and then filtered? In that case surely Big Tables wonāt really work in Glide as the amount of data being sent to a users device is so huge?
So I would need to employ row owner array columns with every signed up user as row owners (per companyā¦ for the ācompany rowsā, or rows created by users in that company) on each table in my solution?
I would argue the inefficiency to some degree. Glide is cheap because they are offloading the processing to the end users, so they donāt need massive server farms that cost millions to run. At the same time the user experience is much more responsive because you are not waiting for data to travel back and forth between the server and the user. You talk about how CRMās are much more expensiveā¦there is a reason for that, because they handle a lot more server-side processing.
Itās only insecure if you as the developer allow it to be insecure. If you follow Glideās proper security protocols, understand how it all works, and only allow owned data to be sent to a userās device, then itās just as secure as anything else. I would think that many services cache data on the the end userās device to help speed up the UX. I recommend spending some time understanding Glide Security.
https://www.glideapps.com/docs/reference/security-and-user-data
Only if you allow it with poor data managment. This sounds like a good use case for user Role functionality, and then you can apply Row Owners to those user Roles. That will secure the data so each company user can only access data for the company they have been assigned through the Role functionality.
You can only create a row owner array if the array is formulated via the external data source. So for example, in Google Sheets, you can sequentially number columns, which will translate to an array column in glide. Possibly Airtable has itās own way to create an array column, but I donāt use it. If you are using Glide tables, or you are attempting to create an array within the data editor, then it will not allow you to assign Row Owners to that array column for the exact reason that I explained above. Computed columns are computed on the userās devices, so it would violate row owner security to send all data to the user before building the array, and before determining row owners,
If you are unable to create a server-side array via an external data source, then your other options are to create multiple Row Owner columns and assign each individual user to one of those arrays, or you can utilize Role functionality and give multiple users a Role (ie Company ID), and grant Row Owner access to the Company ID.
4 Likes
Thanks again Jeff!! So it looks very much like, for this multi-company app use case on Glide, multi-Role Row Owner rows are the way to go. The first of those roles would be the actual Company the user has signed up to (that ensures signed in users can only ever access their own companies data), and then filtering can be used in the App for the āBusiness Rolesā whatever they are (Admin, Editor etc).
But, please please tell me the below are not Gotchyaās!
PRIVATE PLAN?
Just looking at the documentation you linked to above (thanks) it talks about Roles only being available on the āprivate planā, but on the Glide pricing page there is nothing about a āprivate planā?
It says āIf your app is on a Private Plan, you can assign roles to the users in your User Profiles table. You can then use these roles with Row Owner columns to make certain records only accessible to certain users.ā
Is this private plan thing an old feature of Glide because itās not mentioned in the row owner video or Glide doc page eitherā¦ The video just says if my app has āPublic by emailā user sign in then they can have Roles assigned.
PRICING
On Glides pricing Page, Public users are:-
ā¦ and Private Users are:-
Is that highlighted sentence above correct? So, if Iām on the Starter Plan, my āPublic by emailā users are classed as Private users now if Iām assigning Roles to them? (ā¦and I go from 100 users down to 10). If so why? What difference does it make to my PUBLIC user if I am assigning Roles in order to control access to data withing the PUBLIC app? They are not private users signing into a private app are they.
CHANGING ROLES?
Iām hoping this is also not another āGotchyaā The Roles doc page it says the following:-
āChanging Roles
At the moment, you cannot change somebodyās role via the app. A role can only be changed via the sheet or Data Editor. If you show the Roles column in the app somewhere, users will be able to change the value - but this will not affect the backend and you will see the value change back.ā
So itās not possible to have an āAdminā User (or some kind of Super User) per company who can change a users role?
The doc is a bit out of date here. Roles are available on any plan (even a free plan), but making use of them does impact your Private user count.
Yes, that is correct. Users with Roles assigned will count as Private users, even if your App is Public.
I donāt know exactly why, but I guess that itās considered that Roles is a feature that creates value, and so it should be paid for.
Also correct. A user can assign a role when creating a user (only roles that the creating user has), but roles cannot be changed via the user interface. To be able to use the App to change the role of a user, you either need to do it directly via the data editor, or use an integration tool such as Make. ie. Send webhook to Make and have it effect the change via an API call back to Glide.
3 Likes
Thanks.
ā¦ this is a real ābum dealāā¦ enough of a bum deal to now make me start considering abandoning Glide for my use case
hmmmā¦ thanks, but once again, Iām having to jump through hoops here in order to actually use Glide. I donāt think Glide has really thought this through properly.
I wonāt agree or disagree, but letās take the fact that you are paying for a Starter plan and want to build a SAAS at $25 per month. Basically a for profit model where the expense to you is extremely low, but Glide still has to pay for hosting and bandwidth. If you are able to become successful and have thousands/millions of customers/users while still only paying $25 to Glide, then who is making money in the deal? Your model may end up costing Glide thousands per month in hosting and bandwidth fees, but they only make $25 off of you. I think thatās the challenge for Glide. They want to charge based on āValueā. If you can save or make tens or hundreds of thousands of dollars per year with a Glide App, then it provides much more āValueā than it would if someone made a similar app for personal or hobby use. Thatās where these user and usage limits come into play. Itās deliberate in design by Glide as a way to gauge a userās āValueā of there app. If you need more users, more rows, more data manipulation, and more storage, then the App has more āValueā, and in most cases, more value means more profit.
Glideās view is that if you are running a business, and the features that you require to effectively run that business are important to you, then you should be at the Business or Enterprise level and paying for those added benefits at those higher levels. Imagine if Tesco was using a Glide app to save 500,000 Pounds every year. Should they pay the same $25 that Joe down the street is paying for an app to assign chores to his children, or does the Tesco app have more value and they should pay more? Something like that is really hard for a Glide to gauge without knowing what each App does, or what itās used for. Thatās where these limits come in as a way determine an Apps value based on the limits imposed.
From the sounds of it, you would probably prefer a model where there is more profit value provided to Glide, but Glide just isnāt really designed for a SAAS model at this time. Iām not here to discourage you, but just want you to be aware of Glideās position, the current limits, and the reasons for those limits. Glideās focus is on those dark internal company apps that mostly service those within a company. While you can technically create public facing apps that have thousands or millions of users, itās not Glideās goal or focus.
I wonāt say that I always agree with Glideās decisions on everything. They frustrate me too sometimes and I could probably go off on how these superficially imposed restrictions actually make things much more complicated than they need to be. I could also go off on things that have been broken or poorly designed for years while being completely ignored in favor of new features. But at the end of the day, I still respect Glideās business decisions. They are here to make money and they know what their financial standings are at the end of the day. I donāt because Iām not their accountant, so Iām in no position to judge their decisions, because at most, I would be speculating.
4 Likes
Well it would still be Glide because the data/update limits would kick in dictating the cost to me per month
I still think there is a detrimental āzoneā in the pricing model for āsolopreneursā trying a validate a solution. We are not some multi-billion corporate like Tesco, or even an entrepreneur backed by venture capital. I myself will have to pay for sales and marketing out of my own pocket in order to get this thing off the ground, and ascend the data usage limits in Glide in order to generate future revenue for Glide. Thatās actually a pretty cute deal for Glide too when you think about it.
Glideās pricing structure has āpublic users (email login)ā at 10x āpublic users (email login) ā¦but using Rolesā. I donāt believe there is any discernible difference between these two groups of users in terms of costs to Glide. The pain zone would be from the 11th user up to about the 20th or 30th user signed up to the app (depending on subscription costs charged for the app).
I get itā¦and we could go on and on forever discussing how Glide should or shouldnāt being doing business. Iām only sharing my impressioned view of Glideās business plan based on views that they have expressed in the past. I myself donāt work for Glide, and I donāt get any kickback for donating my personal time in the forum. The best I can do is tell you how everything works as of today, how to make things work efficiently, and what are the best practices to manage data and keep it secure. I can tell you if I think something is a good idea, or if itās not going to work or scale very well. Iām a programmer/analyst by trade, so I only work with facts and the mechanics of things. I donāt dwell long on wishlist items or theoretical what-ifās. I deal with whatās in front of me now, and decide if itās going to work for me or if I need to come up with a different plan and move on.
Iām not trying to be rude, but I can start to see that this conversation is beginning to go in circles and Iām not really the person that can help you out of it. This topic has been rehashed over-and-over, one way or another, over the past few years. My own use for Glide is for one Private app with a total of 2 users, and a handful of personal/sandbox apps just for myself. I make zero money using Glide, and zero money helping others use Glide. So, as far as scaling to a much larger user base or a SASS type modelā¦Iām probably not the best person to advise on the best ways to accomplish that.
Do I agree with everything Glide does? Of course notā¦and I think many would agree with me to some degree. But, until Glide lets me see their accounting worksheets and lets me analyze their profit to expense ratiosā¦I guess Iām in no position to speculate on what may or may not be the best business practices for the company. All I know is that they offer one hell of generous free plan, and I can only imagine the costs associated with supporting the countless thousands of free users.
Is your idea possible with Glide??? Maybeā¦or maybe in the future Glide with make it easier to do what you want. All I know is that as of today, your current explanation of your app flow is raising some red flags for me, regarding the long term scalability, viability, and security of your app. As of today, you can 100% obtain your goal by simply duplicating and maintaining separate apps and separate databases, but trying to build a SAAS model is a whole different ballgame when it comes to Glide.
I think what you need to do is assess what Glide offers, how each price plan fits into your end goal, and how the data model fits into your over plan. If necessary, you can contact Glide Sales and discuss with them what you want to do and what your current challenges are. Maybe they can offer something thatās workable for both you and them, but in the end, only you can decide if Glide is the best fit for you.
Business is hard. I have a lot of respect for those that choose to go the entrepreneur and startup route. A lot of risk and a lot of reward.
4 Likes