Schedule recurring tickets, and manage your company-wide tags
Settings > Service Desk's Recurring Tickets and Tag Defaults pages.
What you will have
- See how a Recurring Tickets rule turns a schedule into a new ticket automatically.
- Confirm exactly when a rule fires, including the weekend and holiday skip.
- Pause a rule without losing it, and see what Delete actually warns about.
- Add a tag once on Tag Defaults and see it available to every client immediately.
- See why Tag Defaults only ever archives a tag, and what that does and does not affect.
Why it works this way
The Tags (optional) field on a Recurring Ticket only appears once a Client is picked, because tags are scoped to that client's own tag pool - the universal pool plus that client's own additive tags.
The Next Run column shows a dash while a rule is Paused, and recomputes the moment you Resume it - a paused rule never silently keeps a stale date.
Archiving a tag hides it from every picker's suggestions from that moment on, which is the point. But an entity that already carried the tag before the archive can lose track of its name too - its tag picker shows the raw tag id as an unresolved chip instead of the tag's name and color, rather than quietly keeping the old label. This never affects billing math or audit history, which both read a tag by its id regardless of its archived flag - only the picker's own display is affected.
Steps
Open Settings > Service Desk > Recurring Tickets and click New Recurring Ticket.
A recurring ticket is a rule that auto-creates one ticket on a calendar cadence - daily, weekly, every two weeks, monthly, quarterly, or yearly. Fill in a title, a problem description, a client and a schedule, and the portal generates a new ticket every cycle. Use it for repeating low-touch work like monthly patch reviews, quarterly DR tests, or weekly site checks.
Open Settings > Service Desk > Recurring Tickets and click New Recurring Ticket. Pick a Client for the rule.
The same form also takes a Title, a Problem / description, a Priority, an optional Board and an optional Assignee - all on the New Recurring Ticket screen, the same one this rule's own Edit view reopens.
Pick a Client for the rule. Pick a Cadence and a Start date.
Cadence sets the repeat interval. Start date anchors the very first occurrence - it does not have to be a day the business is open; the next step covers what happens when it isn't.
Pick a Cadence and a Start date. Read the schedule hint, then save the rule.
The page states its own timing rule in plain words: tickets fire at the start of the workday - the Business Hours Start time on Settings > Service Levels > Business Hours & Holidays, 08:00 by default - and weekends and holidays are skipped automatically, using the same open-day calendar the SLA clock and dispatch scheduling both read.
Read the schedule hint, then save the rule. See the rule's computed Next Run.
This rule's Start date, 09/20/2026, falls on a Sunday. Next Run reads Sep 21, 8:00 AM instead - the following Monday, at the business's own opening time - live proof that a non-business start date rolls forward rather than firing on a closed day.
See the rule's computed Next Run. Click Pause on the row.
The rule stays in the table but stops creating tickets. Its Status badge switches to Paused and Next Run shows a dash instead of a date, so there is never a stale date left showing for a rule that will not actually fire.
Click Pause on the row. Click Resume to start it again.
The rule goes back to Active and Next Run is recomputed from today against the rule's own cadence - the same business-hours-start, skip-closed-days logic as the original schedule.
Click Resume to start it again. Click the trash icon to see what Delete actually warns about, then Cancel.
The confirmation reads: "'KB walk - recurring example' will stop creating new tickets. Generated tickets stay." Deleting a rule is permanent for the rule itself, but any tickets it already generated are never removed along with it.
Note: This walkthrough clicked Cancel, not Delete - the rule was left in place the whole time.Click the trash icon to see what Delete actually warns about, then Cancel. Open Settings > Service Desk > Tag Defaults and add a new company-wide tag.
Type a name under Add a new company-wide tag, optionally pick a color and a category, and click Add tag. Every tag on this page has organizationId set to NULL under the hood, which is what makes it universal - visible to every client immediately, with no separate "push to clients" step.
Open Settings > Service Desk > Tag Defaults and add a new company-wide tag. Open a ticket-tag picker for any client and confirm the tag is already there.
Back on the Bluebird Dental rule from the earlier steps, opening its own Tags (optional) picker and searching turns up the brand-new tag right away, exactly as if it had always been there. Renaming or archiving it later on Tag Defaults applies everywhere the same way, immediately.
Open a ticket-tag picker for any client and confirm the tag is already there. Archive the tag instead of deleting it.
Tag Defaults has no Delete button anywhere - only Lock and Archive on every row. Archiving hides the tag from every picker's suggestions and drops it out of the page's own active count, but the row itself is never removed.
Archive the tag instead of deleting it. Reopen a rule that already carried the archived tag.
The chip that used to read KB walk - service desk example now reads (unknown cmu4um) - the picker can no longer look up the archived tag's name or color, so it falls back to showing a piece of its raw id instead of quietly keeping the old label.
Warning: An unresolved chip like this is not junk to remove out of habit - check Tag Defaults with its Archive/Restore buttons for a matching archived name before clicking the chip's own x. Restoring the tag there brings its name and color back on every entity that still carries it.Reopen a rule that already carried the archived tag. Know how a tag can drive a billing line, without needing a live example here.
A service plan can attach a billed line item that counts entities carrying one specific tag - for example, billing the count of devices tagged managed-workstation, multiplied by a unit price. Each invoice cycle counts whichever entities carry that tag at that moment: a universal tag counts across every client on the plan, while a client's own additive tag scopes the count to that one client.
Other ways to do this
Workflows
Build a multi-step Workflow template and push it by hand with Apply Template, or fire it automatically from an Automation.
If it did not work
- If a change on Recurring Tickets or Tag Defaults will not save, confirm the account has edit access to Settings - a view-only account can read every field on these pages but not save changes.
- If the Tags (optional) field will not appear on a Recurring Ticket, pick a Client first - tags are scoped to that client's own tag pool, and the field stays hidden until a client is chosen.
Questions this page answers
What is a recurring ticket?
A rule that auto-creates one ticket on a calendar cadence (daily, weekly, monthly, etc.). Fill in the title + problem + client + schedule, and the portal generates a new ticket each cycle. Use it for repeating low-touch work like monthly patch reviews, quarterly DR tests, or weekly site checks.
How is this different from a Workflow?
Workflows are multi-step project templates (a tree of tickets) pushed manually via Apply Template or fired by an Automation. Recurring tickets are single tickets on a cadence - different concept, different UI. If you need a 12-step onboarding project to fire quarterly, use an Automation that wraps a Workflow.
When do recurring tickets fire?
At the start of the workday - specifically, the Business Hours Start time in Settings → Service Levels → Business Hours & Holidays (default 08:00). Weekends and holidays are skipped automatically using the same calendar that drives SLA business-hours math.
How do I pause a rule without losing it?
Click Pause on the row. The rule stays in the table but stops creating tickets. Click Resume to start it again at the next cadence. Deleting a rule is permanent - generated tickets stay but the rule is gone.
Was this helpful?