It seems that in order for a user to be able to Invite / Disable other users, they must be a full Admin.
I want to allow Managers to Invite / Disable users without allowing granting them full access to the rest of Retool.
Is this possible?
It seems that in order for a user to be able to Invite / Disable other users, they must be a full Admin.
I want to allow Managers to Invite / Disable users without allowing granting them full access to the rest of Retool.
Is this possible?
Hey @bwdsl! This isn't currently possible, but I created a feature request for it and will keep you updated in this thread
Thank you for the request and for anyone reading, please feel free to add your +1s!
Thanks Victoria.
Is there any update on this? It is incredibly limiting for external users and portals.
Hi @kyleteal,
Apologies for the inconvenience. I just checked the ticket and it looks like this ticket was canceled ![]()
We did however just get a PM for the Governance team so this could be an issue for me and the team to bring up.
Can you go into more details on the use case you are looking to achieve and how you are using external users/portals?
The last note left on the ticket by once of the governance engineers was that:
"An additional permission for this would be nice, but I imagine many customers would be concerned because adding members means adding seats.
For larger customers, we have many ways to automate user-creation between our SCIM API, JIT, etc."
Thanks Jack, the goal would be to allow certain users to add seats without full admin, in our specific case that would be project managers adding their external project leads as external users to allow them to see their project dashboard. Don't necessarily want to give PMs full admin however.
+1
In our setup, weβve made developers admins because they need access to edit configurations, build applications, and manage technical aspects β which makes sense.
However, user management (like inviting users and assigning permissions) is typically handled by someone within each department. Ideally, these department-level users should manage access, but the only way to enable this currently is to make them admins β which weβve done out of necessity.
The issue is that admin rights grant far more access than needed (e.g., visibility into all apps, ability to edit any resource, run workflows), which isnβt appropriate for their role.
Thank you for the added details on the use case @kyleteal and @Mohsan_Elahi!
It looks like this ticket had been backlogged but I just re-opened it, added both your +1s and added in the additional use case context so the eng team can better understand how to improve out permission options and system ![]()