A Customer Edited a Telegram Message: Update the CRM Note Safely

When a customer edits a Telegram message, do not turn the correction into another lead or replace the entire CRM record. Find the original source record, compare meaningful data and update only fields owned by the integration. If the source link is missing, versions conflict or an operator has changed the target note, retain the correction for reconciliation. Request arrival time does not prove that its text is newer.

This guide is for a developer maintaining a custom Telegram Bot API integration with a CRM. It assumes authorized receipt of enquiries, durable storage and an isolated test environment. It proposes a design policy, not a verified 24go.site feature or a ready-made configuration for any particular CRM. The scope is ordinary message and edited_message updates. Channel posts, business messages, guest formats and deletion need separate contracts. No live credentials are needed for the local policy check.

A message correction is not a repeated delivery

In the Update object, edited_message represents a new version of a message known to the bot that was edited. The documentation warns that changes to fields unavailable to, or not actively used by, the bot may also trigger this update. Receiving one therefore does not by itself require changing a visible CRM note or qualifying the customer again.

Redelivery of an update and revision of a source message are different problems. An event deduplication key must not discard a different update merely because it concerns an existing message. Conversely, a new update with identical meaningful content does not need another note. Use the separate webhook idempotency design for repeated delivery and ambiguous record creation. This guide starts with the relationship between a source message and an already-linked CRM object.

Agree with the sales process owner on what a correction means. Changing “we need five licences” to “we need three” may amend an enquiry, but it does not independently authorize changing an approved deal amount. A spelling correction should not automatically send another email or reopen a task. Business effects belong to your agreed workflow, not to the name of a Telegram field.

Give the source message its own identity

Keep an event key separate from a message key. The event key needs your source context and update_id. For an ordinary message, a proposed application key combines tenant, bot, chat.id and message_id. Here, tenant identifies the organization within your system; it is not a Telegram field. The additional namespaces prevent two customers of an integration provider from sharing a source record accidentally.

The Message contract describes message_id as unique inside its chat. That number alone is insufficient for a whole database. A username, sender label or enquiry text is also unsuitable for locating the original note: these can change or coincide. If a source link is missing, do not select a vaguely similar deal by matching a few words and silently write the correction there.

Maintain an explicit mapping: source message key → internal source-record ID → target CRM note ID. Store the supported message shape, mapper version, accepted projection and delivery state alongside it. A projection is the selected data used to build your note, such as text with its associated entities or a caption with its own metadata. Define and version this application schema instead of assuming every field in an incoming object belongs in the CRM.

If an input's identity does not fit the supported ordinary-message scheme, stop automatic replacement. Special identifiers and newly introduced API formats are not supported merely because the JSON contains a familiar field name. Route them to separate handling. This design is not a universal decoder for every Telegram message format.

Compare source time and meaningful content separately

Message has an optional edit_date, the time the message was last edited in Unix time. It helps compare revisions of one supported source message, but it is not a complete revision history. Do not substitute the HTTP receipt time or job completion time. A slow worker can finish an older job after a newer one has completed.

The proposed conservative policy has distinct outcomes. If the selected projection equals the current one, there is no need to change the visible note. However, a later valid source edit time should still advance the boundary of versions already observed. Otherwise a subsequent late change may appear newer than an obsolete marker. Observation metadata and note content have different reasons to change.

If the projection differs and the source edit time is strictly later than the accepted boundary, it is a delivery candidate. If the time is earlier, do not replace the current projection. If the times are equal but the projections differ, record a conflict rather than choosing whichever request arrived last. This policy can require manual decisions, but avoids presenting an inferred order as a proven one. A missing or invalid edit time also requires reconciliation before an automatic replacement.

Retain update_id for deduplication and investigation, but do not describe it as an everlasting per-message revision counter. The Update documentation allows the next identifier to be chosen randomly after at least a week without new updates. Its documented sequencing role is useful, but does not replace your conflict-resolution and field-ownership contract. Do not invent an exact revision number that the source does not provide.

Decide who owns each CRM field

Before enabling automatic corrections, build an ownership table. For each target field, specify its owner, permitted action and how an operator's intervening change will be detected. A source-text note, deal stage and verified contact number should not inherit one blanket “last event wins” rule.

