Approval workflow in PIM for Azure resource roles offers administrators the ability to protect and restrict access to critical Azure resources by allowing them to require approval to activate role assignments. Resource hierarchy, which is unique to Azure resource roles, allows for the inheritance of role assignments from parent resources and objects down to child resources within the parent container. To illustrate the approval workflow process in PIM, I'll use the following example. Let's assume Steve is a resource administrator. Steve uses PIM to assign Jen as an eligible member to the owner role in the subscription for Blue Widget Co. Through this assignment, Steve makes Jen an eligible owner of all resource group containers within the Blue Widget Co Azure subscription. Because Jen is an eligible owner of all resource group containers, she is also an eligible owner of all resources residing within each resource group contained in the subscription. Now remember PIM settings, unlike assignments, are configured for each role of a resource. As such, the PIM settings that are configured for a resource are not inherited. They are applied strictly to the resource role. In our example, let's imagine that there are three resource groups called finance test, finance dev, and finance prod, all located in the Azure subscription. 

Each resource group contains two virtual machines. Imagine that Steve uses PIM so that he can require that all owner role members of the Blue Widget Co subscription request approval to be activated. To further protect the resources in the finance prod resource group however, Steve also requires approval for members of the owner role of this resource. Steve is less worried about security on the finance test and finance dev resource groups so he does not require the owner roles in either to require approval for activation. Given the approval flow and hierarchy in our example, if Jen requests activation of her owner role for the Blue Widget Co subscription, she's going to need an approver to either approve or deny her request before she becomes active in the role. Similarly, if Jen scopes her activation to just the finance prod resource group, an approver again will need to approve or deny this request. However, if Jen were to scope her activation to just finance test, just finance dev, or both, approval would not be required. This is because Steve did not require approval for members of the owner role for any of these two resource groups. So as our example demonstrates, Azure AD Privileged Identity Management provides a means of configuring granular and hierarchical security that can protect resources by limiting unnecessary administrative access while also allowing for consistent admin access when it's required.