An illustrative example: a salesperson wants to see whether the warehouse has prepared an order. Someone immediately suggests “synchronising everything both ways”. The actual need is smaller: answer the customer without calling a colleague every time. Reading the temperature does not require permission to change the weather.
If the company already uses another CRM or accounting application, first establish what needs to be seen. An integration is a data exchange connecting systems; it does not always have to change both sides.
Choose one source of the status
Identify where an employee decides that an order is ready. That system remains the source of the status. The second system displays received information, while corrections happen in the original.
Specify how records are matched. Company names and customer names can repeat; an exchange needs an agreed stable identifier. This does not require moving the whole customer database.
Do not make a field look editable when the user can only view it. Its label should explain the source and where to make corrections.
Agree on freshness
The displayed status may be out of date. Show the last successful retrieval time and define what happens after a failure. “Data has not been refreshed” and “order is not ready” are different messages.
Decide how much delay the particular task allows. If another check is required before making a customer promise, keep it in the process. An exported copy is not automatically real-time information.
For a team in Kazakhstan, agree on the time zone for timestamps and understandable status names in the working languages. Even a fresh record can otherwise be misread.
Reading in a scenario is different from permissions
If one side is Bitrix24, check REST API availability for that particular portal. An API is a software interface for exchanging data. The official access guide describes operating conditions and how user rights relate to integration permissions. Check other applications' conditions separately.
For a webhook, a way of calling the API, actions depend on its creator's user rights and selected access scopes. This is described in the first request guide. Simply writing “read-only” in a specification does not restrict granted access.
Ask the developer to explain which changes are technically prohibited and which are merely unused by the current scenario. Access to a module does not automatically mean a separate ban on writing. Consider both systems and the intermediate service.
Check for side effects
Using test data, retrieve the status, repeat the request and simulate no response. Confirm that the original order did not change, no duplicates appeared and the employee saw a clear error state. Check the activity log and behaviour with insufficient permissions.
Keep secrets on the server instead of placing them in a public page. Retrieve only required fields rather than every available detail “just in case”.
If your current CRM supports the work, replacing it just to view one status may be unnecessary. QQDev develops exchanges through the Bitrix24 REST API. On the service page, you can discuss a narrow scenario: which data is needed, its source and changes that must be excluded. Whether another system can be connected is first checked against its interface and access conditions.