Permissions on Startup Plan - can we manage permissions by app?


We're looking to "retool" our Airtable bases as a set of apps so that we can integrate data that we had to separate because of Airtable's lack of permissions, and to build more useful forms for editing our data.

Retool looks phenomenal, but I was stopped cold by the leap from $10/mo to $50/mo for permissions.

I need to build apps for our staff to manage projects and their time without accessing financial data. Can I build separate apps for regular employees and business users to see and edit different columns of data without having to buy a "Pro" plan? ie one app might have hourly rates and the other app would not include it. Can we manage permissions by app in the Startup Plan?

Hi @nc3d!

You can certainly build out separate, but similar apps on any plan. You can easily build an app, then duplicate it with one button click (though, from that point on, the apps would be entirely independent so any future changes would not transfer over).

Permissions can only be controlled on the Pro Plan. On the Pro plan you do get the public apps feature, which lets you build apps that are publicly available to anyone with the URL. Whoever uses that link won't need a Retool account, so you won't be charged for them. Since the app is public though, you wouldn't want it to have any user-specific information or dangerous functionality (I.E. deleting rows in a database).

How many org members do you plan on having? I'd be happy to help you decide on a plan that makes the most sense for you and your team 😊

Hi Victoria,

I just need to create apps for my staff that do not include the financial data that is also in our source Airtable base. Couldn't we simply restrict who can make apps (still a permission) and omit certain fields from our apps using a lower-cost plan?

Thanks for your help!


Hi Donald!

Unfortunately, the Business Plan (formerly known as the Pro Plan) is the only app with permissions controls.

You *can* use a little workaround with the current_user object (which has the current, logged in user's email and name) to hide certain components based on the logged in user.