[GH-ISSUE #4472] [Feature Request]: Webhooks for App Consent Requests need more fields included

kerem commented

2026-03-02 13:49:14 +03:00

Owner

Originally created by @dszp on GitHub (Jul 28, 2025).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/4472

Please confirm:

I have searched existing feature requests (open and closed) and found no duplicates.
**me or my organization is currently an active sponsor of the product at the $99,- level. (see https://github.com/orgs/servant42inc/people to validate I'm a member of the same org as the same-company-name user account that sponsors)

Problem Statement

When a webhook is triggered with the Command Get-CIPPAlertNewAppApproval ("Alert on new apps in the application approval list") it does not contain enough information to be fully actionable.

The alerts noted in this webhook contain these fields currently:

AppName
RequestUser
AppId
Scopes
ConsentURL
Tenant

It would be helpful to have additional fields added to this grouping:

Creation/request date
Status (as displayed in the CIPP UI)
Action Taken By (if it has been actioned)
TenantID (GUID) in addition to the Tenant name field

Related but haven't opened a separate request for yet, would also love to be able to approve or deny the app from with in the CIPP UI rather than having to open the ConsentURL with permissions in the client tenant. Maybe this is not possible? Alternately, a way to copy the requested app to a new App Deployment standard to add consent with the requested permissions directly would be helpful. Can submit this request separately if it's even possible--just having more info in the webhook would make this more useful immediately.

Benefits for MSPs

Notifications or tickets we create from the app consent webhook notifications would be able to present a more holistic status of the request to MSP employees for evaluation and action, and including the status would allow for filtering to only alert on actionable (pending) notifications.

Value or Importance

The missing information is critical to being able to only alert on actionable app consent requests from the webhook call, since no status is included. The rest of the fields are less of a priority, but the Status field is reasonably critical for the specific use case.

PowerShell Commands (Optional)

No response

Originally created by @dszp on GitHub (Jul 28, 2025). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/4472 ### Please confirm: - [x] **I have searched existing feature requests** (open and closed) and found no duplicates. - [x] **me or my organization is currently an active sponsor of the product at the $99,- level. (see https://github.com/orgs/servant42inc/people to validate I'm a member of the same org as the same-company-name user account that sponsors) ### Problem Statement When a webhook is triggered with the Command `Get-CIPPAlertNewAppApproval` ("Alert on new apps in the application approval list") it does not contain enough information to be fully actionable. The alerts noted in this webhook contain these fields currently: - AppName - RequestUser - AppId - Scopes - ConsentURL - Tenant It would be helpful to have additional fields added to this grouping: - Creation/request date - **Status** (as displayed in the CIPP UI) - Action Taken By (if it has been actioned) - TenantID (GUID) in addition to the Tenant name field Related but haven't opened a separate request for yet, would also love to be able to approve or deny the app from with in the CIPP UI rather than having to open the ConsentURL with permissions in the client tenant. Maybe this is not possible? Alternately, a way to copy the requested app to a new App Deployment standard to add consent with the requested permissions directly would be helpful. Can submit this request separately if it's even possible--just having more info in the webhook would make this more useful immediately. ### Benefits for MSPs Notifications or tickets we create from the app consent webhook notifications would be able to present a more holistic status of the request to MSP employees for evaluation and action, and including the status would allow for filtering to only alert on actionable (pending) notifications. ### Value or Importance The missing information is critical to being able to only alert on actionable app consent requests from the webhook call, since no status is included. The rest of the fields are less of a priority, but the Status field is reasonably critical for the specific use case. ### PowerShell Commands (Optional) _No response_

kerem

2026-03-02 13:49:14 +03:00

closed this issue
added the
enhancement

no-priority

not-assigned
labels

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@Zacgoose commented on GitHub (Jul 29, 2025):

These alerts are generated only for "InProgress" requests, as such the status at the time of the alert will always be InProgress, there will be no action taken by as its not been completed.
Adding RequestDate and the status is easy (even though it'll always be InProgress)
TenantID should also be fine I guess

@Zacgoose commented on GitHub (Jul 29, 2025): These alerts are generated only for "InProgress" requests, as such the status at the time of the alert will always be InProgress, there will be no action taken by as its not been completed. Adding RequestDate and the status is easy (even though it'll always be InProgress) TenantID should also be fine I guess

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@dszp commented on GitHub (Jul 29, 2025):

These alerts are generated only for "InProgress" requests, as such the status at the time of the alert will always be InProgress, there will be no action taken by as its not been completed.
Adding RequestDate and the status is easy (even though it'll always be InProgress)
TenantID should also be fine I guess

Interesting--I guess that makes sense, but it's not stated anywhere and without a date stamp or documentation, I didn't find it to be clear. Thanks for the info! Having the status included would at least be more self-documenting.

Is it possible at all to approve via Graph as well, or should I not hold out hope/request that feature separately?

@dszp commented on GitHub (Jul 29, 2025): > These alerts are generated only for "InProgress" requests, as such the status at the time of the alert will always be InProgress, there will be no action taken by as its not been completed. > Adding RequestDate and the status is easy (even though it'll always be InProgress) > TenantID should also be fine I guess Interesting--I guess that makes sense, but it's not stated anywhere and without a date stamp or documentation, I didn't find it to be clear. Thanks for the info! Having the status included would at least be more self-documenting. Is it possible at all to approve via Graph as well, or should I not hold out hope/request that feature separately?

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@Zacgoose commented on GitHub (Jul 29, 2025):

According to the MS docs it is not possible to approve or deny apps programmatically

@Zacgoose commented on GitHub (Jul 29, 2025): According to the MS docs it is not possible to approve or deny apps programmatically

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@joelkino commented on GitHub (Jul 29, 2025):

I don't think it's currently possible to approve the request using gdap permissions unless the Application Administrator role is added to the Roles (Preview) section in the Admin Consent Approvers. But once added then it's possible - which would then allow techs to GDAP via CIPP to approve and not have to log in with GA. So that could be a nice standard

@joelkino commented on GitHub (Jul 29, 2025): I don't think it's currently possible to approve the request using gdap permissions unless the Application Administrator role is added to the Roles (Preview) section in the Admin Consent Approvers. But once added then it's possible - which would then allow techs to GDAP via CIPP to approve and not have to log in with GA. So that could be a nice standard

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@dszp commented on GitHub (Jul 29, 2025):

I don't think it's currently possible to approve the request using gdap permissions unless the Application Administrator role is added to the Roles (Preview) section in the Admin Consent Approvers. But once added then it's possible - which would then allow techs to GDAP via CIPP to approve and not have to log in with GA. So that could be a nice standard

That would be a welcome change if possible. I also realized this morning that it would be nice if the displayName of the tenant was included in the webhook (this would be for all webhooks, actually). It would reduce API calls to pull it in after the webhook and allow for matching to PSA client name, as we try to standardize on exactly the same display name in all of our systems so we can easily match for ticketing purposes.

Obviously we can just do an API request to match from the current tenant name (or ideally GUID as I noted) to grab this, as well, but it seems like including it wouldn't be hard?

@dszp commented on GitHub (Jul 29, 2025): > I don't think it's currently possible to approve the request using gdap permissions unless the Application Administrator role is added to the Roles (Preview) section in the Admin Consent Approvers. But once added then it's possible - which would then allow techs to GDAP via CIPP to approve and not have to log in with GA. So that could be a nice standard That would be a welcome change if possible. I also realized this morning that it would be nice if the `displayName` of the tenant was included in the webhook (this would be for all webhooks, actually). It would reduce API calls to pull it in after the webhook and allow for matching to PSA client name, as we try to standardize on exactly the same display name in all of our systems so we can easily match for ticketing purposes. Obviously we can just do an API request to match from the current tenant name (or ideally GUID as I noted) to grab this, as well, but it seems like including it wouldn't be hard?

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@dszp commented on GitHub (Jul 29, 2025):

Also, is there a globally unique ID for each alert that could be included? There appears to be one embedded in the ConsentURL, but I'm not sure if it's accessible outside of that. It would be helpful to deduplicate requests and ensure that once a ticket was created for a request, that it wasn't re-created if it hadn't yet been actioned, the next time the webhook fires. I am seeing repeated firing of the same pending requests via webhook repeated in my observations, so this does seem to be helpful to have if possible. I may be able to add the displayName and maybe this ID myself now that I know where it is in the code; I'll take a look a bit later...

@dszp commented on GitHub (Jul 29, 2025): Also, is there a globally unique ID for each alert that could be included? There appears to be one embedded in the ConsentURL, but I'm not sure if it's accessible outside of that. It would be helpful to deduplicate requests and ensure that once a ticket was created for a request, that it wasn't re-created if it hadn't yet been actioned, the next time the webhook fires. I am seeing repeated firing of the same pending requests via webhook repeated in my observations, so this does seem to be helpful to have if possible. I may be able to add the displayName and maybe this ID myself now that I know where it is in the code; I'll take a look a bit later...

kerem commented

2026-03-02 13:49:15 +03:00

Author

Owner

@Zacgoose commented on GitHub (Jul 29, 2025):

I already have a pending PR to add a couple of those extra details as mentioned. CIPP at this time does not track previous alerts, so on so forth. The ID you see in the consent url is the App Id and this is in the response data. Feel free to comment in the PR if there is something you would like to add :)

@Zacgoose commented on GitHub (Jul 29, 2025): I already have a pending PR to add a couple of those extra details as mentioned. CIPP at this time does not track previous alerts, so on so forth. The ID you see in the consent url is the App Id and this is in the response data. Feel free to comment in the PR if there is something you would like to add :)

kerem commented

2026-03-02 13:49:16 +03:00

Author

Owner

@dszp commented on GitHub (Jul 29, 2025):

I added a non-conflicting pull request that adds the "id" field of the consent request itself as well. I looked at your pull request @Zacgoose which helped me find the right file, thanks for the pointer! I definitely want what's in your pull request, just added an additional field. If I'd seen your note first I guess I could have added a comment instead...

I am torn a little about adding the client displayName as well; I didn't add it in my request. It does make for an extra API call when the webhook is received, but it saves a Graph request when the webhook is created, so maybe that's fine. Not everyone will use it the way I am, and the tenant ID will provide material for the name call reliably.

@dszp commented on GitHub (Jul 29, 2025): I added a non-conflicting pull request that adds the "id" field of the consent request itself as well. I looked at your pull request @Zacgoose which helped me find the right file, thanks for the pointer! I definitely want what's in your pull request, just added an additional field. If I'd seen your note first I guess I could have added a comment instead... I am torn a little about adding the client `displayName` as well; I didn't add it in my request. It does make for an extra API call when the webhook is received, but it saves a Graph request when the webhook is created, so maybe that's fine. Not everyone will use it the way I am, and the tenant ID will provide material for the name call reliably.

Rows
Columns

[GH-ISSUE #4472] [Feature Request]: Webhooks for App Consent Requests need more fields included #2050

Please confirm:

Problem Statement

Benefits for MSPs

Value or Importance

PowerShell Commands (Optional)