Does anyone know if there is a maximum number of workflows that can be executing at the same time? I see in the limits that there is a limit for how many can be executed in 1 minute and 1 hour, but I don't see how many can be active at once.
I'm assuming that you're referring to workflows executed via Triggers? If so, the workflows themselves aren't limited for concurrency, and are only gated by the volume limits documented for triggers.
That said, a huge number of concurrent workflows could cause a (relatively minor) delay in the processing of the workflow.
Thanks Richard. Actually, I am looking at creating a Dialer process that will be calling a data action which will execute a workflow. So, there is the potential for high-number of concurrent workflows.
Makes sense that there might be a delay if a high volume of them are running. Thanks!
On that same note - Is there a maximum time that a workflow can be in a processing state, without fully executing? I know that there is a a limit of 72 hours for a inbound flow (email, chat, etc) to be executing before it takes a failure path or continues processing. I was wondering if there is a similar limit on the workflow type. Do you know?
Can you help me understand the entity.interactions.per.hour? Does that mean if we set up a trigger on user events.. and if we have 100 users that each take a call in 20 minutes, the triggers won't work for the next 40 minutes, because we've reached the threshold?
If so, that makes process automation quite limited, doesn't it?
the entity.interactions.per.hour limit is the number of times a trigger can act on messages regarding a single entity ID. Using a trigger with the topic of v2.detail.events.conversation.{id}.attributes as an example, the entity ID would be the conversation ID. This means that triggers would only be able to initiate 100 separate workflows based on that conversation within an hour; this limit is especially necessary in order to prevent runaway loops based on a single conversation (using the example topic above, a foreseeable configuration mistake would be to create a trigger that runs any time there is any attribute change to a conversation, with the workflow modifying an attribute on the conversation; this would create a runaway loop acting on the conversation repeatedly until this entity ID limit kicks in to break the cycle).
Thanks Richard, how does this apply to a user entity for example? Is each user considered an entity? Or, is each event for a single user considered an entity?
Just trying to understand how this applies to things such as the user.end event.
For a topic: v2.detail.events.conversation.{id}.whatever
the {id} would be the entity. So the per hour limit of 100 would apply to a specific conversation in the above example. Each conversation is its own entity.
The entity limit is designed to prevent recursive loops operating on the same object repeatedly, generating unbounded load on the platform, as I pointed out in my previous comment.