Restricting DELETE_HISTORY permission


in the application that I am building, the user that created a process also needs to be able to delete the historic process instances. When I tried to figure out the permissions that would be needed for that, I found:

ENGINE-REST-HTTP403 org.camunda.bpm.engine.AuthorizationException: The user with id ‘some-user’ does not have ‘DELETE_HISTORY’ permission on resource ‘some-process-definition’ of type ‘ProcessDefinition’.

It thus seems that the DELETE_HISTORY permission relates to the process definition rather than to individual process instances. Does anyone know the rationale for that? This makes things difficult in my case as I seem to grant unconditional history deletion rights to all users if I want them to be able to delete the history for process instances that they have created.

Any thoughts would be appreciated.

Thank you,

Hello @hanshuebner,

This privilege indeed relates to the process-definition. It can be configured in Admin, there you can grant privileges to users / groups per process-definition.
Please have a look here: Authorization Service |
The authorization needs to be enabled:
Authorization Service |

Best, McAlm

Hi @McAlm,

thank you for replying. I understand that the DELETE_HISTORY privilege relates to the process definition, which is my problem exactly. I would like to be able to allow users to delete only specific history items which relate to the processes that they’ve started themselves. With the current privilege scheme, this seems not to be possible.


Ok, understood. This is not possible with the current authorizations, but you can easily provide your own REST endpoint that first checks it that instance has been created by the current user. Alternatively you can first get the history of the process-instance and check it the startedUser equals the current user.

As my application currently uses the ReST API only, it does not add any benefit from a security perspective if a check is made before the deletion is attempted. A new API endpoint is an option, although I would like to avoid adding application specific endpoints that perform engine operations. I will probably live with the security problem until I find the time to investigate if and how the engine permission system can be fixed.