Freshdesk Scenario Automations

A Freshdesk scenario automation is a bundle of ticket actions an agent fires with one click. The closest thing Freshdesk has to a macro, and badly underused.

Start free trial All guides

What a Freshdesk scenario automation is

Take everything an agent does when they handle a particular type of ticket. Set the priority. Change the group. Add two tags. Drop in a reply. Set the status. Now put all of that behind one button.

That's a scenario automation. It's agent triggered, which is the defining characteristic. Nothing happens until a human looks at a ticket, decides this is that kind of ticket, and runs it.

Compare that to the two other automation shapes in Freshdesk. Dispatcher-style rules fire on ticket creation. Time-triggered and event-triggered automations fire on their own schedule or on a change. Scenarios fire because a person said so.

They're also the thing people confuse with canned responses, and the difference is simple. A canned response inserts text. A scenario changes the ticket.

Building one that earns its place

The shape of a good scenario is a real, repeated, multi-step workflow. Not a shortcut for one field change.

Pick a ticket type you handle at least a few times a week and write down every action you take. Then build the scenario with those actions in the same order. Name it after what the agent is trying to do, not after the fields it touches. "Refund request to finance" is a name people will find. "Set group 4 priority 2" is not.

Where scenario automations live in the admin area, and exactly which actions they can perform, has shifted between releases. Check the current Freshworks docs for the menu path rather than following a screenshot from three years ago.

Two design notes worth having. Keep each scenario to one job, because a scenario that does two things gets used for the one thing and pollutes the other. And be careful about including a reply, since a scenario that sends a message the moment it's clicked is a scenario someone will fire by accident.

The three that pay for themselves immediately

If you build nothing else, build these.

The escalation. Change group to engineering, raise priority, add the escalated tag, set status to pending, add an internal note template asking for reproduction steps. Six actions, one click, and consistency you can report on.

The spam or non-issue close. Tag, set status, remove from the SLA-relevant view. Agents do this dozens of times a day and each one is three clicks that add up.

The waiting-on-customer. Set the status that stops your response clock, tag it, and send the standard chase. This one directly improves the honesty of your response time reporting, which is worth more than the time it saves.

Notice what they have in common. All three are decisions a human makes, followed by actions a machine should perform. That's the sweet spot.

Scenario or supervisor rule

The genuinely useful question, and it comes down to one thing: can a rule reliably tell?

Use an automatic rule when the condition is unambiguous in the data. Subject contains an exact phrase. Ticket came from a specific email address. Priority is urgent and nobody has touched it for two hours. Rules are excellent at facts.

Use a scenario when the trigger is judgement. This customer is angry. This is actually a bug rather than a question. This refund is legitimate. No rule reads tone or context, and every team that has tried to automate a judgement call has ended up with escalation rules firing on the word "urgent" in a polite sentence.

The pattern that works best is both together. A rule does the mechanical triage on arrival, and a scenario handles the judgement step once a human has read the thing.

There's also a volume angle. Rules run on everything and misfire quietly at scale. A scenario misfires on one ticket, visibly, and an agent notices. That makes scenarios the safer place to put anything with a consequence attached.

Keeping the list usable

Scenario lists rot. Someone builds one for a product launch, the launch ends, the scenario stays.

Review the list every six months and delete anything nobody has run. If your plan gives you reporting on scenario usage, use it. If not, ask the team which three they actually use, and treat everything else as a candidate for removal.

Ten well-named scenarios that everyone uses beat forty that nobody can find. This is the same principle as canned responses, and it fails the same way.

FAQ

Frequently asked questions

Can a scenario run on several tickets at once?

Yes. Freshdesk bulk actions let you apply a scenario automation across a selection in the ticket list, which is how a morning's triage gets done in one pass.

What is a scenario automation in Freshdesk?

A bundle of ticket actions an agent runs manually with one click. It can change fields, move the ticket between groups, add tags, set status and insert a reply, all in a single step.

How is a scenario different from a canned response?

A canned response only inserts text into a reply. A scenario changes the ticket itself, updating properties, status and assignment, and can include a reply as one of its actions.

When should I use a rule instead of a scenario?

Use a rule when the condition is a fact the system can read, such as a sender address or a priority and an elapsed time. Use a scenario when the trigger requires human judgement.

Can scenario automations run on several tickets at once?

Applying a scenario across a selection of tickets is a common workflow, though the specifics vary by plan and release. Check the current Freshworks docs for how bulk application behaves in your account.

Who can create scenario automations?

Creation is an administrative action rather than a normal agent one, so it depends on the role you hold. Agents run them, admins build them, in most sensible configurations.