Tool sprawl: how to connect 1C, CRM, your bank and Telegram into one system
The average company uses 101 cloud services, according to Okta's 2025 report, and at best a third of them are connected to each other: MuleSoft data shows that only 29% of enterprise applications are integrated. The rest are connected by a person at a keyboard who copies, transfers and makes mistakes. The good news is that removing this manual bridge doesn't require replacing 1C (the accounting and ERP platform most Russian companies run on), your CRM and your bank with a single "mega-system": they can be connected into one integrated system.
Below is a jargon-free breakdown: what integration is and how it works, what approaches exist and how they differ, what to do about 1C and services without an API, where Federal Law 152-FZ (Russia's personal data protection law) comes in, and which connection to start with.
What is system integration, in plain terms?
Integration is a configured exchange of data between programs with no human involved: an event that happens in one system automatically appears in every other system that needs it. A payment arrives at the bank, and the invoice is closed in accounting, the deal moves forward in the CRM, and a notification goes out to the manager in Telegram. Nobody copied anything: the systems agreed to exchange data on their own, following rules defined in advance.
A typical picture at a growing company: accounting in 1C, sales in the CRM, inquiries in Telegram, reports in spreadsheets, payments in the online banking client. Each system does its job well, but between them sits an employee who moves data by hand and makes mistakes.
Tool sprawl in itself is normal, not a sign of disorder. In the Okta Businesses at Work 2025 report, the average company has 101 applications, and large enterprises, according to MuleSoft research, have 897. What costs money is the gaps between systems: wherever data is carried by hand, the business pays in time and errors.
What does a connected system give a business?
A connected system eliminates double data entry: every figure is entered once, in the system where it originates, and from there it automatically reaches everywhere it's needed. The effect is measurable: in a study by SberAnalytics and Sber Business Soft, 37% of companies that implemented automation report a lower share of manual operations, and 36% report fewer errors in documents and reports.
In practice, it looks like this:
- A payment from the bank automatically closes the invoice in accounting and moves the deal forward in the CRM.
- Warehouse stock levels are visible to the sales manager right in the CRM, without calling the storekeeper.
- The manager receives a summary in Telegram, compiled from all systems at once.
- Transfer errors disappear entirely: a machine doesn't type into the wrong cell.
Manual bridges cost more than they seem to. According to a 2025 survey by hh.ru, Russia's largest job board, one in four employees in Russia spends more than six hours a week on reports and reconciliations that nobody has automated, which is almost a full working day spent shuffling numbers between systems.
How do systems exchange data without a person?
Through an API, a programmatic "entrance for other programs." If a service has an API, another system can request data from it or send its own in a strictly defined format, like a visitor at a reception window. Today almost everything Russian businesses use has an API: 1C, Bitrix24 (a Russian CRM and collaboration suite), amoCRM, MoySklad (a Russian inventory management service), banks, online cash registers and Telegram.
Several other mechanisms work around the API, and each has an everyday analogy:
- Webhook. A "callback": the system itself reports an event at the moment it happens. Like a text from your bank about a charge: you don't check your account every five minutes, the bank sends you a message.
- Message queue. A "waiting room" for data: if the receiving system is temporarily unavailable, the data waits in a queue and is delivered once it's back, so nothing is lost.
- Shared reference data. A "passport" for every customer and product: one identifier across all systems, with duplicates caught automatically.
- Exchange log. The system's flight recorder: every data transfer is recorded, so the question "where did this number come from" always has an answer.
The first two mechanisms are responsible for speed, the second two for trust in the data. A system without queues and a log works only until the first failure.
What approaches to integration exist, and how do they differ?
There are four working approaches: direct system-to-system connections, intermediary integration platforms, a data bus, and replacing the whole sprawl with one shared system. The choice depends on the number of systems and the cost of failure: the more connections and the more expensive an error, the more important a centralized solution with queues and an exchange log becomes. For two or three systems, direct connections are enough; beyond that, a data bus pays off.
| Approach | What it is in simple terms | When it fits | Weak spot |
|---|---|---|---|
| Direct connections ("point-to-point") | A bridge between two specific systems | 2–3 systems, simple scenarios | The number of bridges snowballs: 5 systems may need 10 of them |
| Intermediary platform (iPaaS) | A subscription "translator" service that connects systems using ready-made templates | Standard scenarios, quick hypothesis testing | A complexity ceiling; data passes through someone else's cloud; the subscription gets more expensive with volume |
| Data bus | A "sorting center": all systems connect to one hub that knows the route of every parcel | 4+ systems, non-standard logic, high cost of error | Requires design work and a development team |
| One "mega-system" instead of all of them | Moving the entire business into a single product | Processes are standard, and you're ready to adapt them to the system | Slow and expensive; processes bend to someone else's logic; everyone has to be retrained |
Hybrids are common: a standard connection can stay on an intermediary platform, while money-critical flows run on the bus. We design systems on a data bus as custom development: with queues, an exchange log and monitoring, on your infrastructure, so that a failure in one service doesn't bring down the rest.
Can 1C be connected to a CRM, a bank and Telegram?
Yes, it's the most common combination in Russian business. Starting with version 8.3.5, the 1C platform has built-in exchange mechanisms: HTTP services and the OData protocol, through which external systems read and write data without modifying the configuration. Banks provide statements via API, CRMs accept inquiries, and Telegram serves as a channel for notifications and bots.
A heavily customized 1C configuration isn't a dead end: an adapter is written for it, an intermediate translation layer between your database and the rest of the system. Everything starts with an audit of the specific database: which data originates where and who needs it next.
A separate word about Telegram. According to Mediascope, 55% of Russia's population opens it daily: summaries and alerts arrive where the manager already spends their time, without yet another app. The full standard scenario: a payment arrives at the bank, 1C closes the invoice, the CRM moves the deal forward, the owner gets a message, all within seconds and without a single copy-paste.
How do you connect 1C and a CRM so you don't have to transfer data by hand?
Connect 1C and the CRM through a ready-made module, an API or an intermediate integration layer, after deciding which system is the system of record for each type of data. First map the objects and fields, then run a test exchange and check for duplicates, errors and statuses. After reconciliation, extend the exchange to documents and users.
System of record and objects
Decide in advance where products, stock levels, customers, deals and documents are stored.
Exchange method
Choose a module, API, intermediary platform or batch export based on the number of systems, frequency and data requirements.
Test run
Map the fields and check for duplicates and errors on a limited volume before turning on the full exchange.
Common mistakes in integration projects
Four mistakes recur from project to project: syncing everything with everything without a system of record, undefined rules for resolving conflicts, fragile connections without queues and retries, and no exchange log. Each is built in at the start and surfaces months later as data discrepancies that nobody can explain anymore. All four are addressed at the design stage.
- Syncing everything with everything. Each type of data needs a system of record, a single source of truth: accounting owns money, the CRM owns customers, the warehouse owns stock. Other systems read the data but don't overwrite what belongs to another.
- Ignoring conflicts. What happens if a record is changed in two systems at the same time? The rules for resolving such conflicts are defined during design; otherwise each case has to be sorted out by hand.
- Building on fragile connections. Without queues and retries, a single service outage is enough for the data to drift apart. A queue turns a failure from an emergency into a delay of a few minutes.
- Not keeping an exchange log. The system works, but nobody understands exactly how, and the team is afraid to touch it. The log makes every number explainable.
What if a service has no API?
The data is extracted by workarounds: parsing emails and documents, reading export files, or scraping, where a program "reads" a page or document the way a person would, only fast and without getting tired. Unstructured formats (scans, PDFs, free-form emails) are now handled by AI: it extracts amounts, dates and product items from them with accuracy sufficient for accounting with human review.
The classic example of a "system without an API" is Excel spreadsheets, where half of a company's records live. They can also be connected to the system by parsing files, but more often this is a sign that it's time to move that area into a proper system: we covered seven signs of that moment in the article when it's time for a business to move off Excel.
One-off utilities for tasks like these (an export converter, a price list parser) can now be built in an evening with the help of AI: we covered how this works and where the method's limits are in the article on vibe coding. In a permanent system where errors cost money, such utilities are replaced with engineered adapters with queues and a log.
How do you stay compliant with 152-FZ when connecting systems?
Keep the data in Russia and check whose server the exchange runs through. Since May 2025, a company's first personal data leak costs it a fine of 3–15 million rubles, and a repeat leak a turnover-based fine of 1–3% of annual revenue. Integration is exactly where customer data starts moving between systems, and the route of that movement needs to be controlled.
The main pitfall is intermediary platforms: data physically passes through the platform's cloud, which is often located abroad. For inquiries containing names and phone numbers, that already falls under 152-FZ. Before connecting any intermediary, it's worth answering one question: where geographically will a copy of your data end up?
A system on your own infrastructure or on servers in Russia settles that question: data moves directly between your systems, access is restricted by role, defining who sees and changes what, and sensitive information doesn't leave the perimeter without approval.
Which connection should you start with?
With the most expensive manual one. Usually that's connecting the bank with accounting (the accountant posts payments by hand), inquiries with the CRM (leads get lost in chats), or the warehouse with sales (managers sell what isn't in stock). One connection takes weeks of work, the effect is visible immediately, and from there the system grows one step at a time.
A plan for the first step:
- List every place where data is transferred by hand: from the bank to accounting, from email to a spreadsheet, from a spreadsheet to 1C.
- Calculate the cost of each transfer: employee hours per month plus the cost of errors and lost inquiries.
- Choose the one connection that leads in cost and assign a system of record for that data.
- Run the exchange in parallel with the manual process: for a couple of weeks the numbers are reconciled, and trust in the system grows.
- Add monitoring: an exchange failure should be visible on the day it happens, not a month later through discrepancies.
A connected system is the foundation of management reporting: when data flows on its own, the owner's dashboard shows the state of the business in real time, without waiting for the monthly report. And where integrations fit on the overall map, from choosing the first process to AI, we covered in the guide “Business automation: where to start”.
The systems we connect accounting, CRMs, banks and messengers with are listed on the “Integrations” page. If you want to start with an audit of your own tool sprawl, tell us about your task: we'll identify which manual connections cost the most and propose a plan with a goal measured in money. We build the system on your infrastructure or on servers in Russia and support it after handover: the adapters are updated when external services change.
Sources
- Okta: Businesses at Work 2025 — the average number of apps per company has reached 101
- MuleSoft: Connectivity Benchmark Report 2025 — 897 apps at a large enterprise, 29% integrated
- SberAnalytics and Sber Business Soft: a study of automation in Russian companies, November 2025
- hh.ru: survey on time spent on non-automated reports and reconciliations, 2025
- 1C: Developer Guide, Chapter 17 “Integration with external systems” — HTTP services and OData
- ConsultantPlus: fines for personal data leaks from May 30, 2025
- Mediascope: data on Telegram usage in Russia, 2025
Frequently asked questions
We run an old, heavily customized 1C configuration. Can it be integrated?+
In the vast majority of cases, yes. Since version 8.3.5, the 1C platform natively supports data exchange through HTTP services and the OData protocol, and for heavily customized configurations an adapter is written: an intermediate layer that translates your database's data into the language of your other systems. The project starts with an audit of your specific database.
Is integration safe? Will our data pass through third-party services?+
It depends on the approach. Intermediary integration platforms route data through their own clouds, often located abroad, which is a risk for personal data under Federal Law 152-FZ, Russia's personal data protection law. A system built on your own infrastructure or on servers in Russia removes that risk: data moves directly between your systems, access is restricted by role, and sensitive information does not leave the perimeter without approval.
What happens if one of the services changes its API?+
The exchange with that service stops, but with the right architecture no data is lost: it accumulates in a queue and is delivered once the adapter is updated. That is why the system needs monitoring, so a failure is visible immediately rather than a month later through discrepancies, and ongoing support: a team that updates the adapters when external services change.
How is integration different from switching to a single all-in-one system?+
Integration keeps the tools people are used to and connects them through data exchange, so the rollout happens step by step, one connection at a time, without stopping work. Switching to a single system means data migration, retraining every employee and months of implementation. It is justified when your current systems duplicate each other or are on their way out, not when they are simply poorly connected.
How long does the first integration take?+
Connecting two systems takes weeks, not months: for example, automatically posting bank payments to the accounting system or passing website inquiries into the CRM. The timeline depends on data quality and on whether the systems have APIs. The benefit appears with the very first connection, and from there the system grows one step at a time.