How to Send Freshdesk Urgent-Ticket Alerts to a Shared Room

To send one selected Freshdesk urgent-ticket event to a shared group of phones, create a Ticket Creation automation for one group and urgent priority, POST a minimal body to an authenticated relay, and have that relay send fixed copy to a PingRoom incoming webhook. Keep Freshdesk as the ticket record and use one stable key per created ticket so a retry does not become another Ping.

This is a webhook recipe, not a native Freshdesk integration. The destination Room's owner needs PingRoom Pro. You also need access to Freshdesk automation actions and a server-side relay with durable duplicate storage.

Start with Freshdesk's own mobile notifications

Freshdesk's mobile app can already send ticket-update push notifications to agents. If everyone who needs the alert is an appropriate Freshdesk agent, configure those mobile notification categories first.

PingRoom should carry the attention signal, not the support record. This recipe never copies the requester, subject, description, comment, email address, organization, ticket URL, or other case detail into the Room.

Choose one event, group, and message

Use one narrow creation rule: a new ticket already belongs to one selected group and already has Urgent priority. Do not send every update or try to infer urgency in the relay.

The Room receives fixed copy:

Freshdesk urgent ticket created

One selected urgent support ticket needs attention in Freshdesk.

That is intentionally smaller than the ticket. It tells the group where to look without putting customer information on a lock screen. It does not assign the ticket, identify its owner, prove that anyone responded, or say an SLA was met.

Create the private Room and the relay

Create a private Room for the stable group that needs this signal. In the PingRoom browser app, open Settings → Connections → From another app, add an incoming webhook, and store the complete secret URL as PINGROOM_WEBHOOK_URL in your relay's secret store.

The incoming-webhook walkthrough covers the Room-side setup. The webhook reference documents the current request fields, idempotency, cooldown, and error behavior.

Freshdesk points to the relay, not directly to PingRoom. The relay gives you a place to authenticate the source, accept only the expected rule marker, discard ticket data, and queue one stable signal.

Store these values server-side:

• FRESHDESK_SOURCE_TOKEN: a high-entropy secret used only for this route;
• FRESHDESK_EVENT_MARKER: urgent_ticket_created;
• FRESHDESK_ROUTE_MARKER: a fixed private label such as support_primary;
• PINGROOM_WEBHOOK_URL: the complete secret PingRoom incoming-webhook URL.

Freshdesk's current webhook guide says the action can add custom headers. It does not document a signature for this automation body, so this recipe uses a separate shared secret in X-PingRoom-Source-Token. Treat that token and the PingRoom URL as credentials. Rotate either one if it leaks.

Build the Freshdesk Ticket Creation rule

In Freshdesk, open Admin → Workflows → Automations → Ticket Creation and create a new rule. Freshdesk's Ticket Creation guide explains rule order, conditions, actions, testing, and the Show Activities view.

Set all of these conditions:

1. The ticket's group is the one team this Room supports.
2. The ticket's priority is Urgent.

Add Trigger Webhook as the action. Use POST, your relay's HTTPS URL, and JSON. Add this custom header:

X-PingRoom-Source-Token: <your dedicated source token>

Use this body, selecting Freshdesk's Ticket ID placeholder in the editor if your account inserts placeholders through the UI:

{
  "event": "urgent_ticket_created",
  "route": "support_primary",
  "ticket_id": "{{ticket.id}}"
}

The event and route are fixed text. Only the numeric ticket identity varies, and the relay uses it solely to recognize a retry. The relay never forwards it to the Room.

Freshdesk's current webhook automation guide documents POST callbacks, authentication, and custom headers. It lists Growth, Pro, and Enterprise for accounts created after December 2025; older accounts and Freshdesk Omni can differ. Confirm that Trigger Webhook is available in your own account before deploying the recipe.

Authenticate before reading the event

Read the body with a small size limit and compare the custom-header token in constant time before parsing JSON. Then require exactly event, route, and ticket_id; reject extra fields so a later edit cannot quietly begin forwarding ticket content.

