One of the most overlooked aspects of an ArcGIS Enterprise deployment is how user access is configured. Most organizations start with the default roles — Viewer, Data Editor, Publisher, Administrator — and never revisit them. The result is predictable: users with more access than they need, sensitive datasets exposed to the wrong teams, and no clear audit trail when something goes wrong.

Here is how to set up user roles and permissions in ArcGIS Enterprise the right way, based on what we have seen work across dozens of deployments.

Start with the Principle of Least Privilege

Every user should have the minimum level of access required to do their job. A field crew collecting data does not need publishing rights. A department head reviewing dashboards does not need edit access to the underlying feature layers. This is not about restricting your team — it is about protecting your data and reducing the blast radius when mistakes happen.

Move Beyond the Default Roles

The four built-in roles in ArcGIS Enterprise are a starting point, not a finish line. Since version 10.7, Esri has supported custom roles that let you define granular privilege sets tailored to your organization. For example, you might create a “Field Editor” role that can edit features and use collector apps but cannot publish new services or delete items. Or a “Department Viewer” role that can access specific group content but cannot share outside the organization.

Custom roles take 15 minutes to set up and save months of access-related headaches down the road.

Use Adaptive User Roles for Dynamic Access

A recent addition to ArcGIS Enterprise is the concept of adaptive user roles, which allow administrators to adjust user capabilities based on context — such as which groups they belong to or what project they are working on. This is particularly useful for organizations with contract staff, cross-departmental projects, or seasonal workforce changes where access needs shift frequently.

Rather than manually upgrading and downgrading individual users, adaptive roles let you define access patterns once and apply them consistently.

Organize Content with Groups and Categories

Roles control what users can do. Groups control what they can see. Use Portal groups to segment content by department, project, or sensitivity level. Combine groups with shared update capabilities so designated team members can collaboratively edit group content without needing broader organizational permissions.

Set groups to “Organization only” or “Members only” visibility to prevent accidental sharing. Use categories and content status tags to keep your Portal organized as it scales.

Integrate with Your Identity Provider

If your organization uses Active Directory, LDAP, or a SAML identity provider, configure enterprise logins so that user provisioning and group membership are managed from a single source of truth. When a user is deactivated in your directory, their Portal access should follow automatically. Manual user management does not scale and creates security gaps.

Audit Regularly

ArcGIS Enterprise provides administrator reports that show user activity, content ownership, credit consumption, and login history. Review these quarterly at minimum. Look for inactive accounts that should be disabled, users with elevated roles who no longer need them, and orphaned content from departed staff.

The Portal Administrator Directory (sharing/rest/portals/self) also gives you programmatic access to user and role information for more detailed auditing.

The Bottom Line

Getting user roles right in ArcGIS Enterprise is one of the highest-impact, lowest-effort improvements a GIS administrator can make. It protects your data, simplifies onboarding, and keeps your Portal clean as your organization grows. If your current setup relies on default roles and manual management, it is worth investing a day to design a proper role structure. QGS helps organizations configure Enterprise security and access frameworks — from initial setup to ongoing administration.

Leave a Reply

Your email address will not be published. Required fields are marked *