# How to Send a Zoho CRM Deal-Stage Alert to a Shared Room

> Trigger one selected Zoho CRM stage rule, guard a privacy-minimal relay, and forward fixed, replay-safe copy to PingRoom.

- Published: 2026-11-09
- Author: PingRoom
- Category: Automation
- Topics: Zoho CRM deal stage notification, Zoho CRM workflow webhook, CRM phone alerts, webhook push notifications
- Canonical: https://pingroom.io/blog/zoho-crm-deal-stage-push-notifications
- Cover image: https://pingroom.io/blog/zoho-crm-deal-stage-push-notifications-cover.webp
- Cover description: Two PingRoom avatars move a blank deal folio to one selected clay stage while Pingo watches beside a closed detail box.

**To send a shared phone alert when a Zoho CRM deal first reaches one selected stage, create a Deals workflow that runs when the Stage field changes to that value, POST only a fixed event marker and the Deal record ID to a guarded relay, then let the relay replace the ID with fixed PingRoom copy and a replay-safe key.** The Room learns that the stage was reached. Deal names, accounts, contacts, owners, amounts, notes, and record links stay in Zoho CRM.

This is a webhook recipe, not a native Zoho CRM integration. Zoho CRM remains the deal record. PingRoom gives a small, stable group one short signal that it is time to open the CRM and take the agreed next step.

## First decide whether a shared Room is the right destination

Zoho CRM workflow rules can already send email, create tasks, update fields, run functions, and call webhooks. Keep the work there when everyone who needs the event already works in the CRM.

| Need                                                    | Better starting point                                    |
| ------------------------------------------------------- | -------------------------------------------------------- |
| Deal name, amount, owner, history, or next action       | Open the deal in Zoho CRM                                |
| A CRM user needs a task or email                        | Use a Zoho CRM workflow action                           |
| A small fixed group needs the same private phone signal | Use the guarded PingRoom recipe below                    |
| The event starts fulfillment, accounting, or onboarding | Keep the system of record and its controls authoritative |

The Room should not become a second CRM. A useful Ping says that the selected stage was reached and where the detail lives. It does not repeat customer or commercial data on several lock screens.

## Choose one stage with one shared consequence

Use a stage that changes what the group should do. **Closed Won** can be useful for a small onboarding Room; **Contract Sent** may suit a review group. Do not send every movement through the pipeline.

This guide uses fixed copy:

> **Zoho CRM stage reached**
>
> Selected Zoho CRM deal reached Closed Won. Open Zoho CRM to review.

`Closed Won` is approved configuration, not data copied from a deal. If the group immediately asks which deal changed, give the appropriate people Zoho CRM access or use a workflow designed for detailed handoff. Do not solve that question by putting account or contact data in the Ping.

## What you need

- A Zoho CRM account whose edition exposes workflow webhooks. Zoho's current webhook guide lists daily call limits for Professional, Enterprise, and Ultimate editions.
- A profile with **Manage Workflow** permission.
- One Deals stage and one stable group that genuinely needs the signal.
- A small HTTPS relay that can keep a route token, replay secret, stage key, and PingRoom URL on the server.
- A private PingRoom Room whose owner has **PingRoom Pro**. Incoming webhooks are Pro connections.
- A disposable test deal with no real customer data.

Zoho CRM documents static custom header parameters for secrets, but its workflow webhook guide does not describe a sender signature for this request. That makes the long route token and an unguessable relay path the authentication boundary. The Zoho webhook should call the relay, never PingRoom directly.

## Prepare the PingRoom destination

Open [your Rooms in the PingRoom browser app](/app/rooms), choose the private destination Room, then open **Settings → Connections → From another app**.

1. Add an incoming webhook and name it after the selected Zoho CRM stage.
2. Keep **Quick Ping** on **Custom message**.
3. Save and test it once.
4. Store the complete webhook URL in the relay's protected server configuration.

The URL is a credential. Do not paste it into Zoho CRM, source code, screenshots, or request logs. The [incoming-webhook reference](/documents/webhooks) documents current fields, cooldown behavior, idempotency, limits, and responses. The broader [webhook-to-phone guide](/blog/webhook-to-push-notification) explains why the relay owns authentication and privacy reduction.

## Create one exact Zoho CRM workflow rule

In Zoho CRM, open **Setup → Automation → Workflow Rules**, create a rule for **Deals**, and choose a record-action trigger:

1. Run the rule when an existing record is edited.
2. Select **Specific field(s) gets modified**.
3. Choose **Stage** and the one target value, such as **Closed Won**.
4. Add any stable pipeline or layout condition needed to prevent the same label in another process from qualifying.
5. Add one instant **Webhook** action.

