Клиент исправил сообщение Telegram: как обновить заметку в CRM [перекрёстная публикация]

If a client corrected a Telegram message, do not create a new lead or replace the entire card. Find the original message record, compare significant data, and update only the fields owned by the integration. If the record is not found, save the correction as a separate task for comparison. The time of the inquiry does not prove the text is newer.

This guide is for developers integrating Telegram Bot API with CRM, assuming a permitted receipt of requests, persistent storage, and an isolated test environment. It is a project policy, not a confirmed feature of 24go.site or a ready setup for a specific CRM. The guide covers regular messages and edited messages, channel events, business messages, guest formats, and deletion require separate contracts.

The edited_message field in the Update object indicates a new version of the message the bot edited. The documentation warns that the event sometimes triggers changes to fields inaccessible or unused by the bot. Therefore, the fact of receiving such an update does not mean the need to change the visible card or requalify the customer.

One update and correction of the original message solve different tasks. Duplicates by event key should not discard another update just because it refers to the previous message. Conversely, a new update with the same content does not require a second card. For duplicates, use a separate webhook scheme of idempotency. The task begins after the source connects to the existing CRM object.

First, agree with the sales owner about the meaning of the correction. Replacing "need five licenses" with "need three" may clarify the inquiry, but it cannot change the confirmed deal amount by itself. Fixing a typo does not require resending the letter or opening a task for the manager. The business decision is up to your process, not the Telegram field name.

Keep the original message's unique key. Store the event key and message key separately. The event needs your source context and update_id; for a regular message, a composite key of tenant, bot, chat.id, and message_id is suggested. Tenant refers to the organization within your system, not the Telegram field. Additional components prevent two integrators from accidentally dividing a single record.

Do not try to find a similar deal by name or signature if there is no link. Do not assume similarity based on a few words. Maintain clear correspondence: message key → internal ID of the original record → CRM target card ID. Keep supported message type, converter version, projected projection, and delivery status nearby. Projection means the chosen data from which you build a card: for example, text with relevant markup or signature with its metadata.

This is an application scheme that needs to be defined and versioned. If the input identity does not fit the supported usual scheme, stop automatic replacement. Special identifiers and new API formats cannot be accepted just because the JSON contains a familiar field. Direct such input to separate processing. Compare the content and source time separately.

The Message has an optional edit_date field, which shows the last edit time in Unix time. It is useful for comparing edits of the same supported message but is not a complete edit history. Do not replace it with the time of the receipt request or task completion: a slow worker may finish old work after the new one. The suggested conservative policy uses several sources.

If selected data match the current ones, do not change the visible card. However, a later permissible source time should be saved as a boundary for observed versions. Otherwise, a delayed later change may look new relative to the old marker. Observation metadata and card content have different update reasons. If the content differs but the source time is strictly later than the accepted one, it is a candidate for correction.

If the time is earlier, do not replace the current projection. If both times are equal but the data differ, record the conflict instead of choosing by arrival order. This conservative mode may require manual resolution but does not assume a proven order. Keep update_id for deduplication and conflict investigation, but do not declare the message edit count eternal.

The Update documentation allows a random selection of the following identifier after at least a week without new updates. Its description helps restore the sequence of message edits but does not replace your contract on conflict resolution and field ownership. Do not invent a missing exact edit number. Decide who owns the CRM fields.

Before automation, create a table of owners. For each field, specify the source, permitted action, and method to detect the operator's change. The target data, initial message status, deal stage, and confirmed phone number should not share the same rule "last event wins." Target responsibilities and accountability must be clarified.