Recurring Tickets
Some work is not a problem somebody reports. It is the inspection every Monday, the meter read on the first of the month, the filter change each quarter. A recurring ticket is a schedule that files one of those tickets for you, so the job reaches whoever works it without anybody remembering to type it in.
Issues is the one feature every community has, so nothing needs switching on. Creating and keeping schedules is a community admin power, and only that: staff in a work group, delegated permission holders and residents never see the repeat section or the Recurring tab, and the API refuses them even if they go looking. The tickets a schedule files look like any other ticket.
A community admin can do this in the communities they administer. A schedule belongs to one community.
Creating one
Issues > Report Issue, then tick Repeat this ticket on a schedule. The
form you already filled in becomes the template, and the repeat section asks
how often:
| Field | What it means |
|---|---|
| Repeats | Daily, weekly or monthly |
| Every N | Every other week is weekly with 2. Quarterly is monthly with 3 |
| On | The weekday, for a weekly schedule |
| Day of month | For a monthly schedule. A month too short for the day you picked files on its last day instead, so the 31st becomes the 28th in February |
| At | The local time of day. Tickets are filed within the hour |
| Starts | The first ticket is filed on this date, not today |
| Ends | Optional. Leave it blank and the schedule keeps going |
Saving creates the schedule and files nothing yet. The form tells you the
cadence in words before you save, so Every other Tuesday at 8:00 AM is
something you confirm rather than something you discover a fortnight later.
Photos are not part of a schedule. Each ticket it files is a new one, and a photo belongs to the problem somebody actually found.
What a filed ticket looks like
Exactly like one filed by hand:
- Its own ticket number, from the same per-community sequence.
- The reporter the schedule carries. That is you, or the resident you filed on behalf of when you created it.
- Routed by its issue type, so the default group picks it up with no triage. This is the part worth getting right before you schedule anything: a recurring ticket with no owner is a recurring ticket nobody works.
- Open status, comments, photos and linking all behave normally.
The ticket records which schedule filed it, so the work can be told apart from a report that came in off the street.
Keeping them
The Recurring tab on Issues, beside Active and Closed, lists every
schedule the community has, next one due first. The tab is drawn for admins
only, and shows how many schedules there are. Each row shows the cadence, when
the next ticket arrives, and how many it has filed. The count links to the most
recent one.
| Action | What it does |
|---|---|
| Pause | Files nothing until you resume. The schedule and its history stay. This is the reversible one |
| Resume | Starts again from now, so a long pause does not fire a stale ticket the moment it comes back |
| Edit | Changes the ticket template or the cadence. Saving moves the next ticket |
| Cancel | Stops the schedule for good and takes it off the list. The tickets it already filed are untouched |
Cancelling asks first, and says what it costs. If you only want it to stop for a season, pause it instead.
A schedule that reaches its end date files its last ticket and shows as Finished. It is kept so you can see what it did, and it files nothing further.
What happens when something goes wrong
A schedule that was missed while something was broken files one ticket when the job next runs, not one per missed occurrence. Catching up on a month of Mondays would bury the crew that has to work them.
If a run cannot file a ticket at all, the reason is shown on the schedule's row on its row in the Recurring tab. That is the place to look when a ticket you expected did not arrive.
Times are local to the community. A schedule set for 8:00 stays at 8:00 across a daylight saving change rather than drifting by an hour.