import { createHash, timingSafeEqual } from "node:crypto";

function equalSecret(left, right) {
  const a = createHash("sha256")
    .update(left ?? "", "utf8")
    .digest();
  const b = createHash("sha256")
    .update(right ?? "", "utf8")
    .digest();
  return timingSafeEqual(a, b);
}

function eventKey({ event, route, ticketId }) {
  const source = [event, route, ticketId].join(":");
  return `freshdesk-urgent:${createHash("sha256").update(source).digest("hex")}`;
}

The rule itself selects the Freshdesk group and priority. The relay separately checks the fixed route and event markers. These are two boundaries for configuration mistakes, not proof that the ticket is still urgent later. Freshdesk remains the source of truth.

Pingo the Pigeon, PingRoom's fictional Chief Marketing Officer, is giving the stopped duplicate his usual half-lidded review. He cannot read a ticket, access a private Room, or send a Ping; the support team chose the rule and the relay enforces it.

Queue one fixed Ping

Insert the derived event key into durable duplicate storage before acknowledging the Freshdesk request. The queue job needs only that key. It should not contain the ticket ID or original body.

One worker sends fixed copy and reuses the same key as both the PingRoom Idempotency-Key and correlation_id:

await fetch(env.PINGROOM_WEBHOOK_URL, {
  method: "POST",
  redirect: "manual",
  headers: {
    "Content-Type": "application/json",
    "Idempotency-Key": job.eventKey,
  },
  body: JSON.stringify({
    action: null,
    title: "Freshdesk urgent ticket created",
    message: "One selected urgent support ticket needs attention in Freshdesk.",
    correlation_id: job.eventKey,
  }),
});

Treat redirects, throttles, and other non-success responses as queue failures. Retry the identical body with the identical key. Do not make a new key for each attempt.

Freshdesk says webhook calls can be postponed when API limits are reached and may eventually be dropped after prolonged postponement. This route is therefore a best-effort attention cue, not an exactly-once delivery system. The Freshdesk webhook-drop guide describes that boundary and the admin email it may send.

Rehearse the boundary with disposable data

Before enabling the rule for normal support work, use a harmless test ticket and test Room:

1. A request with the correct source token, route, event, and numeric ticket identity queues one job.
2. Replaying the same created-ticket event queues no second job.
3. A wrong token is rejected before the body is trusted.
4. Another route or event creates no Ping.
5. A nonnumeric ticket ID, malformed JSON, extra field, oversized body, or wrong content type is rejected.
6. The queue worker sends only the fixed title, message, and derived key.
7. A PingRoom redirect, throttle, or other non-success remains a retryable queue failure.
8. A locked test phone shows no requester, subject, description, comment, email, organization, ticket URL, group name, or ticket number.
9. Freshdesk's Show Activities view records the rule execution for the disposable ticket.

For this article, the dependency-free relay passed 13 controlled boundaries with Freshdesk-shaped requests, a dedicated custom-header token, an idempotent in-memory queue, and a local mock of PingRoom's documented incoming-webhook contract. One unique mock signal was queued and delivered. No live Freshdesk account, public relay, PingRoom Room, phone, or customer data was used.

Keep the signal smaller than the support workflow

This Room is not the ticket queue. A Ping does not assign the case, acknowledge ownership, start or stop an SLA, verify a reply, or prove that every recipient saw the alert. Device permissions, connectivity, Focus modes, Room settings, and operating-system behavior can affect display.

Use Freshdesk for ticket state, agent work, assignment, history, and customer communication. Use your approved on-call system for emergency paging or contractual escalation. Use PingRoom only when one deliberately selected created-ticket event deserves a separate, minimal shared signal.

If that boundary fits your team, create the private Room, deploy the relay with durable duplicate storage, and test one disposable ticket before connecting normal support work.

Freshdesk is a trademark of Freshworks Inc. PingRoom is not affiliated with or endorsed by Freshworks.