I'm often asked what the best approaches are for working with permissions in AnthillPro. There's a lot going on with permissions and roles, so it's worth taking a look at where things are set and how they can be taken advantage of.

The Basics

First, off, let's look at the key locations where permissions are set. These are at the system level, the project level, the process (workflow) level and environment level. The system level permissions will dictate who can see what screens. We can set those aside for the moment.

In order to run a workflow in some environment, the user must have view permissions to the project, execute permissions on the workflow and read permissions on the environment in question.

A Scenario

To make this more concrete, we should examine a common scenario. Anyone working on Project A should be able to see the project. Developers should be able to build it. Lead developers should be able to deploy it to Dev Testing and a QA lead can deploy to the QA environment. A similar set of restrictions applies to Project B but different people work on that project

One approach here would be to create roles for "Project A Dev", "Project A Lead Dev", "Project A QA", etc. Similar roles would be created for the other projects in our organization. In a large installation, this will result in role explosion and individuals that work on many projects will have many very similar roles.

The better way

Usually, a better approach is to use roles that map more directly to where the permissions are set and cut across projects. So we might create roles called "Project A Person", "Project B Person", "Developer", "Lead Developer" and "QA".  We can give both Lead Developer and QA permission to the deployment workflow. Only Lead Developer would have access to the Dev environment. Only QA would have access to the QA environment. To keep Project B people from interfering, only people with the Project A permissions can see Project A.

This approach works nicely because you need to have all three permissions to see the project, the workflow, and select the environment to run it in. No single role needs to have permission to all three places, a user just needs to have a collection of roles that do.