I like this, but mostly for allowing multiple rules to fire on NEW ticket.
Just my thoughts on this:
I see what you are saying, but I think the set up of having both rules is the way to do it. You really do have 2 scenarios. In #1 the ticket gets hot... and at that point you want to know. That's a perfect job for Observer. in #2 the ticket comes in hot, which dispatcher will catch and fire off to you as a watcher. I don't believe they are doing the exact same thing though. Dispatch'r is very much like a logic gate matching external data to a truth table and internalizing it. Observer is monitoring internalized data for changes and making adjustments. To me its logical.
No-one pulls a truck into a warehouse and puts stuff on the shelf somewhere and has people just spot check all day for accuracy. It comes into a loading dock, gets received, staged, and then warehoused. Once its warehoused. It can be picked and moved by internal people at the warehouse.
We definitely don't have an option to run more than one Dispatch'r rule. The help text at the side of the page even says so:
"Remember, the order of the Dispatch’r rules are important. For each incoming ticket, Dispatch'r will execute the first matching rule and stop. You can reorder the list of rules to have the most important rules on top."
We came to FS from Freshdesk and didn't have that option either, interesting...
David Zarnitzky
OK folks, hear me out on this one.
There are currently two types of automation tools based on Ticket settings -- Dispatch'r and Observer. The only two major differences between the two being:
1) Multiple Executions:
I've already posted a Feature Request about item #1 -- requesting that Dispatch'r should have the ability to execute multiple rules, just like Observer can.
But it's item #2 that is the real stinker. Take the following use-case.
I want any ticket where priorty=urgent to add me as a Watcher. Simple enough, right?
But where do a put this rule? In Dispatch'r or in Observer?
Well, let's say there's a scenario #1 -- where an end-user sends an email -- which automatically creates a ticket in FreshService. An Agent picks up the ticket, reads it, recognizes it as "Urgent" and changes the priority to "Urgent".
... versus scenario #2 -- where an end-user calls the Agent, and the Agent creates the ticket and sets the priority as Urgent from the get-go.
Well if the rule I want is put into Dispatch'r, it'll catch scenario #2 but miss scenario #1. And if I put it in Observer, it'll catch scenario #1, but miss scenario #2. So I have to create the rule in BOTH places -- which is just silly.
And it's silly because Dispatch'r and Observer are doing EXACTLY the same thing, with the except being ACT UPON CREATION vs ACT UPON UPDATE.
I can't think of a SINGLE reason why Observer couldn't be changed to ACT UPON CREATION or UPDATE, and take over the roll of both automation tools.
Would love others' thoughts on this.
7 people like this idea