Scope Groups
A role-base access control framework that restricts user visibility and actions across the GreenLake Cloud platform and underlying services.
Discovery
Ideation
Design
Prototype
Project Overview
Cloud platforms like HPE GreenLake must be flexible enough to handle different customer setups. The deployment of HPE GreenLake should be able to adapt to customer needs from a single setup at the edge, a few workspaces joined together to share services, or many separate workspaces to keep data isolated and secure. This scaling ability means that no matter how much a business grows, its control, management, and billing always stay together in a centralized place.
HPE GreenLake’s legacy RBAC framework, specifically Resource Restriction Policies (RRPs) created a confusing, error-prone experience for users. Beyond solving this usability friction, we needed a scalable solution for large enterprise environments. To address these challenges, we introduced Scope Groups as a modernized replacement for RRPs within the IAM 2.0 release.
Role
Lead UX Designer
Timeline
SEP. 2024 - OCT. 2024
Media mentions
Discovery
Resource Restriction Policies (RRPs) short-comings
In the project kickoff meetings with stakeholders we first discussed the shortcomings of the current Resource Restriction Policy (RRP) framework. There has been history with customers and internal teams that have reported struggling to effectively use and manage legacy RRPs due to a confusing user experience, functional limitations, and high administrative maintenance.
User experience
In the resource restriction policy creation wizard workflow, the tree component introduced friction by making it difficult for users to interpret and select resource data.
Component Usability Challenges & Hierarchical Confusion
User and engineering feedback revealed three core issues with the resource tree component: administrators struggled to track and edit their selections, engineering noted an inaccurate hierarchy, and users found the resource syntax confusing.
Functional limitations
-
When a service introduces new resources, the custom RRP policy fails to include them automatically, even if the policy was set to 'all resources.' In result, authorized users with Read-Write permissions were unexpectedly blocked from managing new infrastructure.
-
Resource Restriction Policies are not available for MSP workspaces and their tenant.
High administrative maintenance
For the functional limitations administrators must manually update the RRP everytime a new resource is added to a service.
Misleading UI
In the 'Selected Resources' view, the sub-header text was misleading: it implied editability, yet users were unable to modify or remove their selected resources.
Define
Project goals
While Scope Groups and Resource Restriction Policies share a foundational purpose, we wanted to introduce a more refined workflow and an updated approach to the information architecture.
-
Feature name change
-
To signal that this was a major strategic overhaul rather than a minor update, we set out to rename the feature. Following stakeholder alignment and industry benchmarking, we established Scope Groups as an intuitive, recognizable term to replace Resource Restriction Policies. In the context of Identity and Access Management (IAM), scope refers to the precise boundary or extent of an action, permission, or policy - defining which resource or set of resources an operation is intended to apply to.
-
Data architecture
-
Once the core definition of Scope Groups was established, system architects defined a scope groups hierarchical taxonomy through a HPE GreenLake Resource Notation (GRN). An GRN is a URI-compatible syntax that assigns a unique, structured identifier across platform instances, workspaces, regions, providers, and resources—allowing for precise resource targeting.​​
-
GRN syntax structure:
-
grn: platform-instance + [/workspace + /resource region] + /provider namespace + /resource path
-
Ex: grn:glp/workspaces/{uuid}/regions/{region-name}/resource-providers/{rp-name}/{resource-type}/{identifier}​
-
-
Design requirements
Following an in-depth discovery phase that uncovered the limitations of Resource Restriction Policies (RRPs) and the frustrations administrators faced when managing and assigning them to roles we defined clear design requirements to guide my ideation process.
Ideation
User flow of creating a scope group
For the Scope Group creation workflow, I opted for a progressive form. This approach aligned with the platform’s emerging design standards and provided a familiar, streamlined experience for users.
Mid-fidelity wireframes
Stakeholder & UX Design critique feedback
Stakeholders and UX designers responded positively to the new direction, noting only a few areas where additional context or clarity was needed.
Iteration
Providing more context and clarity to the scope options.
Iteration
Each scope instance has an associated ID. The ID should be shown in the drop down list.
Hi-fidelity wireframes
After refining the main Scope Group creation flow, I transitioned to high-fidelity wireframes for the main landing pages as well as key secondary workflows, including:
-
Deleting a Scope Group
-
Editing an existing Scope Group
-
Removing scopes within a group
Scope Group details page
On this landing page, the primary challenge was determining how to clearly represent individual scopes within a Scope Group. To ensure the design accurately reflected the underlying technical architecture, I collaborated closely with the lead architect to define the exact scope syntax how display each scope.
Scope syntax:
​
/regions/{region-name}/providers/{provider-name}/{resource}/{scope-instance}/ID:/{ID)
In addition, to the scope data schema the scope group schema (HPE GreenLake Resource Notation (GRN) also needs to be display on the details page.
Scope groups page (Day-N state)
Design notes: scope group sorting is by name in ascending order.
Scope groups filter side drawer layer
Design notes: service filters should be alphabetically.
Delete scope group workflow
Beyond minor copy updates, the deletion workflow for Scope Groups mirrors that of legacy RRPs: deletion is restricted if the group is currently attached to active role assignments. To successfully delete a Scope Group, users must first remove all associated role assignments.
Editing an existing scope group workflow
To maintain platform design consistency, I opted for a side drawer interaction pattern rather than an inline editing approach.
Removing scopes within a group
Similar use cases apply and outcomes fom legacy RRP's occur with scope groups.
Final scope group creation workflow
Including the day 0 state of the scope group landing page.
Final adding scopes workflow
Including final copy text and error handling states for each of the form fields.
Removing scopes within a group
Similar use cases apply and outcomes fom legacy RRP's occur with scope groups.
Impact & Retrospective
Impacts
-
Enables more granular scoping boundaries for role assignments.
-
By representing Scope Groups with a GRN syntax, administrators can also perform these management workflows and role assignments directly via the command line.
-
Delivers a more intuitive experience when resource providers introduce new scope instances.
-
Beta testing with key administrators confirmed that Scope Groups are significantly easier to understand and manage than legacy RRPs.
Contraints
-
Since Scope Group availability is tied directly to the IAM 2.0 release:
-
Existing Workspaces: Retain legacy RRPs until migrated to IAM 2.0.
-
New Workspaces: Automatically provisioned with IAM 2.0 and Scope Groups by default.
-
Retrospective
-
Looking back, the design of Scope Groups was fundamentally shaped by close engineering collaboration. Because the underlying data architecture and GRN taxonomy were evolving in parallel with the UI, our interaction workflows had to adapt to technical constraints in real time. This experience reinforced the value of early cross-functional alignment: bridging backend system rules with user mental models early on saved us from costly interaction redesigns later in the process.
Explore more projects
Admin Portal
System configuration for Data Services Cloud Console (DSCC).
Customer Markup Rates
Cost-Plus Pricing Engine that empowers Managed Service Providers (MSPs) to configure custom markup rates on downstream client subscriptions and services.
