Azure Activity Directory Entitlement Management Service
- by Rob
The Challenge
Employees in organizations need access to groups, apps, and SharePoint sites to perform their job. Azure entitlement management service, a new product, can simplify this process.
The challenge is to create a directory of packages that can contain these resources. A user should be able to search packages, see details of resources, request access, and track the status of their request.
In the review process, a user should be able to grant or deny access with justification and see request history.
Overview
1. Base layer is a directory of many packages, displayed as a grid.
2. Grid pops open to a card, which represents a single package of resources.
3. A hover allows the user to see details of each resource in the package.
The Approach
The design process was divided into two sections.
• Designing the directory experience, where users can view, search, and start the request process.
• Designing the request / approval process.
My Role
• Primary designer for the end-user experience.
• Lead ideation and conceptualized the final design.
• Partnered with product and engineering teams to foster a common understanding of design decisions.
• Worked closely with engineering on implementation.
How does it work?
Access entitlement service, a feature of Azure Active Directory, allows a company to share resources, such as SharePoint Online Sites, SaaS apps and groups with another company, where identity is the control plane.
A company has resources in the cloud it would like to share.
This service has a feature that allows directories to be connected. Connecting organizations is the first step in sharing resources.
Kate needs to start collaborating with Alan, who is at an outside consulting company. She creates a package of resources, and sets a policy that determines who can request and who can approve access.
Alan and his team can see the package created by Kate in a directory. Kate, or whoever she assigned to approve requests, will receive the requests from Alan.
Considerations
• Scalability: Accounting for scenarios where organizations need to collect more information, add multiple approvers, and delegate or escalate access requests.
• Responsive design. Requests and approvals must happen on mobile.
• Search: User will need to be able to review and compare contents of multiple packages.
• Sharing: A package and its resources must be able to reside at a single URL.
• System Status: Show the status of the request at any given time.
Directory: A user, Alan, selects a package from a directory.
Viewing the resources: The user can click the chevron to open the contents of a package.
Package resource details: User can hover on a resource to see its details, such as level of access.
Search: Search results can display multiple packages, allowing users to compare the resources of packages.
Direct link: Even though all packages live in a directory, each package can have its own URL, useful for sharing direct links to users who need to request.
Requesting: A context pane allows user to start the request process.
Approval process: A user, Kate, is ready to review requests.
Approver is able to see request in a directory.
The Approver panel has minimal information, to allow the user to focus on the task. More information is available if needed to make a decision under "details."
Approver hovering to look at additional details.
An earlier design option surfaced more information for the user. Early designs also experimented using a vertical stepper to track the request history.
