How to Send a Trello Card-Move Alert to Your Team’s Phones

To send a phone alert when a Trello card enters a selected list, create one Trello Automation rule with an HTTP POST action aimed at a PingRoom incoming webhook. Keep the message short and fixed, use the card id and move time as a correlation id, and leave the card’s assignment, comments, files, and history in Trello.

This is a webhook recipe, not a native Trello integration. It is useful when a small group needs one shared signal such as “a card entered Ready” without watching every change on the board.

Check Trello’s own notifications first

Trello can already notify people who watch a card, list, or board. Watching includes card moves, and the Trello mobile app has its own push-notification controls.

Use the smallest tool that fits:

Do not invite someone to a Trello board only to deliver one alert. Trello notes that board members can see the board’s cards and lists; keep board access tied to the work, not to notification convenience.

Create one destination Room

Create a private PingRoom Room for the people who need the transition. The Room owner needs PingRoom Pro for incoming webhooks.

Open the Room’s Settings → Connections → From another app, add a webhook, leave Quick Ping on Custom message, and copy the complete webhook URL. A Room can have up to four incoming webhooks.

The URL contains the secret. Anyone who can read it can fire the Room, so treat access to the Trello rule as credential access. Do not paste the URL into a card, comment, screenshot, or exported runbook. If it leaks, regenerate the secret in PingRoom and replace the URL in Trello.

The broader webhook setup guide explains PingRoom’s request and response. The incoming-webhook reference carries the current field limits and error shapes.

Add one Trello rule

In the board, open Automation, create a Rule, and choose the trigger for a card moving into the list you care about—for example, Ready. Add the HTTP request action from Trello’s Content actions, choose POST, and enter the PingRoom webhook URL.

Trello’s HTTP-request documentation allows JSON payloads and custom headers. Use these headers:

{ "Accept": "application/json", "Content-Type": "application/json" }

Use this payload:

{
  "action": null,
  "title": "Trello card ready",
  "message": "A card entered Ready",
  "correlation_id": "trello-{cardidlong}-{cardmoveisodate}"
}

Trello documents {cardidlong} as the card’s stable long id and {cardmoveisodate} as the last move time. It also says variables in a payload are escaped for JSON. The correlation id helps you connect the Ping to one card move without putting the card name on a lock screen. It is not a Trello record locator and does not prevent duplicates by itself.

These AI-generated editorial illustrations feature approved PingRoom avatars and Pingo the Pigeon, PingRoom’s fictional Chief Marketing Officer. They are not Trello or PingRoom screenshots and do not depict customers.

Pingo has no board access, no private-Room access, and no authority to move a card or send this Ping. In the illustration, he is only watching the detailed record stay on one side while the small signal leaves—a separation the human team configures.

Keep the notification deliberately small

The fixed body is the safer default. It reveals no client name, task title, assignee, board name, or card link on a locked phone.

If your team has a documented naming policy and every title is safe for notification previews, Trello also exposes {cardname}. PingRoom’s current private-Room message limit is 120 characters, while this direct Trello rule cannot truncate a long variable. Use a relay when you need to clean, shorten, classify, or redact card data before sending it.

Keep these details in Trello:

• card description, comments, attachments, checklists, and customer information;
• the person responsible and the due date;
• why the card moved and what “Ready” means;
• later corrections or a move back to another list.

A Ping reports the transition that triggered the rule. It does not prove that the work is correct, complete, reviewed, or accepted.

Understand the retry limit of the direct recipe

PingRoom supports an Idempotency-Key header, but Trello’s public HTTP-action guide documents variable escaping for URLs and payloads, not variable substitution inside custom header values. This direct recipe therefore does not claim retry deduplication.

If Trello sends the same accepted request twice, two Pings may appear. When that consequence matters, put a relay between the products. The relay should derive one stable key from the card id and move time, send it as PingRoom’s Idempotency-Key, and retry the identical body with the identical key.

The direct rule is a good fit when occasional duplicate handling is acceptable and the group can confirm the current state in Trello. It is a poor fit for billing, legal approvals, safety procedures, or any workflow where one extra alert creates a material risk.

Test the rule with a harmless card

Before enabling it on a real board:

1. Create a sample card with no sensitive information.
2. Move it into Ready once.
3. Check Trello’s Automation activity, the PingRoom Room history, and one recipient device.
4. Move the card out of Ready, then back in, and confirm that the second move creates a new Ping.
5. Disable notifications or disconnect a test device once, so the team sees why an accepted webhook is not a display guarantee.

For this article, we substituted representative Trello variables into the recorded payload and sent it to a local mock of PingRoom’s documented endpoint. The check covered the JSON, headers, field limits, correlation identity, accepted response, and the direct recipe’s duplicate risk. It did not use a live Trello Workspace, PingRoom Room, or phone.

Trello Automation is available in all Workspaces, but its monthly run and operation quotas are pooled and depend on the Workspace plan. One narrowly selected transition is easier to budget and understand than a rule that fires for every card change. PingRoom also applies webhook cooldown and rate limits; review the current reference before connecting a busy board.

An HTTP 200 with success: true means PingRoom accepted and queued the Ping. It does not guarantee that every phone displayed it. Connectivity, notification permission, Focus settings, Room mutes, and operating-system policy still apply.

If one chosen Trello transition deserves that shared signal, create the destination Room and its webhook, test with a harmless card, and keep Trello as the place where the work lives.

Trello is a trademark of Atlassian. PingRoom is not affiliated with or endorsed by Atlassian.