If the CRM supports a conditional write against a version, verify its actual contract and use it. Reading a note and then issuing an ordinary PATCH does not prevent an operator from changing it between those steps. Without confirmed conditional-write support, proposing an explicitly linked correction is safer than promising that replacement cannot lose work. Appending also needs a stable operation identity so retries do not add several identical corrections.

Do not turn the revision ledger into an uncontrolled archive. Define source retention and access separately under your lawful processing arrangements. Secretly copying all previous texts into logs does not become acceptable because it makes investigation easier. General telemetry usually needs internal identifiers, outcome codes and the adapter version rather than complete private enquiries.

Handle an edit whose original record is missing

An unknown original does not prove that the customer opened a new enquiry. The initial job might be delayed, its CRM mapping might not yet be saved, or the relevant message might predate your observation window. Persist the correction as waiting for a source link, and inspect the local job queue and mapping ledger. Do not create another lead by default.

Assign a deadline and an owner to this reconciliation. Once the original becomes available, process the retained correction under the same version rules rather than replaying its initial write command unchanged. If no link can be established, the operator should see an unresolved outcome, not a green synchronization status. Repeated missing-original cases may indicate routing or persistence defects.

Do not promise to reconstruct complete message history through this design. An edit exposes an observed version, not every change ever made. The absence of another update does not prove that a user made no correction. Likewise, an ordinary edited_message is not a deletion notification. Missing text in an unsupported message shape must not be converted into an instruction to erase the CRM note.

Apply the correction in explicit stages

1. Persist the update and its type through your existing authenticated receiver. Webhook authentication and acknowledgement after durable acceptance remain necessary, but are not redesigned here. The dispatcher must explicitly distinguish a new message from an edited one.
2. Resolve the source key and its target note mapping. Check the organization, bot and chat; do not trust a client-supplied ID for another organization's deal. If the source is unknown, create a reconciliation task without a remote replacement.
3. Build the supported body projection together with its associated metadata. An absent field in an unsupported shape does not mean an empty string. Compare meaningful link destinations too if they are part of the note, not only the displayed link labels.
4. Within one local transaction, decide against the currently accepted version and save an operation intent. Use an atomic claim or record-version check so two workers cannot independently accept incompatible decisions. A check held only in process memory is insufficient.
5. For a delivery candidate, apply field ownership and the CRM's verified capabilities. Recheck that the operation is not already stale locally immediately before the write, and use a documented conditional write when available. A local transaction cannot lock an operator out of the remote CRM note.
6. Read back the target record and compare the expected data. If a timeout leaves the result unknown, retain a reconciliation state; do not generate a new operation key or blindly repeat replacement. Link a confirmed outcome to the particular source version that produced it.

Exercise the policy before connecting a CRM

A reproducible local policy check needs only synthetic keys, texts and times. Implement a pure decision function with no network access. Inputs are whether the original is known, the accepted source time and projection, and the candidate time and projection. Outcomes must distinguish unchanged content, a stale input, a delivery candidate and reconciliation. Separately check advancement of the observation boundary when content matches: “do not write the note” is not the same as “forget this observation.”

These cases check only the proposed decision policy on artificial inputs. Connector acceptance also needs competing jobs, a restart after a persisted operation intent, an operator's intervening edit and a lost CRM response. Separately test that a new caption does not reuse old entity metadata. A passing decision function establishes neither database atomicity nor conditional remote writes.

In an isolated integration environment, create one authorized enquiry and record its CRM note ID. Correct a spelling error, then change a meaningful condition. Verify that both corrections remain linked to the same source, no additional deal appears and business effects follow the approved policy. Have an operator edit the target note before another source correction; check the conflict outcome rather than merely inspecting the HTTP response.

Close the rollout with a precise statement of which decisions passed locally, which outcomes were confirmed by CRM readback and which remain under manual reconciliation. Track the age of unresolved corrections and conflict reasons. The operator needs the corrected enquiry without silently losing their own work. That is the acceptance result to establish before enabling automatic replacement.

Sources

• Telegram Bot API: Update, edited_message, update_id behavior and event scope; checked on the editorial date.
• Telegram Bot API: Message, message identity, edit_date, text and captions; checked on the editorial date.