"We use Jira automation" tells you nothing. Here is a real layer of one hundred and thirty-three rules for a digital agency, grouped by what they are for, with names stripped and the shape kept.
Of 133 rules, 70 were live. The other 63 are the warning: automation accretes exactly like the manual work it replaced.
Every team says it uses automation. What matters is what the rules actually do, and whether they add up to a system or a pile. What follows is the layer as it stood when I documented it, exported and grouped by purpose. Names, project keys, and clients are stripped; the shape is the point.
Seven families of rule
Project scaffolding. The largest family by effort, if not by count. A manual trigger on a template ticket creates an epic and fans out its child tickets: a website build-out generates a five-phase checklist (onboarding and audit, discovery and site planning, content, design, technical build); a new client contract generates an onboarding epic covering operations, branding, marketing, and hosting; advertising work generates a full-iteration or half-iteration set. A paired rule then walks the children and swaps in the right checklist for each. Twenty-eight tickets from one click, correctly shaped, every time.
Scheduled recurring work. Seventy-two rules run on a schedule against a JQL query. Monthly and quarterly deliverables are generated from the client roster (find every account with the reporting component, create this month's ticket, set the due date to the last Monday of the month). Weekly team syncs are created by group. Holiday tickets are created four weeks ahead. Sprints are created nine weeks out. Contract renewals get an email at ninety, sixty, and thirty days. Twelve-month engagements are moved to review when they age out.
QA gates and hygiene. Every new ticket gets a "ready for QA" checklist attached on creation. Transitioning to QA adds two days to the due date so the reviewer has room. Reopening a ticket resets its checklist. Closed tickets are resolved and unassigned. Linked issues mentioned in comments are linked automatically. Original-estimate changes and timeline changes are counted so leadership can see churn.
Slack notification. Overdue tickets, tickets sitting in QA past twenty-four hours, mentions in comments, new support issues, reopened issues: each pings the right person in Slack. This family is small in count and large in effect, because it is what makes the rest of the system visible without anyone opening the board.
Intake. PTO requests and client support requests arrive by form and become tickets, assigned and due-dated, with a Slack notification. Leads uploaded on a schedule become assigned tickets with a due date the following week.
Maintenance and content. Maintenance tickets generated and dropped into the sprint. Monthly newsletter cloned from a template on the first of the month. Weekly social response tickets. Community training content on a cadence.
People and coverage. One-on-ones created by group. PTO tickets. Holiday coverage. The unglamorous family, and the one people notice most when it fails.
What sits around the rules
Jira Automation runs out of headroom in two places: anything that needs to look across many issues at once, and anything that needs to talk to a person on a schedule with computed content. Both moved to a ScriptRunner layer. The daily stand-up job sends each person a Slack message at eight in the morning with their blocked, in-progress, overdue, and due-today tickets, formatted so it can be pasted straight into stand-up, and it skips anyone with nothing open. A dependency validator checks that a ticket has a sprint, an assignee, and a due date, comments naming who last edited the missing field, and rate-limits itself so it does not spam. Time-tracking changes notify the reporter.
Outside Jira entirely, nine Google Apps Script projects do the connecting: forms to tickets, calendars to tickets, meeting transcripts to ticket comments, ticket health monitoring, the weekly utilisation report, and the subscription cost tracker. Two of them replaced paid Make.com scenarios.
The number that matters is not 133
Of the one hundred and thirty-three rules in the export, seventy were enabled. The other sixty-three were experiments, copies made to test a change, and superseded versions nobody had deleted. That ratio is normal and it is a warning: automation accretes exactly the way the manual work it replaced did. The fix was an inventory document, one line per rule saying what it does and what triggers it, a naming convention that puts the family first, and a quarterly pass to disable anything that no longer earns its slot.
How to tell whether yours is a system
Three tests. Can a new team member read the rule list and understand what happens on the first of the month without asking anyone? Does every rule have a name that says what it does rather than what it was cloned from? And if you disabled the whole layer for a week, would work stop being created, or would nobody notice? If the answer to the last one is "nobody would notice", you have a pile.