Integrating a CRM system with a mobile app: BFF, offline, push

CRM integration with a mobile app: where the exchange breaks

A connection drop in an elevator or subway — the client submits a request, taps "Send," and sees confirmation. The accounting system has no request: the request went out at the moment the connection had already dropped, and no retry followed.

The request was lost during the connection drop, and the client learns about it from a manager by phone, not from the app that had just promised otherwise.

The second point of breakage is the key by which the app and the accounting system match a person. If the lookup is by phone, and the same client in the database has a different spelling of the number, a new record is created on the next login.

This is how duplicate client cards appear: order history splits across two records, discounts and bonuses are counted twice, and merging is then done manually and with the loss of part of the history.

Third is statuses. A manager moves an order to "Shipped," while the app still shows "Assembling" an hour later, because the exchange runs on a schedule rather than on an event.

A mismatch in order statuses generates extra support requests and undermines trust in the app more than any interface error.

A separate story is manual data transfer as a patch: export from the app, reconciliation in a spreadsheet, manual edits. It eats up employee time and adds new discrepancies exactly where they were trying to eliminate them.

The cause of all four failures is the same: between the app and the accounting system there is no layer responsible for retrying writes without duplicates, conflict resolution, and delivery to a specific device. Let's look at how this is addressed.

Eliminated failure classes and manager productivity

The most costly were not server failures but silent losses: a request created where there is no connection lived in the phone's memory and disappeared on restart.

Now it immediately goes into a deferred-send queue and goes to CRM as soon as a channel appears; the resend is marked with a record key, so a network drop produces not a duplicate but the same card.

The second class is record version conflict, when a manager and an operator edit the same card simultaneously.

Revisions are compared field by field, not by the principle of "last write wins": matching changes are merged, discrepancies are flagged and sent for confirmation with highlighted differences. The request is no longer overwritten by an outdated form.

The third is duplicate data entry. Previously, the cycle looked like this: a note in a notebook, manual transfer in the evening, reconciliation with photos.

Now data is entered once on site, attachments and signatures are uploaded in the background, and the manager closes the request immediately, not a day later.

In numbers, it looks like this: the share of requests lost before reaching CRM falls from a few percent to zero — each case either goes into the system or remains in the log with a failure reason.

We built the scheme for Bitrix24 as well, and we adapt it to any CRM with an open API. The processing time for an on-site request is reduced severalfold, because the path from recording to a card in the system is compressed to a single action.

Integration options: server-side layer, direct access, bus

The first decision in integration is where the data selection logic lives and who owns access to the accounting system. If the app accesses it directly, any structure change breaks releases, and permissions have to be handed out externally.

A server-side layer keeps the accounting system closed: the app receives only prepared responses tailored to a specific screen and knows nothing about its internal structure.

The choice is driven by synchronization constraints. Where edits come from both sides, an explicit conflict resolution strategy and idempotent operations are needed — otherwise a resend creates duplicate records.

We start by analyzing scenarios: most often, a layer and scheduled exchange are enough, and a bus appears when there are several sources and discrepancies between them stop being an exception.

How implementation proceeds: from data analysis to handover

The earlier the data schema is fixed, the cheaper each subsequent change.

Before the first line of code, we analyze which CRM entities are really needed on the screen and which ones should not be pulled into the mobile environment: an extra field means response weight and a new cause of synchronization conflict.

The outcome of this stage is an exchange map, not an agreement that "we need to integrate."

1. Data schema audit. We reduce deals, contacts, tasks, and activity history to the fields that actually reach the interface and mark those that change on both sides — this is the map of future conflicts.
2. Exchange design. We decide what the app requests directly and what it receives through an intermediate layer: it assembles a response from several sources and gives the screen one compact set instead of a series of requests.
3. Setting up send queues. Records made without a network go into a local queue with ordering and retries. The server matches them by identifier and only then writes to CRM — a resend does not create duplicates.
4. Conflict testing. We intentionally break scenarios: edits from two devices, a network drop at the moment of sending, login after access rights change. We look at which record version wins and whether the employee sees that the edit was not saved.
5. Handover and team training. We hand over the exchange schema, queue configuration, field reference, and analysis of typical failures, and train your developers and support team — so that changes to scenarios do not require coming back to us.
6. Post-launch support. We keep delivery metrics, the share of successful synchronizations, and queue depth: an alert about its growth arrives before users notice data loss.

What remains with you: exchange schemas, rules, regulations

Integration is considered complete not at the moment when data starts flowing, but when maintenance does not require the solution's author.

Therefore, a set of artifacts remains in the client's environment, which support, security, and new developers can use independently, without asking us for explanations.

