Describe the problem/error/question
I have a worfklow A1
that calls another B1
, both with an error flow E1
, like so.
A1 -> B1
A1 -> E1
B1 -> E1
I’ve developed these in my local instance and then imported them to the cloud, where their id’s are now these.
A1 (1)
B1 (2)
E1 (3)
So if you look at the id’s only, they’re stitched together like this.
1 -> 2
1 -> 3
2 -> 3
Now, I have to support different concurrent versions of this. So, let’s say that in my local instance I develop a v2
of these. Now, because I’m just iterating locally, I just update the old ones, so the id’s remain the same, though the version is higher.
A2 (1)
B2 (2)
E2 (3)
Now, as I import them using the API, I want to get the same structure, but with the newer versions. Like this.
A2 -> B2
A2 -> E2
B2 -> E2
But when they’re imported to the cloud, their id’s automatically become the next three consecutive ones. So for example, like this:
A2 (4)
B2 (5)
E2 (6)
Now, the problem is that workflows call each other by id —not by name. So, each Call Workflow
node sort of keeps a pointer to the older version of it’s dependency, so ->(old)
. I need ->(new)
So, what I end up with after importing is this:
A2 ->(2) B1
A2 ->(3) E1
B2 ->(3) E1
Notice how:
- Workflow
A2
should call workflowB2
, notB1
. - Both
A2
andB2
should point to error workflowE2
, notE1
.
So, to summarise:
| I want this | But got this |
| 4 -> 5 | 4 -> 2 |
| 4 -> 6 | 4 -> 3 |
| 5 -> 6 | 5 -> 3 |
Of course, what I described here is just a simplified example to illustrate. The real use case is made up of 6 workflows. So I need to do this programmatically. Having to go in and correct all of this manually is prone to error and would eventually become unmanageable.
Is there a good N8N supported way to do this? or what would be N8N’s recommendation? How have others done it before?