views:

467

answers:

2

I’m about right a workflow in CRM that calls itself every day. This is a recursive workflow.

It will run on half a million entities each day and deactive the record if it was not been upodated in the past 3 days.

I’m worried about performance has anyone else done this.

+3  A: 

I haven't personally implemented anything like this, but that's 500,000 records that are floating around in the DB that the async service has to keep track of, which is going to tax your hardware. In addition, CRM keeps track of recursive workflow instances. I don't have the exact specs in front of me, but if a workflow calls itself a set number of times within a certain timeframe, CRM will kill the workflow.

Could you just write a console app that asks the Crm Service for records that haven't been updated in three days, and then deactivate them? Run it as a scheduled task once a day, and then your CRM system doesn't have the burden of keeping track of all those running workflow instances.

EDIT: Ah, I see now you might have been thinking of one workflow that runs on all the records as opposed to workflows running on each record. benjynito's advice makes sense if you go this route, although I still think a scheduled task would be more appropriate than using workflow.

Matt
By scheduled task I assume you mean something outside of CRM (Like real windows scheduled tasks / windows service)? Or is there something I'm not aware of in CRM?
benjynito
Also it should be pointed out I read it the way Matt mentions here (1 workflow for all, not a workflow per entity). Essentially its a target-less workflow, you just have to pick something to start it off of.
benjynito
Yes, just as a Windows Scheduled Task. Nothing inside CRM.
Matt
When you start writting code outside of crm the client can't manage it. it will become a problem
Chris Jones
I'd argue that as soon as you start trying to make CRM do things it wasn't designed for, that that's the problem.
Matt
+1  A: 

You'll want to make sure your workflow is running in non-peak hours. Assuming you have an on-premise installation you should be able to get away with that. If you're using a hosted instance, you might be worried about one organization running the workflow while another organization is using the system. Use the timeout and maybe a custom workflow activity, if necessary, to force the start time to a certain period.

I'm assuming you'll be as efficient as possible in figuring out which records to deactivate. (i.e. Query Expression would only bring back the records you'll be deactivating).

The built-in infinite loop-protection offered by CRM shouldn't kill your workflow instances. It stops after a call depth of 8, but it resets to 1 if no calls are made for an hour. So the fact that you're doing this once a day should make you OK on the recursive workflow front.

benjynito