No problem ^^ It's not really a big deal. Thanks for the help
Just a question a little off topic, I'll have other question later I think, will it be in the same board ?
It will depend on your question But yes, I think that it will be on the same board.
But we will always try to answer your questions or help you even if it's not posted in the right place
Hey Sammy, welcome to the forums! The cause of this is more related to the how SharePoint works behind the scenes to start workflows within it's WF engine. Using a form, there is a trigger when an item updates that goes to detect if a workflow should begin. It is more of a synchronous order of events when using a form. When using quick edit on a list item, the order of events are more asynchronous, or without order, and batched to be updated behind the scenes. This gives you that edit ability without having to go from screen to screen, or form to form on each item. The details of those triggers will give the effect you are seeing, but both methods of edit are subject to other rules within the WF engine which could cause the reverse effect to be seen. SharePoint also caches workflows to improve starting performance.
So I just want to point out that nothing looks out of the ordinary from what you are experiencing. If your workflows begin to take even longer to begin, then there are other approaches that we can link to you blogs within the community to help.
I see, so it comes from directly SP Thanks for the reply, the wait time is fine for now But I'll think of your advice if one WF take a reaaaaaally long time
when starting to use nintex read through how the batches pickup the workflow actions. This will help you think for the long run
Though not directly related to your current issue read it nonetheless