Has anyone else noticed this issue and with this API workflows setup using more resources?

Questions
1

Some of you may have seen this and also be expereince an increase in resources when logically it should not.

I was trying to optimise my app to get rid of what appears to be a race condition.

Let me explain:

I set-up an API workflow on a list and originally I had all the actions in the one API workflow.

The first issue I found was that no matter what I did it appeared that the second list record that the work-flow was working on trips over the first in the list and fails to create a new thing, particularly when it has to first search to see if that thing exists - records after this all process correctly.

So the solution I tried was break up the API work-flow to multiple branches, what I mean by this is that if the thing exists then go to workflow A. and execute these processes, and if the thing does not exists then go to workflow B. and create the thing then execute this process. Logically by breaking up the workflow it should be more efficient, right?

BUT! It appears that it still trips over itself, especially when it creates a new thing, but more importantly not the CPU usage appears to be greater than having all the processes in the one work-flow!

I have noticed that those who have a branch method of working with API workflows have reported a large use of resources too.

So from what I can see it is advisable to throw everything into the one API workflow for a process rather than call child API workflows , but this does not make sense!

So I have noticed 2 issues here, 1. a situation when working on a list the second process trips over the first and no matter how efficient you are working more API workflows uses more resources, even when breaking a large workflow down into smaller ones.

Has anyone else experienced the same?

1 Like
2

There’s a post on here that talks about actions in an API workflow not being sequential – it seems they should be when they’re labeled “Step 1”, “Step 2”, “Step 3”. In reality, all steps could fire at the same time. The proposed solution is to add “Result of Step x” to the workflow that you want to fire next. Supposedly this will make the secondary action wait until the “result”. This may not work for all actions, but it may help with some.

3

Thanks @Kfawcett. Yeah, it’s always something you easily forget! You would think after a year I would remember this… just got reminded about this today in a coaching session with @romanmg so will see if I can arrange things to force the thing to obey my every command! I am also going to break the the structure down further to see if this helps, will report back once I have done this and tested the performance to see if it helps the CPU performance or does the opposite.