Before
An operator likely had to confirm the user identity, determine which account integrations were available, and locate the corresponding account identifiers manually. They then had to move between separate administrative systems to disable or block the account in each applicable service and track whether every action was completed.
How it works
- Validate the incoming request and confirm that a user or account identifier is available.
- Build the target account list, retrieve required user or account details, and check which identity integrations are enabled.
- Route the request through the applicable blocking or disabling actions and finish the workflow after the enabled branches complete.
Workflow details
- Request validation: An incoming email-triggered request starts the workflow. The automation checks whether a username or account identifier is available; requests without a usable user reference follow a separate no-user path instead of proceeding through the standard account-blocking route.
- Target preparation: When a user is identified, the workflow prepares the final account list to be blocked. It also retrieves user or account information where required, including user details from the directory and account identifiers from the identity management system.
- Integration checks: The workflow evaluates whether the configured identity and access integrations are enabled, including directory, identity governance, cloud, collaboration, development, CRM, service management, security, and network access branches. These checks determine which downstream actions should run for the request.
- Account enforcement: The enabled branches route the identified account to their corresponding blocking or disabling stages. The flow includes explicit account-disable processing in the identity governance and directory paths, along with account-blocking or access-control stages for other connected systems such as cloud identity, collaboration, development, and security platforms.
- Completion handling: After the applicable branches finish, the workflow reaches a completion state. Integration-step failures are configured to stop execution, preventing the process from silently continuing after an unsuccessful service operation.
What changed
Account-blocking requests now follow one automated path that validates the target, checks integration availability, prepares account identifiers, and routes actions to the applicable systems. Human operators no longer need to coordinate each system handoff individually, while failed service operations stop the workflow for follow-up.
Work removed
Manually checking the request for a usable username, determining which integrations are enabled, looking up directory and account identifiers, switching between administrative systems, issuing repeated block or disable actions, and tracking completion across systems.
Expected outcome
Each request can replace up to 13 integration-availability checks and their associated manual handoffs, with actual coverage depending on which branches are enabled.
