We need to update the schema. For instance

    "concurrency": {
      "type": "object",
       "properties": {
         "cancel-if-running": {
           "type": "boolean"
         }
       }
    },

should replace reset-on property.

recurring is also not available.
It seems that from top level properties, only name is actually required as uses is selected automatically if none provided.

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!

I've thought about adding some tab to the user's details page where you would be able to see the workflows currently associated with the user, or the steps scheduled to run for that user. We will need to figure out the details though. Do you envision something different for that?

That's the kind of information I'd expect, nothing different. 👍
An admin probably wants to know which workflows are associated/active with the user and which steps are being executed and which steps will be executed, each with timestamps.

Hi @TuningYourCode , thanks for the message!

You are right. For 2-3, and likely other uses cases, we will need to add the events that would allow us to trigger a workflow. It is very difficult to foresee all possible use cases, so we will rely on feedback from the community to keep enhancing the list of events available for workflows. Regarding the notify user the step allows for the specification of the message key that should be used when composing the e-mail. So I think it might be re-usable for most use cases.

Number 4 has to do with another governance capability - see more on #41350. It is being discussed and I don't yet know how this will integrate with Workflows, but in theory it should be possible to have workflows triggering approval requests upon certain events.

@sguilhen after some thought I would suggest a webhook system first for keycloak user and admin events, which would be more predictable and most likly the use-case 95% the userbase needs. From a techn. perspective this system would focus on deliverability and would leverage the existing event system. features are retries, hmac encrypt, delivery types (http, file, fifo api queue(pull by client)...), maybe logs.
user could define like delivery targets, when an event occurs it would be delivered to all matching targets.

=> good reference is svix, but i do think this could start very small just with http to not complicate things 😄

Afterwards an integration in workflow engine with an additional step in workflows allowing to trigger custom events which are now handled like the other events.
benefit for the workflow engine is, that there doesnt have to be error handling and the step is not blocking execution because potentialy failing delivery is not part of the step.

=> workflow step would "just" trigger this custom event and would not care about where it goes

=> custom event could just be admin events with an custom name and a custom payload

maybe custom events would be a good addition for some folks regarding monitoring/reporting and maybe some external application could/would rely on such an event system for other use cases as well.