Before
An administrator would likely need to identify the affected user, reset the password, require a password change at the next sign-in, verify whether the update worked, and notify the appropriate recipient. Failed updates would require separate handling instead of following an automated outcome path.
How it works
- Receive a webhook or email event concerning a potentially compromised user password.
- Update the user's password, require a change at the next sign-in, and automatically evaluate whether the update succeeded.
- Send a confirmation email for a successful update and route a failed update to the failure outcome.
Workflow details
- Trigger: A webhook or email event starts the workflow when a user's password may have been compromised or identified in a breach.
- Password response: The workflow updates the targeted directory user and enables the requirement to change the password at the next sign-in.
- Validation: After the update, an automated condition evaluates whether the operation succeeded and separates successful and unsuccessful outcomes.
- Confirmation: When the update succeeds, the workflow sends a confirmation email to the configured recipient.
- Failure handling: When the update does not succeed, the workflow follows its failure branch. The accompanying workflow note describes automatic account locking for this situation, although the visible implementation ends at a failure step rather than showing a separate locking operation.
What changed
A password-compromise event now starts the reset sequence automatically, with the directory update, next-sign-in requirement, success check, and confirmation notification handled in one flow. Successful and unsuccessful results are separated immediately, without requiring a person to perform the notification or outcome routing first.
Work removed
Manually issuing the password update, enabling the next-sign-in password-change requirement, checking whether the update succeeded, routing the result, and sending the confirmation email.
Expected outcome
Each qualifying event produces an automated password-reset decision and, when successful, a confirmation notification, removing at least the recurring update, verification, routing, and notification actions from the initial response.
