We recently published blogs on how to use custom roles to help implement an open data strategy in your organization and another on how to use them to provide access to Activity Dashboard for ArcGIS. In this post we’ll talk more broadly about how administrators can implement custom roles and present an example of how roles were implemented in a real ArcGIS Online organization.
Core Roles and Custom Roles
A role is simply a collection of privileges that can be assigned to a group of members to control what actions they can perform and what services they can use. There are three core roles that are pre-configured for all organizations to use: User, Publisher, andAdministrator. These core roles are a good start for providing members with what they need to use the various features and services ArcGIS Online offers.
The downside of sticking with just the core roles is that administrators must place each member into one of these three pre-configured buckets, and this may not fit your requirements from a management or security perspective. For example, you might want all members to participate in open data activities (not just Administrators), and you might need to limit the use of GeoEnrichment to just a few people (not all Publishers). Designing and configuring your own custom roles will help you impose or relax permissions as required to fit the needs of your organization.
Privileges
There are two main categories of privileges that can be assigned to each custom role.
- General privileges relate to members creating, using, and sharing their own items and groups.
- Administrative privileges enable members to view and manage all users’ groups and items.
There is also a set of reserved privileges. Reserved privileges are only available to members in the core Administrator role and cannot be assigned to any custom roles. Examples of reserved privileges include configuring custom roles, removing other administrator accounts, and viewing and editing the organization’s configuration settings.
In creating a custom role you simply review the list of general and administrative privileges and enable the ones required by a collection of members. To get started, you can use one of the available custom role templates such as Analyst, Author, or Student. For example, here are the privileges assigned to the Analyst Template role.
Benefits of Using Custom Roles
ArcGIS Online provide incredible value for its cost, and most organizations include sufficient credits to cover anticipated annual usage. But as an administrator it’s your job to manage your organization, so you’ll want to implement sensible policies and controls that minimize wasteful or mistaken usage of ArcGIS Online and also provide security.
In this effort to manage your organization it is likely that you will outgrow the core roles. You’ll notice yourself being conflicted as to which role to place a new member in. When this occurs you should configure custom roles so you can assign members only the privileges needed for to perform their job function.
There are several areas where administrators will see benefits from using custom roles:
- Improve security in your organization by allowing actions based on role (i.e., job function); for example, only authorized members should be able to share maps with the public.
- Reduce unwanted/mistaken credit usage by limiting access to credit-using functionality such as GeoEnrichment and geocoding.
- Simplify management since you can make a change to many members’ privileges with a single action.
Strategy for implementation
The recommended way to implement custom roles is to start by considering the creation of a role for each job title in your agency, department, or company. In doing so you mimic your organizational structure inside ArcGIS Online. From there you can look for opportunities to consolidate or break out roles as needed based on how people in different job functions use ArcGIS Online.
Example: Esri’s National Government Team
After the custom roles feature was enhanced with additional privileges in July, I took a look at our National Government Sales Team and thought about how custom roles would look for my organization of 220 members. Job titles on our sales team include a Director, Sales Industry Managers, Sales Team Leads, Account Executives, and Account Managers, and in technical positions we have Solution Engineers and Solution Architects.
We also work with Geospatial Analysts and Project Managers in Esri’s Professional Services division, Training Speciaists in the Education Services division, and Product Engineers and Developers from the core software development team.
One possible solution would have been to create a role for every type of job title; however, this is typically an overly complex solution that leaves you with additional administrative overhead. Instead, I decided to consolidate and expand roles beyond just job titles. Here’s how I did it:
- Combined Solution Engineers and Architects into a single role. These technical staff utilize ArcGIS Online in a similar way and can share the same set of privileges.
- Created three roles with gradually expanding permissions: Sales Team Viewer, Sales Team Publisher, and Sales Team Power User. There is a wide range of job responsibilities and experience with ArcGIS Online among the other members of our team. Some are very comfortable publishing services and running analysis tools while others mostly create maps using existing layers and rely on Solution Engineers to help with more advanced tasks.
This table summarizes the roles, job function, and privileges for each custom role on the sales team.
Earlier, I mentioned that the National Government Sales team also works with other teams within Esri. For these “external collaborators” I created several additional roles that have similar privileges to their Sales Team counterparts. Having these roles helps administrators keep track of how many external collaborators have been invited into our organization and also enables us to change privileges for sales team and external staff independently, if needed.
Finally, I created an Activity Viewer role to provide access to Activity Dashboard for our Sales Director and other staff who required visibility into how we use our ArcGIS Online organization (see this blog post for more information about how to do this).
- Activity Viewer – Senior management staff and others who only require visibility into the usage of our organization via Activity Dashboard.
- Map Viewer – Esri employees outside our sales team who need to view maps shared with our org
- Power User – Esri employees outside our sales team who need “power user” level privileges
- Publisher (core) – Esri employees outside the National Government sales team who need “publisher” level privileges
- User (core) – This role will be phased out over time as all members will be transitioned to other roles.
This is what our organization looks like after implementing these roles:
Commenting is not enabled for this article.