Evaluating n8n for very long workflows

I’m looking for a tool that could be the foundation of a document workflow system in a legal setting. It would involve workflows that have long times between steps, as they would be waiting for replies and documents from various institutions, so nodes in the likes of “if there’s no reply for 30 days, then do X” would be quite common.

From what I’ve read so far, n8n seems to be more focused on automatic execution and scalability. Do you think it could also be a good fit for slower processes, when some of the steps involve waiting for humans instead of waiting for code and 3rd party services?

Having a workflow wait for such a long time might result in performance/timeout issues. I’d solve this by assigning a status to each document and save that status globally. You can then check this regularly by scheduling a workflow on a daily basis and perform tasks based on the status value.

This could be done with either n8n Variables or, when there are multiple stages with a complex data structure, a tool I developed called AnyState.

1 Like


My aim is to have a diagram of all the states a document is going through, so it’s easy to see its entire workflow. I guess with n8n I’d have to have multiple separate diagrams for state transitions, which would be sub-optimal in my case. It’s sad - because n8n looks really cool.

It seems I’ll have to cook a little something from scratch myself :cook:

1 Like

Hi @kuba-orlik , there’s no issue with deploying n8n workflows for “slower processes”.

The only caveat is that you need to also involve a backend/data store (Airtable/Directus/Baserow etc.).

And given the usual nature and complexities of “slower processes”, you might want to have a dedicated Backend/Datastore handle all that instead of trying to manage all that in an automation tool like n8n.

1 Like

Just for completeness, I thought it might be helpful to explain how our “Wait” node works:

  • For short waits (I believe 60 sec or less), the execution persists in memory and executes directly after the wait is over.
  • For “long” waits (over 60 sec), the execution data up to that point is saved in the database and scheduled to spin back up and resume executing in a future date. So it was designed precisely to be able to pause/ wait an execution for days/ months/ years.

The important thing here would to just have sound database management (backups etc) but that would be the case to run n8n or any tool in a reliable manner.

If you havn’t used the node before - it can wait a fixed amount of time but also resume the execution when a webhook is received. So might be helpful for usecases where the wait time is unknown at pause start; and “continue execution” is sent in event-based way from a different system.


That sounds lovely! So in fact n8n might be good for my use case. Thanks a lot! :heart:

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.