Update 08-10-2020: Microsoft released an official connector for Azure AD Identity Protection. This would be much easier to use, since you don't have to create a service principal to authenticate the custom connector. However, at the time of writing the official connector does not have the action to get all the risky users. Will keep an eye on things.
This blog was inspired by an Azure AD Mailbag blog about Azure AD Identity Protection. In the article, Microsoft provided a PowerShell script sample that you can use for bulk dismissal of risky users. Today I will show you how you can use either Power Automate or Logic Apps to do the same. You could use the Graph API with an HTTP request for this, but to make things simple, I created a custom connector. I used the riksyUser Graph API.

If you have never worked with app registrations and custom connectors, I suggest you check out this blog where I worked out some more detailed steps on every subject. You can use it as a reference guide.
What do we need?
First, we need the custom connector source files to install the connector in your own tenant. You can grab them from Github.
Next, we need an app registration for authentication. Create a new app registration with the following properties:
Permissions: IdentityRiskyUser.ReadWrite.All Graph API application permissions.
Web redirect URL: https://global.consent.azure-apim.net/redirect
Create a new secret and store it in Notepad together with the Application(client) ID and Directory (tenant) ID.

Install the custom connector
Upload the custom connector by using the browser or the paconn CLI tool. Enter the OAth2.0 credentials and make sure that the connector works correctly by testing the ListRiskyUsers action for example.

Build the flow
Now that we have installed the Risky Users connector, we can build our flow. Start off with a blank automated flow and use manual flow trigger.
Next, add the custom connector action ListRiskyUsers and select the preferred filter.

You can add a custom value if you want to be more specific.
In the next step, I make sure that the risk of the users was updated in the past 30 days, just like the sample script does. Create a Filter array action, and add the custom expression:
addDays(utcnow('yyyy-MM-ddTHH:mm:ssZ'), -30)
Use the output (value) from the first action as your input. You can select the riskLastUpdate parameter from the previous step.

Add the last two steps to complete te flow. First, we have to lookup the ID of the user and than dismiss the risk.

Make sure that you selected the output of the filter array (30 days) as your input. From the Azure AD connector, select the Get User action and provide the UserPrincipalName from the previous step.
Next, add the Dismiss Risky user action from the custom connector, and add the Id from the user.
In my demo tenant, I got only 4 risky users. Test and run the flow.

The API returns an empty 204 response, but you can check the user object to see of the risk is dismissed.

Wrap up
I hope this blog post was helpful. This is just another good example on how easy you can automate with the use of Graph API and Power Automate or Logic Apps.
If you want to get started with building your own custom connector, please check this blog post I wrote on the Power Platform community website.
Stay safe!
Thanks for sharing this great information.
Is there a way to automatically send a notification email with the risk information? for as of today, Azure only send a notification that a user account is at risk with no further details.
Yes, but you would need to do this through the logic app.
Have the app trigger the logic app
Logic app will run another query and collect the fields that you are interested in
next step will send the email and you can format it however you like
I hope that this helps
Hi Jan,
When testing the connector, I get an AccessDenied error. Your account does not have access to this report or data.
I was under the impression that the permissions of the app registration would be used here. I am wrong? I am looking for a solution to enable helpdesk staff to dismiss user risk without granting them Security Administrator Role.
Thanks!