I am working on a challenging user management UI. The manage permissions screen here needs to do all of the following:

a. Allow the user to search for organizations and select any # of organizations

b. Allow the user to search for users and select any # of users

c. Bring up all orgs associated with the selected users

d. Bring up all users associated with selected orgs

e. Allow users to manage permissions listed below in the table

I am worried that c and d could easily create a snowball effect if they start populating all orgs associated with these users and one of those newly populated users has 10 more orgs ... and so on and so forth.

Are there any existing patterns or recommendations on how to handle this kind of situation?

Screen design

Update: Would it be a bad idea to add checkboxes that say 'show associated orgs' and 'show associated users' to prevent automatic population of associations? enter image description here

  • Does the user need to be able to compare orgs associated with different users? In other words, do you need to have more than one users associated orgs visible at any time? Sep 8 '16 at 7:36
  • As an addition to the previous comment, I'd like to know why you have to compare a lot of users with a lot of organisations? The more common way is to either work with a single user and her associated organisations, or work with one organisation and it's users. Why the need of this many-to-many thing? Sep 8 '16 at 14:09
  • @Bennani It was getting tedious to switch between the two modes (one user & many orgs vs one org & many users). It came down as a requirement as the super-users were getting frustrated with switching between the two modes and they usually only have permissions on 3 or 4 organizations and less than 20 users total I thought it wouldn't be too much of a problem to allow them to free select. Yes, the super users are usually dealing with a small amount of users and orgs and they want to be able to compare all the permissions across their organizations at once Sep 8 '16 at 14:17
  • 1
    I have the same screen in my project. I'm curious to know the best answer too. Sep 14 '16 at 20:25
  • I ended up creating radio buttons that only allow the user to select one or the other preventing this snowball effect Sep 15 '16 at 21:58

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:

  1. What is the main use case for this scenario (who will actually see this page and make those decisions?
  2. 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)
  3. 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:

  1. 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.
  2. 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.


For the problem of C and D, you can use a search bar (with autocomplete). So the user must use the search bar.

This is good for 2 reasons: 1.- help the user understand what is doing, 2.- Help the user to navigate in the complexity.

Here a example: https://jqueryui.com/autocomplete/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.