I find that the "End Users" vs standard user management feature is not well-developed. In my opinion, being an end-user should be decided by the manager who shares limited access rights, and not by a system. As it stands, it is almost impossible to use this feature, thus requiring higher costs.
Hi,
I agree with you.
I'm on the Team plan and the end-user feature (at 5$ a month) is not a thing.
I've been said by the Support that the end-user feature is not available for Team, but for Business and Entreprise.
I'm not sure what is true and what's not.
Yes, It indeed have end-user in both Team and Business plan, but in team you can't set the access right to it. This means end-user in team still has access to edit the apps.
If you don't use that end-user to edit the app in specified charge period, it will regards as end-user, otherwise standard user. If you use many end-users to edit your apps. these users will charge as standard users.
I also have feedback my confusion about these too before.
Totally agree, I just switched to team plan (i was using the free plan before for my mockup). Honestly it does not make any sens to not be able to setup end-user as use only profil...
Hi everyone! Thank you for taking the time to chime in, and I definitely understand the confusion. Our approach to pricing is decoupled from access controls and is based on users' usage. In other words, "standard users" and "end users" are pricing and billing concepts, rather than permissions concepts.
So, for example, a user who has editor permissions in Retool, but didn't build in Retool in a given month, would only be charged as an "end user" in that month. You can read more about our approach to billing in our billing docs.
On the Business and Enterprise plans, customers can use permission groups to control who has the ability to edit Retool apps and workflows. You can learn more about permission groups in our permission docs.
We do track every point of feedback, so please feel free to continue sharing your thoughts and questions!
Hello,
I'm well-versed in Retool, but I had my uncertainties. Now that I'm on the Business plan, I've begun experimenting with permissions. I find the terminology a bit perplexing.
I believe it would be beneficial to have a distinct End-user group (without viewing access to Workflows, Resources, and Database) and a separate Viewer group (with viewing rights). Naturally, we would also have the Admin and Editor roles.
I grasp the idea behind the Viewer role—it's more cost-effective for those not involved in development edits. However, the primary notion showcased in the Portal is the End-user without viewing permissions. This isn't available by default.
I suggest adjusting the pricing structure accordingly. For instance, under the Business plan:
- Admin/Editor: $50/month
- Viewer: $15/month
- End-user: $5/month
At $15/month per end-user (taking the pharmacist in the given example), it becomes challenging to establish a feasible business model for the suggested product. This leaves little to no profit margin for startups. Given that startups appear to be a key demographic for Retool, this is concerning.
1 Like
Thank you - I’ve shared your feedback with our team working on pricing. As a quick note, just in case it’s helpful, have you looked into our Startup credits? We actually created this program to address your last point!
Hi @victoria, we're facing a similar issue here.
I am struggling to understand how to set up an end user of one of our apps without granting them too many permissions. I have started off setting them up only with "Use" permission to the app. When they tried accessing the app, we could then see that data couldn't be fetched for the app because the user didn't have the appropriate Resource permissions. Now we're unsure about what the "Resource" "Use" level of permission entails, as we don't want the user to freely write their own queries against e.g. our database - we essentially are looking for a level of permissions where the user can access the app and can view the data that the app fetches using the preconfigured queries + transformers.
Hey @jangerrit! The base level of "Use" for Resources does exactly what you are looking for. Allows the user to access the app and can view the data that the app fetches using the preconfigured queries + transformers. Without edit access to an app, the user would not be able to write any queries against that resource. Let me know if you have any other questions 
Hey @joeBumbaca and @victoria ,
This looks like a spicy topic!
I just wanna bump this one too as I just ran into it and found it super frustrating.
I’d recommend you relabel the “End User” in the Team plan description to something like “Didn’t really use the app.”
The description as-is gave me the impression I could actually have limited End Users with this plan.
Take it or leave it, just one of those experiences that puts a bad taste in your mouth.
-Cam
1 Like
Hey @Cam_Szarapka, really appreciate the feedback. Sorry this left a bad taste in your mouth. I've passed it along your sentiments with the pricing team, and will update this topic if anything changes.
I want to bump this too, I'm a startup looking at making an internal admin board to moderate/manage my mobile app DB easily.
Say I make an admin panel and get some employees/contractors to moderate flagged user-generated posts in my app.
Are you saying on teams any End user I add.. I don't want them to edit my tool or make dev new ones, instead of those guys just using the app I created (use case update post to 'hidden'/'delete') and see the data I as retool developer decided to show in my app I invited them too (in this example flagged posts for moderation)...
Retool allows these end users to edit the app, write a new script (as my DB is connected) and access all and any data, including financial and private data of my customers (basically anything in that connected DB)? As well as update it at will...
That is wild and a massive security flaw no matter how you look at it...
"End user" - as the name implies, should be able to view and use the end version of the created app. Eg if a field has a drop down to edit, they can do that and that and only that.
Your version of 'end user' is at best very misleading...and can have pretty serious security consequences for your unsuspecting customers, in a day where personal data laws and company trust are essential. Wild to offer this pricing in teams where the account holder has zero permission access control.
Imagine this conversation with your customers based on your pricing structure?
"guys we are making a new internal tool"
"great, who are the end users?"
"you mean the people we will allow to freely edit the tool we make at will, write to our connected DBs unchecked but choose not to for a set amount of days?"
Seriously guys?
I can see why it is leaving a bad taste in your customers' mouths, anyway my 2 cents..
"Hey, my end user, here is an internal tool we made, as a end user... please don't edit it, look at anything your not supposed to (really easy to do and I can't stop you) and replace every document in my db with profanity... please (I really can't stop you unless I pay x5 the price of a license) ... crazy who thought that pricing was a good idea.
My suggestion, if you base your invoicing and pricing off someone being a user/end user, you should at minimum have a way of controlling that permission for the person paying the bill. And that is a pretty minimum requirement (I would assume even legally).
Or better, to build trust with your user base, you make the "end user", what it should be, an end-user of the retool you created.
3 Likes
I just finished up making a simple app for desktop, just to discover that my end-users can edit everything.
For now I only need 2 things:
- an account to edit and create apps
- accounts that use it.
I went from free to team just to be able to do this. Now I see I need a business subscription just to be able to make an app not editable.
Basically, this is an excel app all over.
1 Like