Understanding Group-Based Permissions and System Behavior

Purpose/Overview

This article explains how permissions are structured in Utilisphere and how group assignments, combined with system options, determine what actions users can perform in the platform. Unlike some systems, Utilisphere does not support direct user-specific permission overrides. Instead, permissions are additive across all groups a user belongs to.

Understanding this structure and how system settings can sometimes override group permissions helps administrators configure access more effectively and troubleshoot cases where users see unexpected behavior.

Things to Know:

• Permission Requirements: Only admin-level users can view or modify group permissions.
• Group-Based Access: All permissions in Utilisphere are granted at the group level. Users inherit the combined permissions from all groups they are assigned to.
• No Direct User Overrides: Permissions cannot be overridden for individual users. If a user needs additional access, adjust their group assignments.
• Additive Permissions: If a user is in multiple groups, their access is the sum of all permissions from those groups.
• System Options Can Override Permissions: Certain configuration settings in Options or other system areas can block or hide functionality, even if the group has the related permission enabled.

Permission Levels:

In Utilisphere, user access is determined entirely by group-based permissions. There are no direct user-specific overrides, and permissions are additive across all assigned groups. Certain system options can override group permissions.

1. Default Groups Permissions: Utilisphere includes several default groups (e.g., Administrators). These provide a baseline set of permissions out of the box. While they conceptually resemble “system roles” in other applications, Utilisphere does not use or display that terminology. All permissions are described in terms of groups.
2. Group-Level Permissions: Administrators can create and manage groups (e.g., by department or region). Each group defines a set of permissions, and users assigned to that group inherit those permissions. If a user is assigned to multiple groups, the permissions are combined. 

Important Nuances: When System Options Override Group Permissions:

While groups define the baseline of what a user can do, other system configurations can sometimes limit or override those permissions.

Examples include:

• Assignment Restrictions: A group may have permission to Assign Ticket, but if the option Prevent Direct Assignment to Locators is enabled, assignment actions will not display. If a group has Assign Ticket but not Un-Assign Ticket, members cannot reassign tickets that are already assigned.
• Sketch Tools: A group may have View Sketch or Modify Sketch permissions, but if a Work Item does not have sketching enabled, users will not see sketch tools.
• Response Restrictions: A group may be configured to access all responses, but if responses are restricted by Registration Code or tied to specific Facility Types, users may only see a subset.
• Ticket Assignment Locking & Dynamic Dispatch: If Ticket Assignment Locking is enabled while Dynamic Dispatch is also in use, some tickets may remain unassignable even if the group has assignment permissions.
• Map Display Settings: A group may be set to display the map by default, but if Display Map for Ticket Details is disabled, the map will not appear in the Ticket Summary.
• Transmission History Links: A group may have permission to Forward Excavator Positive Response from Audit, but the related link will not function unless the group also has Modify Transmission History permission.

Note: These cases are not bugs—they reflect how permissions and system options interact.

Best Practices

• Use broad access groups like Administrators or Field Users as a starting point, then add more specific groups for departmental or regional needs.
• Adjust group permissions rather than creating numerous small groups to reduce complexity.
• Be aware of system options that can limit or hide functionality regardless of group permissions.
• Regularly review group assignments to ensure they reflect current operational needs.
• Keep a record of why specific groups or permissions exist for future reference.

Related Features/Next Steps:

• Groups Overview

Questions?  Contact us!