I've seen a few questions in other threads about setting up client-facing views in Runway, specifically how to give external users access without handing them the keys to the whole database. It’s a common need, especially for agencies or anyone providing services with regular client updates.
I recently helped a member configure this for a project management setup, and I thought a consolidated walkthrough would be useful. The goal is to create a portal where a client can only see and interact with records related to them. Here’s the approach that worked, focusing on two main tools: Teams and Views.
First, create a dedicated Team for your client. Add the client's user to this Team. Then, for every base or table you need to share, set up a View. The crucial step is the View's "Share" settings: share it specifically with the client's Team, and set the permissions to "Can comment" or "Can edit" based on your needs. This automatically applies a filter. You'll need to define that filter so it only shows records where a field (like "Client Email" or "Client ID") matches the logged-in user's information. Using the `CurrentUserEmail()` function in a filter is often the cleanest way to tie a record to them.
Remember, this relies on the client having a registered Runway user account. For true "portal" access without individual logins, you'd need to explore public view sharing, but that offers far less control and no user-specific filtering. This method keeps everything contained within Runway's permissions system. Has anyone else set this up differently? I'm curious about alternative methods for handling multiple points of contact from the same client organization.
—Ethan (mod)
Keep it civil, keep it real
Yeah, the Team + View + Filter combo is the way to go. It's basically the only sane method for client portals right now.
One gotcha I've hit: the `CurrentUserEmail()` function is great until the client's user email changes. If you're using email as the filter anchor, you have to update the view filter manually. I've started using a static "Client Code" field instead, assigned to the team, and filter on that. It's one less moving part.
Run it yourself.
That's a really helpful walkthrough, thanks. Using `CurrentUserEmail()` in the view filter seems straightforward, but what happens when a client has multiple people from their company who need access? Do you create a separate team and view for each user, or is there a way to handle that as a group?
Great starting point! Your mention of using the filter to tie records to the client's user is key. I've used this method for client dashboards, and it works well for a single point of contact.
But it does get tricky with multiple client users, like user828 asked about. I've handled that by creating a "Client Account" record for the whole company, and linking all their people to it. Then, instead of filtering on `CurrentUserEmail()`, I filter the view to show records where the "Client Account" field matches a value I assign to their Team. That way, everyone in the client's team sees the same portal view, and I don't have to manage separate filters per person.
Happy testing!