Repeating Task Evidence

🧾 Repeating task evidence

An auditor asks: "Show me this check was done every month this year." For a repeating task, FreeITSM now answers on one page - every occurrence that should have happened, what happened to each, who did it, what the checklist recorded, and the gaps - and prints it or exports it.

Requested in #181; the design, with the decisions and the clarifications agreed on the issue, is Recurring task evidence - design. Developers: Repeating task evidence - Developer Guide.

History starts on the day this was added to your FreeITSM. Some things were never recorded before it - who completed an older task, a due date as it was before somebody moved it. The report says not recorded for those rather than guessing.

---

1. Every task keeps a history

The task window has a History tab: everything that happened to the task, newest first.

• who created it - a person, or the repeat (on schedule, after the previous one was completed, or late, as a catch-up)
• every status change; who completed it, and the due date at that moment; reopening
• due-date, start-date, assignee and team changes - a change made after the task was completed says so
• a skip and its reason; whether a next occurrence was due, and when
• checklists attached and removed, and every tick, untick, value and result on their steps - unticking no longer erases who ticked it

Nothing in it can be edited or deleted, and it stays on record after the task is deleted. It is kept for every task, not only repeating ones.

---

2. The evidence report

Open it from a repeating task (Repeats → Execution history) or from Tasks → Evidence, which lists every repeating task - including ones that have been stopped, and ones whose tasks have all been deleted.

Choose a period of scheduled dates (a year by default). The page shows the repeat's rule, a summary line, then one row per occurrence that should have happened:

Outcome	Means
On time	Completed on or before its original due date - and any date it had been moved to
On time after rescheduling	Completed after its original due date, but on or before the date it had been moved to at the time. Due the 1st, moved to the 8th, done on the 7th - this, never plain On time
Late	Completed after the due date in force at the time
Overdue / Open	Not completed yet - after, or before, its due date
Skipped	Closed on purpose, with the reason (section 3)
Missing	It should exist, and does not (below)
Not created yet	Due to be created today, and the repeating-tasks job has not run yet
Removed	Created, then deleted - its checklist results, exceptions and history are still shown
Not recorded	The history needed predates this feature

And flags beside the outcome, none of which can make work look on time:

Flag	Means
Rescheduled	Its due date was moved before it was completed
Due date changed after completion	Somebody edited the due date afterwards. The outcome is still judged by the date in force when it was completed
Created late	The scheduler made it after work on it should have started - it was catching up
Changed after completion	A checklist step changed once the task was done

"On time" is a calendar day in the install's time zone. A task completed at 00:30 on the 2nd in London was not completed on the 1st.

Missing

• On a fixed schedule, the report works out every date the rule produced - using the rule as it was at the time, and leaving out any period the repeat was stopped - and a date with no occurrence is Missing. Viewing or exporting the report never creates the task.
• After completion, the next occurrence only exists once the previous one is done, so the report never invents a row before then. But once a completion or a skip made the next one due, and it never appeared, that is Missing, with the date it should have been due.
• For a repeat that existed before this was added, missing dates are worked out only from that day - the rule's earlier history was not recorded, and the report says so.

Why it was missing or late

For a missing or late occurrence the report adds what the repeating-tasks job's run history shows for that time (see Background jobs):

• No recorded run of the repeating-tasks job between 2 and 9 March
• The repeating-tasks job failed on 3 March, with its message
• The job ran on 3 March but did not create it
• Created on 9 March by a catch-up run
• Run history not available for this period - before run history was kept, or older than it is kept

It says only what was recorded. "No recorded run" is not the same as "the job did not run", and the report never claims the second.

---

Due later than the day it is for (#190)

When a repeat makes each occurrence due later than the day it is for (the next working day, say), timeliness is judged against that due date - the one the occurrence was created with. A Saturday check due Monday and done Monday is on time, not on time after rescheduling. Each row also shows the period the occurrence checked. See The Work view.

Forms, procedures and follow-ups (#190)

Each occurrence's details list the forms it needed and their answers, the Knowledge procedures it followed (with the version whose text was kept - shown once under Procedures used), and its follow-ups with whether they are open. A form answer ticked as an Exception in the form designer is listed among the occurrence's exceptions.

3. Skipping an occurrence

When an occurrence should not happen - the server it checks was being replaced, say - open it and use Repeats → Skip, with the reason. It closes as skipped, not done, into the status chosen in Tasks → Settings → Evidence (Cancelled on a standard install). The report shows it as Skipped with the reason. A repeat set to repeat after completion makes its next occurrence, just as completing would.

---

4. Checklist results: Pass, Fail, Not applicable

A completed task should not imply the check it describes passed. A checklist step can ask for a result instead of a tick: in Checklists, open the procedure and switch on Ask for a result for the step.

On a task the step then shows Pass, Fail and Not applicable. Fail asks what went wrong before it is saved - the exception note. The task can still be completed with a failed step: the report lists it under Exceptions, so it cannot be hidden by the task being done. Steps that do not ask for a result keep their tick, and tickets always use the tick.

Procedures keep their versions. Saving a checklist procedure keeps the version before it, and every checklist on a task records the version it was given - so the report shows the procedure as it stood for that occurrence, and a later edit never rewrites an earlier one.

---

5. Printing and exporting

• Print opens the report ready for Print → Save as PDF, with the period, the time zone, who produced it and when on the page.
• Four CSV files that join on the task id: occurrences (one row per occurrence - outcome, flags, dates in UTC and local time), checklist results (one row per step), attachments and comments (one row per attachment - name, size and SHA-256 - comment, form submission, and linked ticket or change, by number), and form answers (one row per answer, for tasks that need forms - see Forms on tasks).

Every print and export is recorded at the bottom of the report: who, when, which file and which period.

---

6. Settings - Tasks → Settings → Evidence

Setting	Choices	Default
Changing a completed task's checklist	Allowed, and recorded · Refused until the task is reopened	Allowed, and recorded
Deleting an occurrence of a repeat	Allowed, and kept as Removed · Not allowed - skip it instead	Allowed, and kept as Removed
Status a skipped occurrence moves to	Any of your closed statuses	The last closed status in your order
Who can run the evidence report	Anyone who can see the repeating task · Only roles with Run the evidence report	Anyone

Each defaults to the forgiving choice, so upgrading changes nothing, and whichever you choose, nothing already recorded is lost - the stricter choices just stop the change happening at all. The tab itself needs the Configure repeating task evidence permission.

---

7. An Auditor role

Somebody who should read the record and export the evidence, and change nothing:

1. System → Analysts (or Teams) → Module access: give them Tasks at the Read only level.
2. If the report is restricted, a role holding Run the evidence report (System → Roles).

They can open every task their companies allow, read its history and the evidence report, print and export it - and every change is refused, on screen and through an API key acting as them. That includes attaching or removing documents.

---

8. Companies

On a multi-company install the report lists only occurrences in companies the viewer can see, and says how many it left out. A linked ticket or change is named by number only.

---

Related pages

• Repeating tasks · Tasks · Checklists & SOPs
• Background jobs - the run history the report reads
• Recurring task evidence - design (#181) · Repeating task evidence - Developer Guide
• Module access · Roles and permissions