4

I knew that workflows were deleted every ~60 days, but I didn't know tasks were ever automatically deleted. My customers rely heavily on this information being available at all times. Is it possible to allow the workflow items to be deleted while preventing the tasks from being deleted? There isn't a visible retention policy on the tasks list that we can turn off or anything like that which I can see in the UI.

edit: After doing more research on this, it looks like tasks that have been completed more than 60 days ago are deleted. I tried updating the modified dates to make them appear as if they were only completed recently, but it seems it doesn't use that date in this determination.

However, I have noticed that if I create a NEW task on the Task list itself without a workflow or if I make a copy of a task created by a workflow, the task is created without a WorkflowInstanceID value (it is null instead of a guid). Can anyone please confirm that an item without a workflow instance ID will not be deleted? I can't change the timing of 60 days, and I can't wait 60 days to know if this solution will work.

|improve this question
  • You mean workflow history deleted every ~60 days? – Venkat Konjeti Jun 23 '17 at 20:09
  • Yes, but I don't care about the workflow history. I care about the tasks that are being deleted because they're associated with the workflow history. – Dinerdo Jun 23 '17 at 21:02
  • I don`t think Workflow Tasks will be deleted. – Venkat Konjeti Jun 23 '17 at 22:02
  • I'm not asking. I'm telling you they are being deleted. – Dinerdo Jun 26 '17 at 14:54
2
+25

As you've discovered, there is a timer job that runs which deletes "workflow instances and related task entries that still exist 60 days after a workflow is completed or cancelled." This quote is from Microsoft's doc that explains how to disable that timer job, if desired. (of course, these steps would only apply if you're using SharePoint on-prem. You can't disable any timer jobs in SharePoint online).

Though, since you said it's critical, another solution is to write to a separate list as part of the workflow to create a more permanent history. After all, disabling the timer job would apply to all workflows, and you may not need to keep history on every single workflow task. Also, disabling the timer job is something that would potentially complicate upgrades, as the same configuration would have to be made in future SharePoint farms, where as a custom list wouldn't cause similar configuration challenges.

|improve this answer
  • I'm aware of this, but I dont think you answered the question I placed a bounty for. I don't have the ability to disable the timer job, and that's not what I asked for. I want to know if tasks without WorkflowInstanceID values are guaranteed to be free of deletion..or if I can update some othet field like changing "Completed" to "Complete" (or vixe versa) to guarantee the task will not be deleted. Also, I believe workflow amd task lists that go to their own lists are still targeted for deletion from what I saw. All I want is to retain the current tasks or the ability to clone them via workflow – Dinerdo Jun 30 '17 at 22:31
  • I apologize for the typos. I have big hands and a little phone – Dinerdo Jun 30 '17 at 22:36
  • Let's say you somehow manipulated the task so that it wasn't deleted by the job. Is there any way to know if the next version of SharePoint will work exactly the same, or would this strategy cause migration issues? Also, any future SP admin would be confused by this sort of non-standard solution, and so it would carry the risk of causing issues in the future. If you cloned the task, people searching for items of content type task would find two of each task, causing problems. I'll stick with my original answer: stop the timer job or write entries to a custom list. – Mike2500 Jun 30 '17 at 23:31
  • You're all over the place with this one. Microsoft has repeatedly stated that there are no new versions of SharePoint coming that will not be in the cloud. So.. stopping the timer job would not be an option then either. We show the tasks in a filtered view based on a custom task list field. When cloning the task, I would expect to immediately delete the original. I'm not concerned about the implications of what I've asked. I just want answers to the questions I asked. I can deal with the ramifications, if any. – Dinerdo Jul 1 '17 at 2:18
  • MS will be updating 2016 with new functionality. While it is very unlikely that they'd change this piece, I generally follow the advice not to take advantage of undocumented functionality like this, even if it works,as it's confusing for other administrators. But your solution comes down to creating a custom list item, which is the common strategy that I previously mentioned that is used to get around the fact that workflow tasks are deleted.... – Mike2500 Jul 1 '17 at 10:41
2

If you want a concrete answer as to whether items without the GUID will be deleted or not you either need to test it youself, or ask Microsoft directly. I don't think the community can give you the required authority on the answer unless someone has conclusive test data of having done the same thing.

Why not just modify your workflow so it creates a copy of the item you need to retain in another list (that isn't a Workflow History list), and therefore won't be affected by the timer job?

|improve this answer
  • Also a pertinent question might be why can't you change the time period of the timer job, or just have it turned off for the specific area (maybe not viable as AFAIK it's done on web app basis). If it's so important, even if you don't have access to modify the settings surely you can provide a suitable justification for whoever does hold the levers of power to change it? – Thomas Gass Jul 6 '17 at 12:05
  • This site is already in production with thousands of existing tasks. In a future deployment, we will scrap the task list. We just need a quick prod fix. There are filtered web parts relying on this tasks list all over the place. That is why I said I cannot wait 60 days to find out. I have already "tested" it out, but I won't have the results back for another 2 months. I'm not a farm admin, and our farm admins can turn the timer job off for our site (which is where we're leaning), but it's getting very political and going up to people I don't exactly want recognition from at the moment. – Dinerdo Jul 6 '17 at 14:50
  • We have a local MS rep, but he is not available at the moment so that's why I posted the question out here hoping someone else had already come across an answer either from MS directly, examining the code in the timer job to see exactly what is being keyed/referenced, or otherwise. I know it was a shot in the dark, but desperate times.. – Dinerdo Jul 6 '17 at 14:52
  • I feel you. It's hard to find a direct answer from MS as to how stuff works sometimes without an outright Premier ticket saying 'here pal, tell us how this works'. – Thomas Gass Jul 7 '17 at 8:00
  • 1
    Also a curse on workplace politics and egoism standing in the way of producing a working solution. – Thomas Gass Jul 7 '17 at 8:00
1

I'm using SharePoint Online. It allows me to add a retention policy for the workflow task. The navigation path is:

List settings > Information management policy settings > Content type policies

Hope this helps.

|improve this answer
  • This would only help if I was trying to delete tasks quicker than 60 days. The retention policy won't override the timer job. – Dinerdo Jul 5 '17 at 15:19
1

Well did you ever solve this Dinerdo? The answer I am presuming is NO - you cannot fool the task. This is because the Task is associated to the WF Instance ID, which has the date/time fields etc. Changing anything on the task does not get it to "fool" the timer job cleanup. You cannot fix the timer job cleanup or fool it. It will cleanup what it wants when it wants (unless you disable it, which is no good for your farm). I challenge you to prove this wrong on a dev farm. I don't think you could. But again I have not tried, it is just from what I know about how the workflows and WF History and Tasks all relate, I can imagine the code MSFT wrote to "cleanup" the job. This being said, it is a HORRIBLE solution by MSFT not to give us options to configure it or disable it on a per workflow, or per list/library, or per subsite basis. You have to design another solution - So what I have done for clients is to copy the tasks list (and WF History List) into a custom list(s) on another site for example and provide them a link to that site. That allowed them to pass the failed audit and avoid audit penalties. It wasn't a pretty solution but it worked. I simply wrote a powershell script to run once every 30 days and copy any WF History and/or Tasks lists items that they needed to preserve. I scheduled that powershell to fire off using the NT Scheduler or Task Scheduler in Windows Server 2012.

|improve this answer
  • Hi @thesharepointguru No, I didn't get a solution to this. I see your note about tasks being associated by WF Instance ID", but that goes against my research and the last question I tried to have answered in regards to items without a value in that field. Thanks for your explanation. We ended up deflecting to Microsoft as the users seemed okay with the information coming from Microsoft (rather than us just being incompetent) especially because it was technically retrievable via the audit logs we generate on a monthly basis. – Dinerdo Jun 8 '18 at 22:40
  • cont: When the next project started and we actually had time to develop a new solution, I just eliminated the task list altogether and created my own approval buttons. Here's the question I was hoping someone would be able to answer when I ran into this issue back then: " I have noticed that if I create a NEW task on the Task list itself without a workflow or if I make a copy of a task created by a workflow, the task is created without a WorkflowInstanceID value (it is null instead of a guid). Can anyone please confirm that an item without a workflow instance ID will not be deleted?" – Dinerdo Jun 8 '18 at 22:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.