Queries regarding the Microsoft Entra ID governance API related to campagin and certifications

Question

Hello Team,

I have a few clarifications regarding the Azure Entra ID Governance Access Review APIs.

1. In the Access Review Decisions endpoint: https://learn.microsoft.com/en-us/graph/api/accessreviewinstance-list-decisions?view=graph-rest-1.0

Could you please clarify the difference between the target and principal fields in the response? Specifically, I would like to understand the purpose of each field and in what scenarios their values may differ.

Regarding the accessReviewId returned in the Access Review Decisions endpoint: https://learn.microsoft.com/en-us/graph/api/accessreviewinstance-list-decisions?view=graph-rest-1.0

Is this accessReviewId the same as the id returned from the List Instances endpoint below?

https://learn.microsoft.com/en-us/graph/api/accessreviewscheduledefinition-list-instances?view=graph-rest-1.0

In other words, can the accessReviewId from the decisions API be directly mapped to the id of an instance returned by the instances API?

Is there any endpoint or possible way to retrieve the last login (last sign-in) details of the user whose access is being reviewed in the access review process?

From the Access Review Definitions endpoint (which represents the campaign template): https://learn.microsoft.com/en-us/graph/api/accessreviewset-list-definitions?view=graph-rest-1.0

Is there any field available that indicates the campaign type (for example, whether the review is for groups, roles, applications, or other resource types)?

Thank you for your assistance.

Answer 1

Hello Balamurugan, Susinthika

Thank you for reaching out regarding the Access Review APIs in Microsoft Entra ID using Microsoft Graph. Please find the clarifications below:

1. Principal and target differences These fields in the Access Review Decisions API reflect several review-related entities:

Principal: The person whose access is being examined, such as a service principal, user, or group.

Target: The resource (such a group, application, or directory role) that the principal can access.

For instance, if a user's group membership is being reviewed:

primary → the person under review

target → the user's access group

2. The connection between instance id and accessReviewId Yes. The Access Review Instance ID that the List Instances API returns matches the accessReviewId that the Access Review Decisions API returns.

As a result, the id of the instance returned by the instances endpoint may be easily translated to the accessReviewId from the choices endpoint.

3. Obtaining assessed users' most recent sign-in details Last sign-in information is not provided by the Access Review APIs. Nevertheless, Microsoft Graph may be used to obtain this data from the user object:

GET /users/{user-id}?$select=signInActivity

Fields like lastSignInDateTime and lastSuccessfulSignInDateTime are part of the signInActivity property.

4. Using Access Review Definitions to determine the type of campaign

There isn't a specific field in the Access Review Definitions API that indicates the type of campaign (e.g., group, role, or application review). Rather, it is possible to deduce the resource type under review from the scope configuration, namely the scope.query value, which identifies the resource under evaluation (e.g., directory roles, application assignments, or group membership).

Let me know if any further queries - feel free to reach out!

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.