Authorization: granting user group read access to historic process instance


certain user groups that were involved in a process should be able to read the variables of this specific instance after the process has ended and became a historic process.
I tried the following lines to achieve that:

            var authHistory = authService.createNewAuthorization(AUTH_TYPE_GRANT);
            var permsHistory = new Permissions[]{Permissions.READ};

It throws an exception: ENGINE-03087 The resource type with id:‘20’ is not valid for ‘READ’ permission.

I also tried
var permsHistory = new Permissions[]{Permissions.READ_HISTORY};
but this gives a similar error that resource type is not compatible with permission READ_HISTORY.

According to the authorization service documentation (if I got it right), the READ-Permission can be used with Historic Process Instance (cf: auth service doc

Can someone help me to set the permissions correctly?

Setting the read permissions for the running process instance gave no error, I do not understand the difference:

            var authProcess = authService.createNewAuthorization(AUTH_TYPE_GRANT);
            var permsRead = new Permissions[]{Permissions.READ};

Hi @Dierk,

The ability to read the history related to a specific instance is disabled by default.

This can be enabled using below property of the process engine configuration


You can find more details in below link

1 Like

Hello Hassang,

Thank you for the explanation.
@engine developers: Maybe the Error Message in the exception should mention this detail


I tried the suggested approach but it does not work. I have the following in my application.yaml:

        generalResourceWhitelistPattern: "[a-zA-Z0-9\\.@]+|camunda-admin"
        enableHistoricInstancePermissions: true

However, it still throws an exception: ENGINE-03087 The resource type with id:‘20’ is not valid for ‘READ’ permission.

I have also created a new process instance to test it, but the error remains the same.

Hi @Dierk,

Try with below property name

Thanks for the hint, but the error message remains the same, I tried to assign Permissions.READ_HISTORY and Permissions.READ because I am not sure which combination is corect.

Hi @Dierk,

What version are you using?

I am using Camunda 7.15. with Spring Boot 2.5.4

Hi @Dierk,

7.15 should be okay…

Please make sure that content of your yaml file is valid and the file is located in the correct place.

I did not find an obvious error in the application.yaml file, but because I do not understand the syntax of the generic properties (how does propertyName enableHistoricInstancePermissions map to enable-historic-instance-permissions), I changed the engine configuration from config files to programmatic configuration:

public class MyProcessEngineConfiguration extends AbstractCamundaConfiguration implements CamundaProcessEngineConfiguration {

    public void preInit(SpringProcessEngineConfiguration configuration) {

Now the property setEnableHistoricInstancePermissions ist set for sure, I also checked with the debugger that the above code is executed. However, the error message does not change. Therefore I assume that somehow the following lines are not correct:

            var permsHistory = new Permissions[]{Permissions.READ_HISTORY};

Error message stays the same: ENGINE-03087 The resource type with id:‘20’ is not valid for ‘READ_HISTORY’ permission.’

Try Read permission

I tried, but the error is: ENGINE-03087 The resource type with id:‘20’ is not valid for ‘READ’ permission.’

Update: the flag EnableHistoricInstancePermissions is enabled for sure, I checked via postInit-Method and the debugger. Therefore something else with my code must be wrong. Does someone have an idea how to grant read permission to historic process instances?

I did not mention that I am using the community version of camunda. Does one need the enterprise edition to set permissions on historic process instances?

The solution could not be simpler, but sometimes easy solutions are hard to find:


For historic process instances Permissions.READ can be selected via the admin gui:


But it is always mapped to the ALL permission.

1 Like

Hi @Dierk,

Thanks for sharing the solution.