New (3.5+) workflow configuration

Last modified 01 Feb 2022 19:38 +01:00
This functionality is obsolete. It is no longer supported or maintained.

Starting in midPoint 3.5, configuration of workflows is done like this:

  1. "Static configuration", e.g. Activiti database URL, is stored in midPoint config file (config.xml).

  2. Other parts of configuration are stored in System Configuration repository object.

  3. Finally, some information about required approvals is attached to individual objects (e.g. roles being assigned):

    1. directly (in a "legacy way"),

    2. using policy rules:

      1. attached directly or via metaroles,

      2. defined globally in System Configuration repository object.

MidPoint configuration file

You can specify some configuration properties in the static midPoint configuration file. An example:

    <enabled>true</enabled>    <!-- optional (if omitted, default is true) -->
    <!-- optional (if omitted, default is either the same database as for repository, or - in case of embedded H2 - separate file in the same directory) -->

Items that can be configured are:

Item Description


If false, workflows are disabled. Use this if you don’t use approvals in your deployment. Do not use this to temporarily turn off approving new requests - in such situation disable the workflow model hook instead (see below).

jdbcUrl, jdbcDriver, jdbcUsername, jdbcPassword

Parameters for connecting to workflow (i.e. Activiti) database. By default, workflows use the same database connection parameters as midPoint repository. However, it is possible to specify different db connection properties for them, if necessary.


Whether to perform automatic update of Activiti database schema, e.g. when upgrading midPoint. Default: the same as for repository configuration (it is true if hibernateHbm2ddl is set to "update").


MidPoint automatically deploys new versions of BPMN processes at startup. Here you can specify the location from which the deploy is done. Default: classpath*:processes/*.bpmn20.xml.

System configuration object

The configuration object primarily lists change processors that are to be used and their configuration. A change processor is a module that intercepts a change event coming from midPoint core (model) and determines whether workflows have to deal with such an event.

Currently, there are two change processors available:

  1. Primary change processor: it is used to approve a request (or requests) before execution. It is able to provide approvals in standard situations with almost no configuration nor coding.

  2. General change processor: provides the greatest flexibility for midPoint engineer, however, at the cost of more complex configuring (one could say "programming") and testing. It allows calling arbitrary BPMN process in any phase of model operation execution. Please note that this change processor is still quite experimental.

More information on change processors is in the architectural description of workflow module.

The configuration looks like this:

    <modelHookEnabled>true</modelHookEnabled>		<!-- this is the default -->
    <processCheckInterval>10</processCheckInterval> <!-- this is the default -->
      <enabled>true</enabled>						<!-- this is the default -->

Items that can be configured are:

Item Description Default value


Tells whether workflow model hook is active (the default) or not. If the hook is not active, all requests simply bypass workflow processing, so they are executed without any approvals. (This can be obviously dangerous from the security perspective, so be careful.)



This property is applicable to "dumb" wf processes, which require active shadowing tasks that repeatedly query their state. It sets the process instance check interval (in seconds).



How to deal with legacy approvers specifications, i.e. approvalRef, approvalExpression, approvalSchema, automaticallyApproved items in roles, orgs, and services ?The options are:

  • never: The legacy approvers specification is never used.

  • always: The legacy approvers specification is always used. It is used before any other (policy-based) approval actions.

  • ifNoExplicitApprovalPolicyAction: The legacy approvers specification is used if there’s no explicit approval policy applicable to a given target. (This is the default setting.)



Whether to use default approval policy rules.These default rules are: use users with the approver relation to approve any assignments of a given role/org/service. Use users with the owner relation to approve any modification of a given focal object.The options are:

  • never: Default approval policy rules are never used.

  • ifNoApprovalPolicyAction: Default approval policy rules are used if there are no applicable approval policy actions. (This is the default setting.)


primaryChangeProcessor, generalChangeProcessor

Configuration of these two change processors.

Primary change processor configuration

Primary change processor traditionally contained a set of so called change aspects. Each aspect takes care of approvals of a single kind of elementary modification, like "assign a role R to a user U". So, by listing change aspects in the configuration, you specified what kinds of changes were to be approved by workflows.

However, in midPoint 3.5 we have introduced policy-based approvals. These are no longer configured by specifying list of aspects and their parameters. Nevertheless, legacy aspects are still present in midPoint (at least in version 3.5). All of them are disabled by default, but can be enabled if needed.

If needed, policy-based approvals can be disabled by setting enabled to false for policyRuleBasedAspect. You might be in such a situation e.g. if there would be some issue with this new mechanism and you’d like to stay with original (although obsolete) code.

Concluding notes

  1. If you fail to correctly set up your approvals (i.e. change processors, aspects, policies) then changes will be executed WITHOUT requiring the approvals. That might present a major security problem.

  2. Each change can be processed by only one aspect. So beware, if you enable both "legacy" aspects and new policy-based one. The policy-based one is evaluated first; but nevertheless keep in mind the potential for conflicts.

  3. Some policies can interfere - like assignment policy for a given role and modification policy for a given user.

Was this page helpful?
Thanks for your feedback