A support lead asks for one thing: "Can we send a CSAT survey the moment a ticket gets resolved?" The obvious answer is to open Jira Automation, add a rule — when issue transitions to Resolved, send an email with a survey link — and call it done. Except now someone needs project admin access to build it, it lives buried in a rule list next to a dozen unrelated triggers, and if a second team wants the same thing on their project, someone has to rebuild it from scratch there too.
That's the default path most JSM teams take, because Jira Automation is the tool everyone already knows. But timing a feedback request isn't really an automation problem — it's a survey configuration problem that's been routed through the wrong tool because there wasn't an obvious alternative.
The Real Problem: Survey Timing Shouldn't Live in Automation
Jira Automation rules are built for issue workflow logic: change a status, assign a field, notify a watcher. They're not aware of anything survey-specific — no concept of "don't ask this customer again if they just responded last week," no built-in distinction between a request that's resolved versus one that's actually closed, no way to scope a timing rule to a specific feedback instrument without wiring an email or webhook action by hand.
That mismatch shows up as real friction:
It's gated behind admin access. Automation rules sit in Project Settings. A support lead who wants to adjust when a survey goes out — say, only on weekdays, or only after a request has been closed rather than merely resolved — can't make that change themselves. They have to find whoever owns the rule and ask.
It doesn't travel with the survey. An automation rule is tied to the project it was built in. If the same feedback timing logic needs to apply to a request-level survey, a project-wide portal survey, and a publicly embedded widget, that's three separate things to configure and keep in sync, in three different places, none of which know about each other.
It mixes concerns. A project's automation rule list is already handling ticket routing, SLA notifications, and status transitions. Adding "also fire a CSAT email" to that list means feedback timing logic competes for attention with everything else the team relies on automation for — and a broken survey trigger is easy to miss in a rule list built for ticket workflow, not feedback delivery.
The Fix: Collection Rules, Configured on the Survey Itself
Every Myra Feedback Survey has its own Collection Rules — a rule set that lives on the survey, in the survey's Settings tab, and controls exactly when and under what conditions that survey is allowed to ask for feedback. No automation rule builder, no admin ticket to file with another team.
The available rule types cover the timing scenarios that actually come up:
- Last Resolved — the direct answer to "trigger a survey when a ticket is resolved." This times the request around a request's resolution, without anyone writing a status-transition rule to make it happen.
- Request Closed — for teams who'd rather ask after a request is fully closed, not just marked resolved.
- Date Range and Day of Week — for boxing collection into a specific window, like a launch period or business days only.
- Last Submission — avoids re-surveying someone who already responded recently.
- Reporter Only — restricts collection to the person who raised the request, rather than anyone participating on the ticket.
- Always Allow — a catch-all with no conditions, applied by default to every new survey.
To configure them, open the survey's Settings tab, toggle Enable Collection on, then use Add Rule to pick a rule type, give it a name (rule names can't be changed later, so it's worth getting right the first time), and optionally a description so the next person who looks at it understands why it's there. Each rule can be switched on or off independently, so a team can pause a condition — say, during a support-volume spike — without deleting the setup they'll want back later.
One thing worth knowing before relying on this: if Enable Collection is on but every rule is either deleted or turned off, the survey simply won't appear to customers. There's no error, it just stays silent — so if a survey seems to have stopped collecting, checking for at least one active rule is the first thing to look at.
Rule availability also depends on the survey's scope. Request-scoped surveys, which are tied to an individual ticket's lifecycle, support the full set including Last Resolved and Request Closed. Project- and Public-scoped surveys — which aren't attached to a single request's lifecycle — don't support Request Closed or Reporter Only, since neither concept applies once a survey is decoupled from one specific ticket. Worth checking the compatibility before assuming a rule you liked on one survey will carry over to another scope.
Teams that just want the resolution-triggered case working immediately don't have to configure anything at all: Myra's built-in CSAT survey ships with two predefined Collection Rules already in place, specifically so feedback gets requested at the right moment out of the box.
The Takeaway
Before the next request for "ask for feedback when X happens" turns into a new Jira Automation rule, check whether it's actually a Collection Rule sitting on the survey itself — Last Resolved and Request Closed cover the two most common resolution-based triggers without touching a rule builder or requiring project admin access. Save Jira Automation for what it's actually for: issue workflow. Let the survey own its own timing.