By Artem Korsakov ·
Let us consider a typical path: the client fills out a form, the website saves the inquiry, and the integration sends the fields to CRM. On the third step, the service is temporarily unavailable. If everything ends with a disappearing error message, the employee may never learn about the new lead.
Determine where the original inquiry is saved
Before setting up integration, you must decide which system is responsible for the primary record. For a form, this might be its own storage, CRM, or another agreed-upon point. It is important that if the transmission fails, there is a way to recover the request.
There must be an inquiry number or another identifier that passes through all stages. With it, the employee can link the form message and the record in the final system.
The set of saved data and retention period are defined separately. The exchange log should not become an uncontrolled copy of all customer correspondence. For diagnostics, it is often sufficient to have the identifier, time, action, and result; access to details should be restricted.
Distinguish between an attempt and a result
Process owners benefit from statuses such as "Pending Transmission," "Sent," and "Requires Review." Success occurs when the recipient confirms the record. An initiated send is not yet success.
Sometimes a record is created, but the response from the receiving system does not arrive. If you automatically send the same data again without verification, a duplicate will appear. Therefore, the method for resending must be planned together with identifiers and the capabilities of a specific integration.
With multiple systems, you cannot promise an instant identical view everywhere. Agree on where the main status is stored and what delays can be expected.
How to display integration errors
The list of problematic sends must answer simple questions:
- which inquiry was not processed;
- when the last attempt occurred;
- what is known about the cause;
- who should intervene;
- whether it is possible to retry the action;
- how to ensure no duplicate was created.
Not every error requires a separate urgent signal. Temporary service unavailability and incorrect mandatory fields require different procedures. For example, scheduled retries may help in the first case but will not fix an incorrect phone number or missing category.
Подпись: Illustrative example. For the user, all four cases look like "not sent," but actions differ. Retrying helps only in case of temporary unavailability.
Resending a lead: what to agree upon
For a small project, it is reasonable to agree on one source, one receiving system, and a fixed set of fields. Methods for resending and manual correction are described separately.
Bidirectional synchronization, mapping a large reference list, and transferring old history expand the task. The owner must understand whether these are included in the estimate. More on how such conditions affect the scope of work can be found in the article on integration costs.
AI explains the problem, rules manage resending
You can pass authorized records from the log and instructions to an assistant: it will prepare a summary "leads without a new mandatory field are being rejected starting from the morning" with links to events. The responsible person checks the cause and selects an action. Commercial data and connection secrets are not included in such a summary.
Resending itself is performed according to pre-set rules. The model should not guess and change details, delete records, or increase access rights. An error "no mandatory field" requires data correction; a lost confirmation requires searching for an already created record. These are different actions, even if both cases look like "not sent" to the user.
1C (a Russian accounting and ERP platform) Platform supports a REST interface for data exchange. However, the presence of a mechanism does not mean that the required objects are published in a specific database and permissions are configured. This must be verified before estimating integration.
Подпись: Illustrative example. AI finds the common cause of failures and links to log events. Resending starts a rule after the responsible person resolves it.
How a manager can verify reliability without reading code
Ask to show one lead at each stage and find it by the original number. Then resend it: the number of business records should not increase. After temporary unavailability of the recipient, show where the inquiry is stored and who sees the queue. After recovery, find the confirmed record in the final system.
For two consecutive changes, check the order: an outdated status should not overwrite a newer one after a delayed retry. This scenario is especially important when canceling an order. If a specific integration cannot currently resolve conflicts automatically, it must stop the disputed record for human review.
Acceptance ends with a comparison of the original inquiry with the result. A green checkmark in the log is not enough for this. For a pilot, one direction of exchange is sufficient; expansion to other entities occurs after verification of this chain.
Which situations to check before launch
Send a correct inquiry, then an incomplete one and a repeated one. Check the receiving system's unavailability, data rejection, and a scenario where a record is created but confirmation is lost.
The employee must be able to find the inquiry, understand its status, and perform an agreed-upon action. If resending is possible only through a developer, this limitation must be identified in advance.
This verification relates to the standard reliability of data exchange. AI integration does not replace it: even a correctly processed letter still needs to be safely saved and passed on.
trike_dev can connect your systems and determine the error handling procedure. A demo integration shows an example scenario, and actual methods of exchange depend on your systems. The basic set of fields is discussed in the article on sending leads to CRM.
Related reading: Preparing data for automation: reference data without confusion; Automation support: what is needed after launch.
Частые вопросы ### Can you guarantee the absence of any failures?
No. You can define reactions to known situations, save necessary details, and regularly verify the connection.
Should all errors be fixed automatically?
No. Incorrect source data or disputed mapping often require an employee's decision. It is important that such cases are visible.