It depends on the estimated number of users you'd be handling, but from the look of it you're talking about hundreds at the least, with tens to hundreds of clients as well.
In that case, you've got a lot of selections to consider: users, user permissions, and permissions per organization.
The good news is it's likely that most users aren't on multiple organizations, so you don't have to worry too much about overflow. The bad news is that's three main things to display when a table doesn't really accommodate that third dimension.
I think to make the best decision here you need to answer a few questions that we don't have answers for in the description:
- What is the main use case for this scenario (who will actually see this page and make those decisions?
- Does the main use case (or any secondary use cases) require, or should they even support, making multiple permission changes across multiple clients simultaneously? (This could lead to security risks, and also clients may not like such a system, assuming they know about it)
- On average how many users have access to how many different organizations? (the number, as well as the edge cases and expectations on changes in the future, will help determine what the best layout for the page is for navigation and ease-of-use.)
The other good news is that no matter what the answers for these questions are, to make it as simple as possible you've really got two main options:
- Only allow one user/organization change per page - This is the standard practice, especially with SaaS services where you might have some users with tens to hundreds of clients to access, and it works perfect for scalability. It means that no matter what the person making permission changes can only do it for one user or one organization at a time. The former would show all of the organizations that the user has access to and the permissions settings for each; the latter shows all of the users to one organization with the same permissions settings.
- Have a front-page that's more like a basic reports search system, where adding the required parameters delivers an ordered list, either per user or per organization, of the available users to assign permissions to - This is more cumbersome and frankly might not work well depending on the technology stack, especially when scaling. In theory you could come up with results in the thousands or tens of thousands, which would take a lot of time to load and would be cumbersome on both the servers and your own machine (after all your browser will have to retain everything on that list). Otherwise it would require pagination, which would be a challenge because you're then requiring (for best UX practices) to retain permissions data while moving between pages.
I have a similar issue right now with a new client, though their scale is much smaller, just 35 users with the expectation that in 3 years time we'll be looking at 200, across dozens to hundreds of clients. The last company I worked with used the first option I listed, mostly out of laziness when they developed it, but once the company scaled from 100 clients to 3000 clients it proved to be the right decision because of the scale, especially since it was for internal use only.