Zoho's [workflow-rule guide](https://help.zoho.com/portal/en/kb/crm/automate-business-processes/workflows/articles/configuring-workflow-rules) documents the Deals module, specific-field edit trigger, conditions, and instant webhook action. Its separate [Closed Won automation walkthrough](https://www.zoho.com/crm/developer/docs/functions/getting-started/quickstart/build-automation.html) shows the same stage-change pattern with a function instead of a webhook.

In the webhook action, use `POST`, the relay URL, and raw JSON. Add this static custom header:

```text
X-Zoho-Route-Token: <a long random secret stored by the relay>
```

Build a two-field body:

```json
{
  "event": "deal_reached_selected_stage",
  "deal_id": "<insert the Deals record ID merge field with Zoho's # picker>"
}
```

Use Zoho's `#` merge-field picker for the record ID instead of typing a token from an example. Do not add the deal name, account, contact, owner, amount, probability, notes, stage history, or URL.

## Replace the record ID with a replay key

The relay accepts only the route token, the fixed event marker, and one numeric Zoho record ID. It then derives a non-reversible identifier with HMAC-SHA256:

```js
const digest = createHmac("sha256", ZOHO_REPLAY_SECRET)
  .update(`${ZOHO_STAGE_KEY}:${dealId}`)
  .digest("hex");

const replayKey = `zoho-stage-${digest}`;
```

Use that key for both PingRoom identity fields:

```json
{
  "action": null,
  "title": "Zoho CRM stage reached",
  "message": "Selected Zoho CRM deal reached Closed Won. Open Zoho CRM to review.",
  "correlation_id": "zoho-stage-<hmac-digest>"
}
```

Send the same value in the `Idempotency-Key` header. Discard the raw Deal ID after deriving the HMAC and keep it out of logs, queues, and PingRoom.

This key defines the recipe's meaning: **one Ping per deal and selected stage**. If a deal leaves Closed Won and later returns, the relay produces the same key and the request replays instead of sending another Ping. That is useful for a first-entry alert. If every re-entry matters, this recipe is the wrong contract; use a source event with a stable occurrence ID and document the new meaning before connecting it.

## Rehearse the boundary before enabling the rule

Zoho's [webhook guide](https://help.zoho.com/portal/en/kb/crm/automate-business-processes/actions/articles/webhooks-workflow) says to test with CRM data until the receiving application gets the expected request. Use a disposable deal and check these boundaries:

1. Keep the workflow inactive while you verify the relay URL and route token.
2. Move the test deal from a non-target stage to the selected stage.
3. Confirm the relay accepted exactly `event` and `deal_id`.
4. Confirm PingRoom received only the fixed title and message.
5. Replay the same request and confirm it returns the first result instead of creating another Ping.
6. Change the Ping body while reusing the key and confirm the idempotency conflict stops it.
7. Try a wrong route token, wrong event marker, malformed ID, and extra field; each must stop at the relay.
8. Move the test deal away and back. Confirm the first-entry policy still produces one Ping.
9. Only then enable the workflow for the intended pipeline.

The fixture for this article passed those cases against representative requests and a local PingRoom contract mock. No live Zoho CRM account, public relay, PingRoom Room, customer record, or phone delivery was used.

![Two PingRoom avatars test one accepted clay token while a duplicate stops at a guarded wooden relay and Pingo observes beside an hourglass.](/blog/zoho-crm-deal-stage-push-notifications-1.webp)

Pingo the Pigeon, PingRoom's fictional CMO, watched the duplicate stop and gave the relay a slow, approving blink. The human team still owns the rule, secrets, stage meaning, privacy choices, and product claims. Pingo cannot read deals, enter a private Room, or send a Ping.

## Read the result conservatively

Zoho CRM documents one retry after 15 minutes when a webhook fails, then no further webhook notification for that workflow trigger. It also documents edition-specific daily limits and a 10-second socket timeout. PingRoom idempotency makes an exact retry safe; it does not turn the overall path into guaranteed or exactly-once delivery.

A successful Ping means the configured relay accepted the selected workflow request and PingRoom accepted the fixed event. It does not prove:

- that the deal is paid, reconciled, onboarded, or fulfilled;
- that the stage change was correct or approved;
- that the deal is still in that stage now;
- that every phone displayed a notification;
- or that a person completed the next step.

Zoho CRM remains the place to inspect the deal and its history. PingRoom records the short shared signal and sends it through its normal delivery path. Network conditions, operating-system settings, Room mutes, and notification permissions can still affect device display.

If that boundary fits your group, [create or choose the private Room](/app/rooms), add its incoming webhook, and rehearse one disposable Deal before enabling the Zoho CRM workflow.