I don't know if it can be done with the authoring tool or the console's "workflow" setup, but it can be done (I've done it). There are a couple ways..I'll first describe the way I've implemented it.
Set up a workflow that creates your incident from a template. This workflow could be powershell based or C# based..any method through which you can use the SDK to create an incident with a template.
This workflow will trigger when an incident, previously created by the workflow, has been closed or resolved.
How will the workflow know which incident has been previously created by itself? Give it a unique marker..for example, in the notes field of your incident's template you could put something like "recurring incident". Your workflow's trigger criteria,
then, would trigger on an incident that closes and whose notes field contains "recurring incident".
Basically, you'll create a self-recreating incident. When the engineer closes or resolves the incident, another one will generate right away. You can put a 7-day SLA on the incident so the engineers know that they should work on the incident within that
7 day period.
The other method is to, again, setup a workflow that runs on a timer. It simply executes every 7 days and does the same thing whether the previous incident is closed or not. The risk in that method is, of course, if your workflow engine goes down it may
not generate another incident until another 7 days has passed.
Finally, why are you generating recurring incidents? In the ITIL world, incidents are used to track unexpected issues, not routine tasks. I recommend you use a service request record instead, if you can.
-
Proposed as answer by
Andreas BaumgartenMVP, Moderator
Wednesday, April 29, 2015 4:42 AM