This post details a solution created for configuring workflows to run on a scheduled basis
The dynamics 365 component in the solution for configuring these recurring processes is a custom entity named Workflow Task. This can be scheduled to run continuously with a minimum duration of 10 minutes. That is they can be configured to run every X minutes, every X hours or every X days amongst other durations. They can also be configured to only run between certain hours of the day as well as to not run on weekends and public holidays
This table lists the different types of workflow tasks which can be created with some examples linked. Further examples will be added when time permits
| Type | Purpose |
| Target Per View Result | Runs workflows on records returned by a system view |
| View Notification | Email notifications when records are returned by a system view, listing the records returned by that system view |
| Target This Workflow Task | workflow which runs against the configuration record (generally calling a custom code activity) |
| View Has Results (Target This Workflow Task) | workflow which runs against the configuration record only when a system view returns any results(generally calling a custom code activity) |
Before finishing I will add these notes which need to be considered
- On rare occasions the workflow processes which implement this solution have failed for infrastructure related reasons. Monitoring processes which restart failed processes have been implemented into the solution and the stability has gradually improved to the point failures are now very rare. Nonetheless it is advised automated notifications or manual checks are done to ensure the solution processes are running. This is easily done by ensuring the workflow task execution and monitor times are all kept updated as future values
- It is possible to trigger custom code or integrations by creating custom workflow activities and adding them to target workflows
- The 2 minute time limit for sandboxed plugins needs to be considered for custom code scenarios. If your custom code is sandboxed ensure your logic is implemented to not exceed the 2 minute threshold or the workflow and its schedule will fail
If you have any questions about this solutions features feel free to post a question and I’ll try to provide an answer
JM SOFTWARE 
Hello Joseph,
your solution is great.
Is there any limit regarding the number of records over which the scheduled workflow can be performed?
For example if a view returns more than 10.000 target records will it work without problems?
Hi there
Currently the code will only process a maximum of 5000 records from a view per execution. This is because it uses one RetrieveMultiple message on the view definition, and RetrieveMultiple messages return that maximum number of records per call. This 5000 limit could be raised calling RetrieveMultiple more than once but it is not a feature/issue I currently have on my to do list
With online tenants it is also limited by how many Start Workflow messages it can get through in 115 seconds due to the 2 minute time limit of custom workflow code in isolated assemblies
Note I have never used this solution to process over 1 or 2 thousand workflows per execution, and depending on how complicated the logic is per record, I have noted this sometimes puts excessive load on the platform causing several of them to fail and/or timeout. The reliability of the platform in this regard does seem to be improving however and your mileage may vary depending on the logic being executed in the workflows
Generally, if there are a large number of workflows to run I will use a combination of the following approaches
1. Have the process run multiple times at early hours of the morning, processing only a portion of them each time. This requires building the view in such a way so those already processed no longer meet the views criteria. Note there is a newish feature to limit the hours the workflow runs between, for example you may configure a process to run every 10 minutes between 12:30AM and 3:30AM.
2. Process them all via code in a custom workflow activity. This is potentially quicker and less load on the system as only one workflow is triggered. Note the custom code may need an escape clause for the 2 minute time limit when running online, as well as need the above point factored in for multiple runs
3. Set a 1 or more second delay per workflow start so as not to load the system with too many at once
If you have any issues with the solution, or suggestions to improve it in this regards, feel free to raise an issue on GitHub, though I cannot guarantee an SLA on getting to work on it. You could also clone or fork the repository and do your desired changes if you wish
Hi Joseph,
I have the following situation: it is necessary to start the WF process every day, once or several times.
Since I need to map dynamically the value of the field from the targeted record within the fetch-xml query, in the ordinary filter inside the view I cannot set the condition like field a > field b.
So what I need then is just to call desired WF at defined time intervals every day.
The WF will query all necessary records end it will initiate another desired WF to run on every record that is retrieved by the query.
I noticed that there is Workflow Execution Type called Target This Workflow Task.
When I tried to set up scheduled running of desired WF I am getting this error: “The Target Workflow targets the entity type of new_recordline but was expected to target the type jmcg_workflowtask.”
Is it possible with your solution only to set up scheduled running of desired custom WF, without specifying target records?
Hi mm
If I have inferred all the details correctly, I am gathering you have a custom workflow activity doing all the querying and starting of workflows since you could not get a view/fetchxml to return the record set for running the workflow against
If this is correct I think you just need to recreate that workflow selecting Workflow Task as its target type. There needs to be a target record for every workflow, so essentially this means the workflow will be run against the Workflow Task configuration record, but will still run your custom workflow code and spawn the workflows against the correct type
The “Target This Workflow Task” option is effectively used to schedule a workflow which has no specific record context, and generally will just be running custom code which may operate on some other record type
The only time you would have a different target type for the workflow, would be if it is being run against multiple records returned by a view/fetchxml query as per the other workflow task types “Target Per View Result” & “Target Per Fetch Result”
Also note if you keep the assembly isolated there will be a 2 minute time limit on the custom code execution, so you will want to ensure somehow this is not breached
Also note where possible I sometimes used a field on records to signify the workflow needs to be run and use a view for the target records based on this field. This is sometimes a better option than using custom code, but may require you to add a workflow or plugin to set that field based on changes in the other fields which you cannot compare in your query
Hope this helps
Thanks for the answer Joseph.
The second approach is exactly what we have applied.
We created one additional field (flag) that helped us to set desired condition within the fetch-xml query. So we are now able to schedule running of desired WF based on returned target records, so we don’t need to worry about 2 minute time limit since WF will be run for each target record.
Thank you again for this solution.