SharePoint - When to Timerjob rather than Workflow

When to use an timer job rather than a Workflow

Timer jobs can be used instead of so called "system" workflow ( that automate processes  that interact with the content and data stored in SharePoint). The major differences between timer job and system workflow:
 - Timer jobs can be activated and managed by farm administrators only;
 - End users can't control execution;

So rule of thumb: If the end users do not need to control the process, then choose timer jobs; otherwise, choose system workflow




  • Does any user interaction occur?
  • Will the process run for a long time (more than a second or two)?
  • Will the process need to pause to wait for another process to complete a task?
  • Will the process be run many times (more than 25 or 30) concurrently?

If the answer is "Yes" for any of these questions, you should build a workflow; if "No" for all, consider an event receiver. There are certainly some exceptions, but in general these rules apply. (Workflow Scalability and Performance in Windows SharePoint Services 3.0)


Also see - How to create custom TimerJob programmatically
http://www.codeproject.com/Tips/634208/Create-and-Deploy-Custom-Timer-Job-Definition-in-S

Comments

Popular posts from this blog

Run Powershell script on Remote Computer/Server

Power BI Refresh Issue: unable to convert the value '' from the source data type 'VT_BSTR' to the expected data type 'VT_I8.

SPDActivities - DP.SharePoint.Workflow - Workflow failed to run