Forum Discussion
SharePoint Online Workflow permformance
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
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