Hi All,
It was nice to see the retool portals and embed at the developer day. As a non-developer, or, one might say - a 'low-coder' - I understood most of it, but not all.......
So - I've been doing some digging around, as I try to get my head round this. And I wanted to ask a few questions.... as (obviously) there is very little by way of documentation on how I can actually create my first 'Portal' app.
-
Is there any fundamental change from Retool - or is this simply a branding exercise? I.e. given that the user pricing model changed recently, is it just my lack of understanding or has nothing actually changed in regards to how others out with my organisation (I.e. - end users) interact with my app?
-
Would I be correct in saying that, in essence, I can only create one portal - and then any control I want to apply to my customers /end users etc - I need to do via user /group permissions? I.e. If I have two clients, and I want clients to only see their data /apps specific to them - how might I do this in a Portal environment? is it possible to restrict data sets via user group?
Sorry if these are rudimentary questions, I have tried to find answers online - but there doesn't seem to be any fundamental change with regards to launching a portal (vs previous situation and the new billing model that was introduced in May) - but I'm sure I'm just missing something....
thanks, Neil
We are all still feeling this out, but here is what I believe to be correct right now.
-
Yes, the only thing that is really new in Portals is the Branding Section in settings. Everything works the same as it did last week. Portals is primarily a marketing repackaging, or maybe a new way of looking at things, for now but I believe that new market will trigger other changes going forward.
-
Yes, you control access to apps via user/group permissions. You can have more than one portal as the portal is sort of defined by the Workspace homepage in your Permission Group's Additional tab. Add a new group to assign other users to and you get a new portal. To control access to data, there are a couple of techniques. One is to have a where clause in every applicable query that filters by their own records. I use this technique myself. You do need a way to link the Retool account to their client_id. I have a write up on how I do that here: How to get retool user id? - #2 by bradlymathews. the other is to use Row Level Security in your database. That is more complicated, but more hands off once you get it set up, and you still need to link the client_id to the Retool account.
While I was writing this @antonybello posted some clarifications here: Introducing Retool Portals and Retool Embed - #8 by antonybello
1 Like
Hi @maillme!
You'd still be building your applications as you would be for internal use–– it's true that most of the net new customer-facing functionality you're seeing as part of this launch is on the Branding settings. I'm not sure if you're referring to these docs that walk through building a portal, but would love to understand what improvements we could make here (even if it's just adding more clarifying language)!
Ah looks like @bradlymathews beat me to your second question! 
Regarding security and making sure each user is able to see only their own data, we'd recommend leveraging Permission groups and referencing them in your applications (like so). At the data level, we've seen customers build in row-level security by using the permission group ID in queries as well.
1 Like
Thank you both - I appreciate your response.
@bradlymathews - I found a quick post from retool on the row level security, this seems like the most 'secure' - if indeed a little tricky (for a low coder) - but it's all looks to be quite exciting.
And yes, now i see the permissions can control a 'new' portal - simply create a group - only let that group access your app - and essentially, you have a 'new' portal.....
again, thanks both - already reading your linked posts,
Neil