• Data exchange schema — which CRM entities go into the app, in what form, which fields are mandatory, and how a conflict of simultaneous edits to the same record is resolved.
• Access rules and roles — a "role → available entities and operations" matrix, with separate blocks for external users and for revoked accounts.
• Error handling policy — which failures are considered temporary, how many retries are performed automatically, and at what point an event goes to manual review.
• Support instructions — ready-made scenarios: data did not arrive, a notification did not reach, a record was not saved — and what exactly to check in each case.
• Event logging — which events are written, their retention period, and how to link a user complaint to a specific exchange by request identifier.
• Deployment diagram — which services live in the client's environment, where addresses and access keys are stored, and how a test environment is raised for checks.
• Change procedure — how to add a field or entity without breaking the app on devices with previous versions.

Each document is backed by working configurations, not a "general description." Before handover, we go through the artifacts together with your team and answer questions — so that after launch there are no nodes that work only in our heads.

Case study: how requests stopped getting lost during connection drops

A service company with field crews accepted requests through a mobile app, while a dispatcher managed them in Bitrix24.

When the connection dropped, a card was created on the device, but the server response did not arrive — the app marked the send as unsuccessful and did not retry.

Up to 14% of requests were lost per shift, and the dispatcher learned about some of them from the client by phone, not from the system.

We implemented an offline queue: a request is saved locally and is sent again when the network is restored, and each one gets a key by which the server discards duplicates.

Between the app and CRM, we placed an intermediary layer with a unified contract — the app does not depend on how fields are renamed in CRM. Statuses come back via push notifications, so the operator does not call to check whether the request was accepted.

What changed in the first month of operation:

• share of lost requests — 14% → 0.4%;
• average request processing time — 26 → 9 minutes;
• requests per operator per shift — 40 → 65 without expanding staff;
• share of clients calling to check status — 31% → 6%.

The value here is not in "it became more convenient," but in the fact that losing a request stopped being a scenario: the network dropped, the app was closed, the phone died — the request still reaches the dispatcher and comes back to the client with a status.

What to do if the accounting system is already deployed and in use?

A deployed environment is not stopped for the sake of exchange: new logic is built alongside the working one, not instead of it.

Requests, reference data, and balances continue along current routes while changes are tested on traffic copies — this way, implementation proceeds without sales downtime. The switchover does not happen in a single day but by user groups and offices, with a phased plan.

Backward compatibility relies on method versioning: new fields come as optional, and old builds still installed on employees' phones receive a response in the previous format.

The exchange goes through a BFF layer, so the mobile client does not know which accounting system (1C) holds the data, and it does not need to be rebuilt with every schema change.

Lossless data migration is a separate stage, not a side effect of launch. Checksums are reconciled at the source and destination, each record is marked with a retry key, discrepancies are collected in a log and loaded after the main pass. We schedule bulk operations in a night window, when the load on the accounting system is minimal.

A rollback plan is prepared before launch, not after a failure: the previous app build remains available for installation, the server side keeps a switch to the old exchange route, so rollback takes minutes.

The decision is made based on control metrics — the share of successful synchronizations, send queue depth, and response time. What to switch first — exchange, offline queue, or push notifications — depends on where there is more manual work in the current environment.

Common technical concerns before starting

Before starting, the client wants to understand who is in charge of data in the system and what will happen during a synchronization failure. Below are questions that come up in almost every assessment, with our substantive answers.

What if the same record is edited from two sides at the same time?

Conflict resolution is based on version and modification time: the server compares them and either accepts the edit or flags the record for manual review. Fields managed only by CRM are not affected by changes from the app.

How is client data protected?

Data on the device is stored encrypted, authorization uses short-lived tokens, permissions are checked on the server with every request, not inside the app. A session can be revoked remotely, and no personal data remains in the logs.

Can accounting rules be changed without reinstalling the app?

Yes. Calculation logic, statuses, and reference data are moved to the server; only display remains in the app. Rule updates arrive on the device without releasing a new build and without any action by the user.

What happens with a weak connection?

Edits are put into a local queue and go to the server as soon as a connection appears. A resend does not create duplicates — each operation is marked with its own identifier.

Let's discuss the task and come back with an estimate and plan

To discuss the integration task substantively and come back with a stage-by-stage estimate and plan, rather than generalities, a minimum set of inputs is needed. Below is what to send for analysis; if something is missing, we will fix it as the first stage of work.

• App usage scenarios: what the user views and changes from the phone, which operations must work without a network, and how data is loaded when the connection returns.
• Access and environments: a CRM test environment, accounts with different roles, network access rules on your infrastructure side.
• Data model: entities that go to the device, relationships between them, approximate record volume, and change frequency.
• Contracts: a description of the existing API or an export of current requests, response formats, and error codes.
• Permissions and notifications: who sees and can change what, which events should arrive on the device, and text templates.
• Constraints: estimated load, expected timelines, what has already been tried and why the solution did not fit.

The interaction process is simple: we analyze scenarios and constraints, we assemble a stage-by-stage work plan with the inputs for each stage, then come back with timeline estimates and a risk analysis. We handle clarifications in writing so that the estimate remains verifiable. Describe the task — we will come back with a plan and timelines.