SharePoint Online Workflow permformance

[Jason Sandholm]

I've had a lot of workflow problems in the SharePoint 2010 farm I was lucky to inherint at my current job. From not kicking off, to failing, so i'm trying to be workflow concious when migrating to SPO. 

One of my co-workers created a workflow that contains "Event: Wait for item in this list to Change", and it was looking at the current list. He did this instead of waiting for a field to equal a specific value, since that value could be multiple things.

So, it sounds to me like anytime anything happens, all the workflows on this step will hit this trigger and check if a field has changed. I've got some ideas of how to do this differently, but i'm just curious if anyone knows if this is even a big enough hit to performance to even care? 

[#2]

If you are asking about possible performance problems with SPO workflow, the answer is that you can have them...SPO workflows story rely on three possible approaches:
(1) Legacy workflows (same ones you can currently create in your SP 2010 environment)...you can experiment performance poblems if you reach workflow limits in your setup
(2) Workflow manager ones what means you are consuming workflows exposed as services and here you can also experiment performance problems
(3) Microsoft Flow, the latest technology Microsoft is working on to automate business processes.

[#3 · Accepted solution]

Hi Jason,

From my experience, SPO custom solutions and workflows are rather sensitive to performance issues.

It's better optimizing workflows as much as possible vs price tag of the stuff responsible for the WFs creation and maintenance.

It's very common to place all heavy logic out of the workflow. For instance, WF 2013 is completely declarative and deals with SharePoint via REST calls, SPD WF 2013 can be extended with another declarative custom actions, let's say black boxes with some complex proceeding but simple for a human input and output, if a workflow will be created with use of numerous custom activities at the end of the day the instance of the workflow can be dramatically slow.

That is one of the use cases when the logic should be placed into a web service for workflow only to trigger it passing input, then requesting with a timeout asking for completion and outputs.

Also, there are numerous cases when WF can be replaced or extended with:

• Web Jobs / Scheduled jobs - similar like to have a site workflow, but sometimes much more effective
• Remote events receivers (or ReR) - to trigger receiver code on a remote (to SPO) server on content changed or changing instantly
• Webhooks - similar to ReR, but universal, can deal with many different O365 objects, not instantaneous, it can be a 5 min interval delay in Webhook notification to subscribed web service

On facing issues with WFs performance the situation can be fixed by bringing some complexity to the architecture of the solution. For example, to use ReR for checking fields changes and then triggering the specific WF assigned to content type, etc. 

I would recommend trying usual for you approach first, but keeping in mind "architectural workarounds".

--

Best regards,

Andrew