Introducing: Project*-Specific Permissions!

by Reid M. Porter

We’ve been working hard on a permissions overhaul that touches every page of the DevResults app. Now we’re ready to release project-specific permissions, providing you with a huge increase in the flexibility and specificity of user permissions.

Since the dawn of (DevResults) time, we’ve lauded the benefits of broad data access to our customers. When colleagues can look at each others’ work, even if it’s not strictly speaking “their” project, they can answer their questions faster and get the data they need easier. Some people worry about the risk that someone may inadvertently enter data or delete documents for the wrong project, but in practice those mistakes are rare and are almost always caught immediately after the fact or in data review.

Even so, there are lots of valid reasons to be more particular about permissions across projects:

  • Some projects may contain sensitive data or information about vulnerable people or partners.
  • Some projects may work in locations that shouldn’t be known to anyone who isn’t directly involved.
  • Some projects contain information about partners or other third parties that shouldn’t be broadly shared.
  • Some organizations have such scale or hierarchy that one-size-fits-all permissions leads to an overwhelming amount of stuff.

So how can we offer a solution that’s simple to use but allows you to specify different permissions for different projects for each user? Lucky for us, we already have a system for assigning individual users to projects for which they are responsible — the Staff Roles table!

The same table that already gives partner users access to a project can also be used to identify when people need particular permissions for a project they work on versus one they don’t.

We decided to use this concept of “assigned projects” and “unassigned projects” as a handy way to differentiate between “broad permissions” and “limited permissions” within user groups. Since the concept of a ‘project’ is central to our data model, it’s easy for DevResults to translate project assignments to relevant indicators, results frameworks, and partner organizations without a lot of clicking and decision-making.

And it looks a little something like this:

Note that any users in this example group can do just about everything for projects they’re assigned to, but can still see most information and content on all the other projects. They can still participate fully in project discussions (to ask questions, share insight, etc.) but can’t see documents or financial information, which is restricted to assigned users only.

After much experimentation, this seemed the simplest, most straightforward way to give our customers greater control over what their users can see and do in DevResults. Combined with unlimited, custom user groups and unlimited user accounts, site owners have more flexibility than ever in striking the right balance between complexity and security.

We’ve also included some helpful tools to make implied assignments a little more visible. Site owners will be able to see a new Applied Permissions table on each user’s profile page to show which projects, data tables, and indicators they have access to:

In addition, every user will see a tiny ‘A’ for assigned or ‘U’ for unassigned in the top right next to the bookmark star whenever looking at a project, data table, or indicator so they know unambiguously whether or not they’re assigned to something in particular:

But what if you like your permissions the way they are — one set for each user group, without having to worry about individual project assignments? Well, you can keep doing what you’re doing! There's no need to upgrade if you are happy with how things are configured currently.

You can read more about project-specific permissions in our Knowledge Base. If you want to upgrade to project-specific permissions, get in touch at help@devresults.com!

*You may have noticed we’ve started saying ‘project’ instead of ‘activity’. That’s right, our customers have voted with their pseudonyms — ‘project’ has beaten out ‘activity’ as the preferred term to describe individual units of work. We’re following suit — and we’re currently updating our Knowledge Base with this change.