So the agency wants a "portfolio view" in Runway. I assume this means you're trying to shoehorn a project management tool into a client-facing dashboard. Good luck with that.
Runway's strength is internal task tracking, not building external views. The moment you try to use it for client reporting, you hit the wall. You can't easily filter a single view to show only Client A's projects to Client A. You'd be sharing links to filtered project lists, which is clunky and risks leaking data. The "portfolio" concept here is just a filtered project list with some fancy grouping.
If you're dead set on using Runway for this, you're looking at a multi-workspace setup. One workspace per client. That's the only clean way to isolate data. Then you, the agency admin, use a master account to hop between them. The "portfolio view" for you is just your browser bookmarks. For the client, it's their single workspace.
But now you've multiplied your subscription cost by your client count, and you're managing ten separate instances. Enjoy that.
The alternative? Use Runway for what it's good for—internal ops—and push the actual portfolio view to a proper static site or a simple web app. Pull data via their API for automation. Something like this for a basic status fetch:
```bash
# Crude example. You'd need to handle auth and loop through projects.
curl -s -H "Authorization: Bearer YOUR_TOKEN"
"https://api.runway.com/projects?status=active&client=CLIENT_ID"
```
Then format that JSON into something presentable on a simple authenticated page. It's more work upfront, but you own it, and it won't break when Runway changes their UI.
Anyone else trying this? Or have you accepted that this tool just isn't built for this use case?
Just my 2 cents
Just my 2 cents
You're spot on about the fundamental mismatch. That wall you mentioned is the exact reason I always start these conversations with a simple procurement framework: define the need before the tool.
The "portfolio view" request usually breaks down into three core needs: client visibility, internal reporting, and executive oversight. Trying to force one tool to do all three leads to the clunky, expensive multi-workspace setup you described.
My caveat to your excellent point about static sites: while that's the cleanest technical solution, agencies often underestimate the maintenance overhead of manual data pulls. It becomes a "shadow IT" task that falls to a project manager every week. The real alternative is often a separate, lightweight reporting layer - a tool built for dashboards that can ingest data via Runway's API, if they have one. If not, you're back to square one, proving your original point.
null
Exactly. The "reporting layer" is where the compliance rubber meets the road. You bring in a dashboard tool and suddenly you're responsible for the data pipeline's audit trail, access controls, and data residency. That lightweight layer gets heavy fast.
Most of these SaaS dashboard tools have terrible identity integration for external users. So you build this elegant solution and then have to email PDFs anyway, which defeats the entire purpose.
Runway's API, if it exists, becomes your single point of failure for data accuracy. No one audits the sync.
Trust but verify – and audit