Workflow Linting / Validation: Common Rules

Related to the work in Bpmn Workflow Linter / Validator API

I wanted to get the communities insights and feedback on the following working draft list of “linting” / validation rules for workflows/BPMNs.

The purpose is to collect a common set of rules that we struggle with at various times, in effort to create a common set of implemented and configurable rules that improve modeling for developers and analysts.

Please share any insights, rules, ideas, problems, etc that you have faced, fixed, or still struggle with!!

  1. Timer Limits: Minimum allowed, Longest allowed, etc
  2. Ensure the Executable is checked on pools/processes
  3. Extension Rules: Extension Rule that Targets a Element Type and has requirement on extension content
  4. Gateways have descriptions
  5. Sequence Flows that come out of a Gateway must have a description
  6. Start and End Events must have a description
  7. Only 1 Blank Start Event is allowed
  8. Limits on Call Activity: What processes can be called, and what input/outputs are expected: more likely to be valuable for outputs related to the specific process being called.
  9. Multi-Instance Loop Limits
  10. Async Before/After on a USer Task is likely a error, as a User Task is already async
  11. Elements with duplicate sequence flows going to same element
  12. Data Elements without a Name/Title
  13. Comment Annotations without a description
  14. Embedded Sub Process that does not have a title
  15. Message Flow from pool to pool that does not have a description
  16. Message Flow that does not have a description
  17. Boundary Event that does not have a Title
  18. Time Events with bad configuration or missing configuration
  19. Pool without a name value
  20. Tasks without a Name value
  21. Multi-Instance only allowed to be used on specific task types
  22. Async After on a End Event is likely not needed
  23. Certain types of Elements that are unreachable: No inbound or outbound flows: not all elements are bad when this occurs. But some types would: Tasks, Annotations, Sequence flows, intermediate and end events, etc.
  24. Warnings of a certain code that are listing of all Expressions: Providing a list of Expressions for easier review: “Show me all of the expressions in the workflow”
  25. Field Injection Rules for specific types of Java Classes
  26. Inputs Rules for specific types of Java Classes
  27. Limits of Listener Types: What types should and should not be allowed: “We do not want to support Expressions or script types”
  28. Script Language Control: “We only support Javascript as a language”
  29. Service Task / Send Task / Send Message Implementation Rules: Only specific types of implementations are supported: “Connectors are not allowed”
  30. HTTP-Connector Helpers to ensure proper fields and values are provided
  31. External Task Topic Limits: Only allow specific topic values
  32. Warning about Expressions not being supported on certain fields: Example: Form Key on a Start Event does not support a Expression
  33. Warnings about Listeners on Annotations: Data Store and Data Object
  34. User Task Priority Limits
  35. External Task Priority Limits
  36. Complex Gateway Warning: that it does not do anything…
  37. Script Compiler: Ensure script compiles
  38. Task IDs have the right name convention given their task type
  39. Expression Compiler
  40. Proper Message and Signal Setup
  41. BPMN Error Code Allowances
  42. Fake Joins: Checking for multiple incoming sequence flows
  43. Subprocess requiring a start event
  44. DMN limits
  45. Process Version Pattern allowance
  46. History Time to Live Pattern
  47. Candidate Starter Groups and User Rules
  48. User Task Rules
  49. Process ID/Process Key Naming rules.
  50. Event Based Gateway looping warning: Warning about race events and other common issues when you loop a event gateway
  51. Too many nested embedded sub-processes
  52. Multi-Task on Tasks that dont make much sense: Such as a Manual Task.
  53. Loop Characteristic Warning: Note that it does not actually do anything
  54. Tasks with a single sequence flow, and that sequence flow has a condition on it.
  55. Missing End events at end of scope/path
  56. Pool Lanes without name/text
  57. Use of Form Key or Use of Form Fields on User Tasks depending on allowed configuration pattern.
  58. Reserved Variable Names
  59. Only use Delegate Expressions when building for a Spring App (or else the DI wont work in the delegates)
  60. Call Activity and Business Rule Controls on Bindings, and Tenant ID,
  61. Call Activity control on the Business Key expression: Ensuring that the business key will always be the expected value being submitted to child processes.
  62. Link events must have a title/name
  63. Unreachable Compensations

This is a great idea Stephen, i’m going to give it some thought - but first i want to say:

I very much like this rule :slight_smile:


@StephenOTT it will be great work and will be useful for everyone. I was already using a bpmn linter, but it validates for few properties.

Few rules need to be additionally covered like,

  • Validation rule for processid if it’s not provided.

  • And validations for missing delegates/expressions/scripts/delegate expressions on service task/send task/script task, etc.

  • Extension properties without keys or duplicate keys

  • Process or element documentation should not allow empty string.

<bpmn:process id="" isExecutable="true">
    <bpmn:documentation>        </bpmn:documentation>
    <bpmn:startEvent id="StartEvent_1" name="Start">
1 Like

Hi folks,
I am learning BPMN and I’m using the Camunda Modeler with the linter plugin. I have a workflow with one pool and two lanes. The linter throws a warning: lanes should be avoided. May I ask why that is? What are the considerations behind that rule?

Hi @kimskovhusandersen,

this rule is for automated processes where the majority of tasks are service tasks. For this scenario, lanes are blowing up the layout.

It’s a completly different story if you have a user driven process where you have mostly user tasks. Here I would just disable the rule.

Hope this helps, Ingo


Hi BPMN comrades!

In my company it is the BA’s who draw the process models using camunda modeler. We have been looking for a plugin that guarantees the quality and maintainability of our models for several months now.
Since a few days we have been using camunda modeler linter plugin but it does not fully meet our expectations. We’d like to create our own rules, disable or edit some of the plugin core but we’re not developers so it’s very complicated for us. We tried to install the custom linter rules plugin but it doesn’t work ( the error message is not very useful in the Plugins tab of the modeler : Linter - Custom Rules ).
In our case we are stuck and are not able to deliver top quality processes.

Is it planned in the short term to have a rule-based and easily editable validation tool directly in the modeler that will comply with common rules like Stephen mentionned?

In the meantime, if someone can help me with the custom linter rules plugin to make it work it would be great :slight_smile:

1 Like