Observer enables you to automate certain actions on your helpdesk when events that you specify are triggered in a ticket in real-time. This helps you modify statuses, change priorities and even send out notifications as and when conditions are fulfilled. For example, when a customer replies to a ticket that’s already been resolved, you could set up a rule that makes the Observer automatically change the ticket’s status to “Open”. You could have another rule that sends an email to your Support Team head the minute someone submits an unsatisfied rating in your customer satisfaction survey. This helps you save time, and agents don’t need to keep an eye on tickets all the time.

Unlike the Dispatch'r (which acts on newly created tickets) and the Supervisor (which runs once every hour and checks all tickets in the helpdesk against its rules), the Observer is a trigger-based automation that constantly watches all activities in your helpdesk and matches them against the conditions you specified. Also the Dispatch'r comes into play at the time of creating a new ticket whereas the Observer comes into play when you need any actions to be taken on existing tickets based on a trigger.

The Observer has four distinct sections:

  • The event occurrence, which specifies what event triggers the rule.
  • Whom the event is performed by - whether it is a requester, or agent, or either. 
  • The conditions that you set for the tickets.
  • The action that the rule is supposed to perform when the condition is triggered.

Observer rules are processed sequentially in the order you have set them up, but a rule may trigger an action which in turn triggers subsequent rules.

As and when you add Observer rules, you can find them listed in your Observer page. You can choose to have them running or not by toggling the on/off switch. If you want multiple similar rules, you can click on the Clone button to create a clone of your existing rule and modify them accordingly. You can also choose to Edit your existing rules.

Quick guide for creating an Observer rule

  • Go to Admin > Helpdesk Productivity > Observer
  • Click on New Rule.
  • Give your rule a name and a description in the text boxes.
  • Choose an event occurrence that you want to act as your trigger by using the drop down menu under “When Any of these events occur”.
  • You can add multiple events by clicking on Add new event for every new event occurrence you need.
  • Next you will need to select whom the events have to be performed by under “and the events are performed by”, whether it is an agent or a requester, or if it can be either. You can add particular names if you want to select specific agents.
  • Under “on tickets with these properties”, you can add one or more conditions, along with whether all of them have to be matched or if any of them is enough.
  • Under “perform these actions”, you can select whichever actions you want similar to the conditions menu. You can choose to add multiple actions by pressing the + button.
  • Click on Save once you’re done.
Remember that you can click on the - button to delete any condition/action you might have accidentally created. You can also click and hold the icon next to the - button to reorder the conditions/actions you’ve created.
In this example, we will be automatically assigning tickets to the first person who responds to it.
  • Go to Admin > Helpdesk Productivity > Observer
  • Click on New Rule.
  • Give your rule a name and a description in the text boxes.
  • Choose an event occurrence that you want to act as your trigger by using the drop down menu under “When Any of these events occur”.
  • Here, we select “Reply is sent” as the first event, and “Note is added” with Type “Public” as the second event. So, if any agent replies or adds a note to a ticket, it will get assigned to him.
  • Next you will need to select whom the events have to be performed by under “and the events are performed by”. Click on Agent.
  • Under “on tickets with these properties”, select Agent, Is, None in the three drop down menus respectively. This ensures that only tickets which aren’t already assigned to any agent come under this rule.
  • Under “perform these actions”, select Assign to Agent, and Event Performing Agent in the respective drop down menus.
  • Click on Save once you’re done.


  • The conditional elements are not case sensitive. If you’re setting up a rule that searches for the word “refund”, it will be activated regardless of whether you use “refund”, “Refund” or “REFUND”.
  • You can specify only one keyword in one condition. If you’re setting up a rule that searches for “refund” or “payment”, you will have to create two conditions and each one can check only for one keyword. Depending on whether you want both keywords to be found, or any one, you should click on the corresponding Match condition on top of the rules.
  • If you're setting up a rule which acts on tickets whose subject/description contains "refund", tickets with the words "refunded" in their subject/description will also match the rule. Similarly, a rule which is supposed to act on tickets whose subject/description contains "want refund" will also act on tickets whose subject/description has "want refund now". However, tickets whose subject/description contain "refund" will not be acted on by this second rule.

Using Webhooks in Observer

A Webhook is a “callback” to an application or web service that is triggered when a specific event occurs. What that means is a webhook lets you look for a specific update, change or action to occur and automatically pushes the information you specify to the place you want.

The Observer is a trigger-based automation that gets fired when a specific event occurs on a ticket. Using just the Observer, you can update, modify, send notifications and run actions within Freshdesk. For example, you could update ticket priorities, send out escalation emails, etc.

Webhooks also come handy when you want to trigger an action in an external application or tool (as well as some updates that the Observer can't perform, like update time entry on a ticket or add a note to a ticket). Here are some example scenarios when you might want to use Webhooks:

For example, if you have a third party tool to send out text messages via phone, you can setup a webhook which responds to whatever Observer rules you set, and instead of performing an action by the Observer directly to a ticket, you can set up the helpdesk to call back the text messaging tool.

Quick guide to setup a webhook request with the Observer

  • Create a new Observer rule and select the Triggers and Conditions (learn how).
  • Under actions, select the Trigger Webhook option from the drop down.
  • Choose the Callback Request Type. While each 3rd party app may use a request type in a different way, most applications follow standard methods:
  • GET Requests are typically used to retrieve one or all resources.
  • POST Requests usually create new resources.
  • PUT and PATCH Requests are used to update a resource.
  • DELETE Requests are usually used to delete a resource.
  • If you want to set up a rule to add a note to a ticket based on certain conditions and triggers, it's POST because you're adding a note (How did I know that?).
  • Specify the callback URL (configured for webhook) of the application you want to hit. You can make the URLs dynamic using placeholders.
  • For example, to add the note to a ticket, you'd have to specify WHAT ticket you want the note to be added to. Your callback URL would be:[:ticket ID]/conversations/note.json with the placeholder {{}} instead of "ticket ID".
  • Pick the encoding of your request that the resource application supports (JSON, XML or XML- Encoded). For the note addition example, it's JSON.
  • To simply send a list of ticket properties that you want in this webhook, select the Simple content option. Adding a note doesn't require any of the usual ticket properties so you'll have to write a custom API request.
  • If you would like to customize the content that is being sent, select Advanced.
  • The advanced option lets you write custom API requests. These requests have to be encoded
  • in the format you chose in the previous step. For our note addition example, this is what the API request would look like: {"helpdesk_note": {"body":"Hi {{}}, we're looking into this. Sit tight.","private": false} }
  • If you'd like to add a private note, put 'private: true' in the request. You can also customize the content in your API requests by making them dynamic using placeholders. If you'd like to do more with the Freshdesk API than just add a note, a multitude of options are available.
  • You can use or postman - REST client (a google chrome extension) for testing out APIs.
  • The {{Triggered event}} placeholder is available only in Webhooks, and returns the name of the event that triggered the rule.

Webhook Callback Request Limits

The number of webhook requests you can use in 1 hour is limited to 1000 calls. If the status codes are between 200 and 299, the callback is a success and status codes between 300-399 will be taken as callback redirects. When a callback fails (status codes other than 2xx and 3xx), the webhook will automatically be retried once every 30 minutes, totaling 48 calls. Calls requested after the rate limit will be buffered until fresh calls are available after 1 hour.