It really doesn't - it was mandatory a while ago but with @pedroigor 's latest changes to the JSON definition it is no longer the case.

This will be replaced with the concurrency config as we've discussed

Yes, idea is to have just "if": "expression" instead of the whole condition config

Yes - this is one of the issues in the roadmap - whether it will be in Milestone 2 or 3 is yet to be defined :)

Good point - I'll look into the grammar and see if I can get rid of the whole double quotes or at the very least switch the single quotes to prevent having to escape these characters in the config.

We will probably have an action in the UI to trigger this action - probably an async operation as it can time consuming to locate all users depending on the amount of users in the DB and how complex the conditions are.

So a more broad answer to your question is that Workflows can be automatically enabled based on events, but it is also possible to trigger them "manually" via an enpoint call

@sguilhen Thanks for your reply.

What about adding a feature to trigger the workflow on missing user events. For example, admins can create a workflow that get triggered on missing USER_LOGIN event with a condition expression that checks if the user is created N milliseconds ago?

I believe something like that can be useful for most old Keycloak installations. I believe most installations configure Keycloak to delete events after a specific period, and most inactive users stay inactive forever.

We've been thinking about some ways to handle the inactive users. One way would be to create a workflow that tracks the active users, give it some warm up time (a couple of weeks, a month maybe) so that all your active users trigger the workflow, and then create another workflow that attaches to all users who have not activated the first workflow (i.e. the condition would be the lack of association with the first workflow). This second workflow can have a step that is triggered right away to disable or even delete these users, but it wouldn't be activated on a particular event. An admin would have to select it and then apply it to all eligible resources.

There are certainly other ways to approach this. Looking for stored login events might work in some installations, depending on whether they store these events and for how long. Perhaps a condition that says "user-older-than(30d) AND user-event-missing(USER_LOGIN, 20d)" to convey you are looking for users at least 30 days old who have not logged in in the last 20 days. And then you can add a step that removes those users right away. But again, there won't be a particular event you would be listening to in order to identify these stale users.

We will keep thinking about ways to handle this situation, perhaps adding some suggestions in the documentation, but I think we won't have a one-size-fits-all solution for this as the conditions vary greatly across deployments.

You can listen for deletion if your listener is handling provider events and the UserRemovedEvent event. There is no provider event for user updates.

Before solving this problem, we need to review the event subsystem in Keycloak to make it more consistent. Today we have at least 3 different types of events and, sometimes, they overlap with each other. Also, some events, like user/admin events, which you are probably interested in, are very specific to the Admin API or authentication flows, making it hard to leverage them in Workflows without duplicating code/logic when firing events. IMO, steps should not worry about programmatically firing events whenever executing operations or changing the state of a realm resource.

It makes a lot of sense to have those workflow-specific events, and in the meantime, while we don't review events in Keycloak, it can help to achieve what you want. Not the best because you will need to listen for a user/admin plus the workflow event.

Not the best because you will need to listen for a user/admin plus the workflow event.

Yes, unfortunately it's not the best. It scatters event handling over several places. But at least... something.
Thanks for clarifying.

It seems that the UserRemovedEvent is not properly emitted, but a UserStorageManager$4 event.
From my log (see line 4), there's not UserRemovedEvent:

2025-10-08 16:07:03,520 INFO  [dasniko.keycloak.events.CustomEventListener] (Timer-0) Fired CustomEventListener: org.keycloak.models.workflow.WorkflowStepRunnerSuccessEvent
2025-10-08 16:07:03,523 DEBUG [org.keycloak.models.workflow.WorkflowsManager] (Timer-0) Running step delete-user on resource f2a1e2a3-d6db-4900-b5cc-2869599cc29c (execution id: abab04f3-df32-43ff-8f7c-12c0e8fca01c)
2025-10-08 16:07:03,524 DEBUG [org.keycloak.models.workflow.DeleteUserStepProvider] (Timer-0) Deleting user test (f2a1e2a3-d6db-4900-b5cc-2869599cc29c)
2025-10-08 16:07:03,557 INFO  [dasniko.keycloak.events.CustomEventListener] (Timer-0) Fired CustomEventListener: org.keycloak.storage.UserStorageManager$4
2025-10-08 16:07:03,597 DEBUG [org.keycloak.models.workflow.WorkflowExecutionContext] (Timer-0) Step delete-user completed successfully (execution id: abab04f3-df32-43ff-8f7c-12c0e8fca01c)
2025-10-08 16:07:03,598 DEBUG [org.keycloak.models.workflow.WorkflowExecutionContext] (Timer-0) Workflow 'disable inactive users' completed for resource f2a1e2a3-d6db-4900-b5cc-2869599cc29c (execution id: abab04f3-df32-43ff-8f7c-12c0e8fca01c)
2025-10-08 16:07:03,598 INFO  [dasniko.keycloak.events.CustomEventListener] (Timer-0) Fired CustomEventListener: org.keycloak.models.workflow.WorkflowStepRunnerSuccessEvent

I guess it is because it is an anonymous class. An instanceof should map the UserRemovedEvent type.

Unfortunately, it doesn't. That's my code:

@Override
public void postInit(KeycloakSessionFactory factory) {
  factory.register(fired -> {
    log.info("ProviderEvent fired: {}", fired.getClass().getName());
    if (fired instanceof UserModel.UserRemovedEvent event) {
      log.info("UserRemoved event: {} - {}", event.getRealm().getName(), event.getUser().getUsername());
    }
  });
}

I never see the "UserRemoved event: ..." message in the logs.
I copied the code from JpaWorkflowStateProviderFactory, so it should work!?
Does my Factory has to implement the WorkflowStateProviderFactory interface?

I think the way the step is working is consistent with what happens when an admin disables a user in the admin console. Existing sessions are still active but any attempt to login or refresh a token will fail for this users. Maybe in this case it would be better to have a separate step to terminate the active sessions, with the possibility to also trigger the backchannel logout in the process. Then the workflow would have 2 separate steps to handle user disabling and session termination.

Yeah, steps should address a single and specific concern so that you can combine them to achieve your goals. IMO, it is a key design principle.

Thanks, understood.

Indeed, thanks for spotting and for the PR!