How to replace DjangoFSM with a database-driven workflow engine (BPMN or alternative)?

Title:
How to replace DjangoFSM with a database-driven workflow engine (BPMN or alternative)?

Body:

We currently implement business processes using Django models + DjangoFSM (finite state machine). Each process is hardcoded:

  • states and transitions are defined in model fields

  • transition logic is implemented in viewsets

  • every process change requires code changes and redeploy

This leads to several problems:

  • DjangoFSM is not compatible with Django 6

  • tight coupling to Django (we plan to move to FastAPI or another backend)

  • impossible to support multiple customers with different workflows without forking code

  • no runtime configurability of processes

What we want instead:

  • store process definitions in the database

  • allow admins to configure workflows without code changes

  • validate process schemas

  • keep execution logic in backend code

  • avoid heavy proprietary BPM systems (prefer open-source or embeddable solutions)

  • ideally decouple from Django entirely

We are considering moving from FSM to a BPM-style approach (possibly BPMN), but we are unsure about implementation strategy.

Question:

What are practical approaches to implement a database-driven, customizable workflow engine in Python backend systems?

More specifically:

  • Are there lightweight or headless open-source BPM/workflow engines suitable for embedding?

  • Is BPMN worth implementing for this use case, or are simpler models (e.g., state machines + metadata) more practical?

  • What are common architectural patterns for separating workflow definition from execution logic?

We are not looking for full enterprise BPMS solutions, but rather something embeddable or extensible.

Additional context:
Current stack: Django, PostgreSQL
Target: possibly FastAPI + decoupled workflow engine

As the author of django-fsm, I’ve seen many folks hit this exact limit. If you need runtime config and multi-tenancy without redeploys, you've outgrown hardcoded FSMs.

Here’s the path forward:

  • For a modern FSM: Switch to viewflow.fsm. It’s the direct successor to django-fsm, built to be cleaner and compatible with the latest Django versions.

  • For DB-driven workflows: Use the full Viewflow engine. It supports BPMN, allowing you to store and version process definitions in the database so you can support different customer flows without changing code.

Thank you, this is helpful advice.

We agree that we ve already reached the limits for "FSM in code": we need runtime process configuration and tenant-specific scenarios without releasing the application.

viewflow.fsm does seem like a natural replacement for django-fsm within the Django stack, and we re considering it as a possible intermediate step.

Our additional architectural goal is to reduce our dependence on Django in the long run (possibly switching to a headless service/different backend).

Вернуться на верх