# Externally determine the approval requirements for an access package using custom extensions (Preview)
In entitlement management, approvers for access package requests can either be directly assigned, or determined dynamically. Entitlement management natively supports approvers when they are the requestors manager, their second-level manager, or a sponsor from a connected organization:
:::image type="content" source="media/entitlement-management-dynamic-approval/native-support-diagram.png" alt-text="Screenshot of native support of approvers in Entitlement management." lightbox="media/entitlement-management-dynamic-approval/native-support-diagram.png":::
With the inclusion of [custom extensions](entitlement-management-logic-apps-integration.md) calling out to [Azure Logic Apps](/azure/logic-apps/logic-apps-overview), you're able to determine approval based on each of the [ApprovalStage properties](/graph/api/resources/approvalstage?view=graph-rest-beta#properties). For example, if the user requesting an access package is in a department where leadership has recently changed, dynamic approvals can query the system and assign the new department head as the approver.
:::image type="content" source="media/entitlement-management-dynamic-approval/dynamic-extensibility-diagram.png" alt-text="Screenshot of example of determining approvers using custom extensions." lightbox="media/entitlement-management-dynamic-approval/dynamic-extensibility-diagram.png":::
}
```
Although the example uses a user ID, the primaryApprovers and escalationApprovers section can contain any valid [subjectSet](/graph/api/resources/subjectset). The approval section of the code must follow the parameters as shown here: [accessPackageApprovalStage](/graph/api/resources/accesspackageapprovalstage).
> [!NOTE]
> In Public Preview the resume call must be performed against Microsoft Graph's beta endpoint. However, the [accessPackageApprovalStage](/graph/api/resources/accesspackageapprovalstage) provided in the resume call body must follow the [v1.0 convention](/graph/api/resources/accesspackageapprovalstage) and not the [beta convention](/graph/api/resources/approvalstage).
## Related content
# Externally determine the approval requirements for an access package using custom extensions (Preview)
In entitlement management, approvers for access package requests can either be directly assigned, or determined dynamically. Entitlement management natively supports dynamically determining approvers such as the requestors manager, their second-level manager, or a sponsor from a connected organization:
:::image type="content" source="media/entitlement-management-dynamic-approval/native-support-diagram.png" alt-text="Screenshot of native support of approvers in Entitlement management." lightbox="media/entitlement-management-dynamic-approval/native-support-diagram.png":::
With the introduction of [custom extensions](entitlement-management-logic-apps-integration.md) calling out to [Azure Logic Apps](/azure/logic-apps/logic-apps-overview) you are now able to dynamically determinie approval requirements for each access package assignment request based on your organizations specific business logic. The access package assignment request process will pause until your business logic hosted in Azure Logic Apps returns a [approval stage](/graph/api/resources/accesspackageapprovalstage?view=graph-rest-1.0) which will then be leveraged in the subequent approval process via the [My Access portal](https://myaccess.microsoft.com). For example, if access requests must be approved by the department head of the person requesting an access package this feature allows you to query an external system, such as your human resources (HR) system, to on-the-fly look up the current department head and assign them as the approver for the given access request.
:::image type="content" source="media/entitlement-management-dynamic-approval/dynamic-extensibility-diagram.png" alt-text="Screenshot of example of determining approvers using custom extensions." lightbox="media/entitlement-management-dynamic-approval/dynamic-extensibility-diagram.png":::
}
```
Although the example uses a user ID, the primaryApprovers and escalationApprovers section can contain any valid [subjectSet](/graph/api/resources/subjectset). The approval section of the code must follow the parameters as shown here: [accessPackageApprovalStage](/graph/api/resources/accesspackageapprovalstage?view=graph-rest-1.0).
> [!NOTE]
> In Public Preview the resume call must be performed against Microsoft Graph's beta endpoint. However, the [approval stage](/graph/api/resources/accesspackageapprovalstage?view=graph-rest-1.0) provided in the resume call body must follow the [v1.0 convention](/graph/api/resources/accesspackageapprovalstage?view=graph-rest-1.0) and not the [beta convention](/graph/api/resources/approvalstage?view=graph-rest-beta).
## Related content