Overview of execution listeners

Deprecated Java Core API v1 listeners will not be available in the next major release. Use Java Workflow API v2 listeners where available or script tasks to replace the functionality of v1 listeners. See Alternatives to API v1 listeners for examples.

• FlushExecutionListener: This listener exists for a pure technical reason. When everything is executed in one transaction, data is not always flushed to the database in between. For example if you create assets in a workflow and right after that you want to add some relations, this will not work. The newly created assets are detected by the workflow logic and adding the relations fails, unless you add this execution listener in between. For more information about transaction boundaries in a workflow please refer to the Flowable documentation and search for Transactions and Concurrency.
• AuthCacheEvictExecutionListener: This listener clears the authorization cache of the current user and flushes all changes made during the current session. Clearing the cache can be useful when the authorization cache needs to be updated immediately, even before the transaction is committed. Typically, the cache is updated only after the transaction is committed. For example, you can have a script task assign a user to a group with the necessary permissions to participate in the workflow and immediately assign the same user to the next task. Without this listener, the user does not have the appropriate permissions to be assigned to a task until the transaction is committed. With the listener, the cache that stores the user permissions is refreshed prior to assigning the task. An alternative approach is to make the script asynchronous, but this prevents the user task from being opened automatically.
• SendEscalationEventExecutionListener: Listener that triggers an escalation event. By default the escalation process is listening to these events to start it's execution. You can use this listener to trigger a escalation event yourself. It needs two input parameters:

  Field name	Expressions	Mandatory	Description
  taskId	N	Y	The ID of the task the escalation is for.
  escalationType	N	N	The type of the escalation. This variable is used in the escalation process to determine which kind of escalation to execute. The default is mail so this is a optional parameter.

• SetMembersExecutionListener: A listener to easily set members on the current workflow business item. It has three input fields:

  Field name	Expressions	Mandatory	Description
  userNames	Y	Y	A CSV of usernames you want to set a member for.
  roleName	Y	Y	The name of the role. You can only specify one role to use at once.
  clearExisting	N	Y	If true all existing members on the current business item will be deleted prior to adding new. If empty no clearing is performed.

• SetActivityStreamListener: A listener capable of setting the filter which will be used to generate a activity stream. This listener is both a execution listener and a task listener. The filter it generates will be put in a local variable. This means, in the case of a usertask, the variable will only exist as long as the task exists. Outside of a user task, the variable will exist for the current execution only, meaning it will not be visible in super or sub process instances. You can decide for yourself if you want it to be used as a tasklistener or execution listener on user tasks.
  When the listener has been used, a user will be able to see a activity stream on the task bar. Also, when action mails are send, the configured activity stream can be included in the action mails for the current user task. There are a lot of configuration options which we will discuss next. Here is the list of all input fields. None of them are mandatory and if no input is provided, all changes since the start of the workflow on the current resource are listed.

  Field name	Expressions	Mandatory	Description
  user	Y	N	Limits to only show activities for the user with the given user name. Needs to be a username.
  role	Y	N	Filter only the changes where the user, specified in the user parameter has a given role in. If no user is given, only the changes are returned performed by users having the given role.
  involvedUser	Y	N	Only show activities where the given user is involved in/has a role in.
  involvedRole	Y	N	Filter only the changes where the user, specified in the involvedUser parameters, has a given role in.
  startTimeEmpty	N	N	This will override the default: the start time is the beginning of the current workflow, meaning all activities since the beginning of time will be shown.
  startTask	N	N	The task ID of the task to take as start timestamp to show activities for.
  startOnStatusChangeFrom	N	N	Fill in the signifier of the status here if you want all activities to show since the latest status change from the given status.
  endTask	N	N	Sets the end timestamp to the given task ID.
  resourceTypes	N	N	Filter on the types to return the changes for. If empty or null, all resource types are taken into account.