Implementing Bitrix modules: where a ready-made solution breaks
A ready-made module from the 1C-Bitrix marketplace covers a typical scenario and costs less than custom development — right up to the moment it is installed on a live project.
Installation completes without errors, but a few days later the admin interface starts to "drift", orders are duplicated, and some settings roll back to the "default" state after a core update.
Implementing Bitrix modules is not an "install" button but a separate engineering effort with its own procedures.
The first class of failures is a conflict between the module and the core.
The solution overrides standard events, attaches its own handlers, and overrides template components, and when the core is updated, such overrides are lost or break adjacent logic: the cart stops working, and export to the accounting system falls off.
The second is data duplication: the module brings its own tables, does not link them to existing reference data, and the same product exists in two places with different identifiers.
The third failure is loss of settings: a module update overwrites the configuration if it was not stored in a separate layer but was written directly into files.
The fourth is manual operations that appear instead of automation: data exchange is started by hand, exports are checked by eye, and the entire process rests on one person and their notebook.
We will look at how this is addressed: adapting a ready-made solution to the project architecture, isolating settings from code, updates with a rollback point, and a list of operations that must run on their own.
What changes after configuring modules for your processes
A ready-made module from the 1C-Bitrix marketplace is a blank for a typical scenario, not for yours.
The effect comes not from installation but from implementing modules with adaptation: exchange rules, roles, permissions, and status logic are configured for how your departments actually work. Below are four changes that are visible in metrics.
Release of updates accelerates
Previously, modifications were transferred by hand: an edit on the test environment, repeating it in production, reconciliation from memory. After configuring the module for processes, updates follow a single procedure — migrations, checks, rollback.
Update release time drops from days to hours, and environment drift is visible before deployment, not after a user complaint.
Fewer manual operations
Filling reference data, reconciling request statuses, exporting documents to 1C — these steps were performed by people, and at volume they consumed a working day. Scheduled exchange and event handlers take them over.
The share of manual operations decreases, and the result is the same for a hundred documents and for tens of thousands.
A whole class of failures disappears
Typical failures of an adapted module: crashes on non-standard data, duplicates during repeated exchange, loss of statuses after an update. Input checks, protection against repeats, and logging close this class entirely. Support stops handling the same request month after month.
Modifications are not lost during updates
Modifications are moved to a separate layer, and settings are available from the interface — logic changes in a targeted way, without editing the module code. A new rule is added in one iteration, and the next version from the marketplace does not overwrite your changes.
Ways to adapt ready-made solutions: comparison of options
The choice between a ready-made solution, customization, and custom development is a comparison of adaptation options along three axes: speed of delivery, maintenance cost during updates, and how closely the system behavior matches your processes.
The marketplace covers typical scenarios, but exchange with the accounting system, access permissions, and approval logic almost always have their own specifics.
What to consider when choosing
The key criterion is where the boundary lies between configuration and code modification. As long as we work with settings and event handlers, the module update proceeds without conflicts.
As soon as the core changes, every update turns into a manual merge — and this is the main source of regressions.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made module without modifications | Typical processes, exchange using standard formats, deadlines more important than flexibility | Does not cover non-standard scenarios, some fields and statuses are maintained manually |
| Module with customization | Logic is close to typical, but custom fields, reports, and access rules are needed | Customizations live outside the updatable branch — an update procedure and automated tests are required |
| Combination of several solutions | The task is broader than one module: funnel, warehouse, documents in one environment | Duplicate entities and desynchronization when exchange fails |
| Custom development instead of a module | A unique process that ready-made solutions do not describe | Full responsibility for support and development is on you, delivery takes longer |
In practice, the combination most often wins: a standard module for closed areas and targeted customization where processes differ from the market.
Work sequence: from configuration audit to handover
Installing a module from the marketplace "as is" reveals conflicts with customizations and the core version already on live users.
Therefore, we lead module implementation from a configuration audit: first we record the current state, then configure and test on a copy, and only then migrate.
Work stages
- Configuration audit. We create a map: core version and edition, installed modules, template customizations, custom components, event handlers. The output is a list of intersection points with the new module and a risk assessment.
- Module implementation plan. We decide what to take from the ready-made solution, what to customize, which parameters to move into settings, and which remain in code. We record the order of stages and readiness criteria.
- Test environment. We deploy a copy of the production configuration with the database and files — checks run on real data, not on an empty installation.
- Configuration and adaptation. We connect the module, align it with access permissions, the template, and exchange with 1C; we fix only conflicts that arise, without rewriting the entire project.
- Verification. We run scenarios for roles, orders, notifications, and exchange, including partial and erroneous data. We close defects here — before migration.
- Migration and solution handover. We roll out settings in stages with rollback capability, hand over configuration documentation, and train the administrator in typical operations.
Configurations, access permissions, and update procedures
After project delivery, the client's team has a set of materials with which the system can be developed and maintained without us.
These are not access details in a chat and not verbal agreements, but working artifacts — configuration, relationship diagram, policies, and procedures verified on a database copy and recorded in a version control system.
- Working configurations: configured modules and components with recorded parameters — what is enabled, which values are set and why, and where there is a deliberate deviation from default settings.
- Integration diagram: a map of connections between the site and the accounting system, exchange with 1C, external services, and exchange queues — indicating the direction of data and which side is the source of truth.
- Access permissions: a role matrix for administrator, editor, integration user, and service accounts — with the minimum required set of operations and an explicit prohibition on excessive ones.
- Update procedure: the order for installing core and module updates, maintenance windows, mandatory verification on a database copy before rollout, and criteria under which an update is postponed.
- Rollback procedure: taking a backup before work, database and file restore points, step-by-step return to the previous state, and a way to confirm that the rollback completed correctly.
- Administrator instructions: typical operations — adding a section, publishing, granting access, reading logs — with the expected result at each step.
- Monitoring and logs: which events are considered signs of degradation, where to look when exchange fails, and who receives the notification.
Documentation is updated together with releases — otherwise, six months later the procedure diverges from the actual system state, and the first rollback turns into a blind investigation.
Case study: how a module was connected to the accounting system
A wholesale auto parts supplier came with a task: a catalog on 1C-Bitrix and accounting in 1C lived separately.
Stock levels were updated by a nightly job, managers corrected prices and warehouse quantities by hand, and orders from the site were transferred to the accounting system by copying.
State before work
Discrepancies began to accumulate by midday: a manager reconciled 30–40 items per day, and stock mismatches surfaced in 5–8 orders per week. Each such correction meant a call to the client with apologies and a postponement of shipment.
The export failed 3–4 times a month, most often on items with non-standard units of measurement, and it had to be restarted manually.
What was changed
They did not take the ready-made module "as is" — its exchange scheme did not cover non-standard catalog attributes. They configured reference data mapping, moved items that failed validation into a separate queue, and output errors to a log linked to a specific item. Exchange became frequent, and price and stock are now updated before an order is confirmed.
Metrics after
The share of orders with manual correction fell from a third to isolated cases, and the processing time for one order decreased from half an hour to a few minutes.
Export incidents stopped being regular: one per quarter, and that one was resolved from the log in an hour instead of restarting the entire export.
What to do if a ready-made module conflicts with updates?
A conflict rarely looks like an explicit error. The module edits core files, overrides component templates, or calls methods that no longer exist in the current branch.
Integrity check during an update sees modified files and either stops installation or overwrites customizations — after which functionality unrelated to the update falls off. The deeper the module sat in the core, the more expensive recovery after an update becomes.
Therefore, as a first step we take a rollback point: a backup of the database and files plus a label for the working build. Then the scenario is selected according to the table.
| Action option | When it fits | Limitations |
|---|---|---|
| Isolation of customizations | The module is needed, but the core must update freely | Revision of all modifications, part of the logic is rewritten to use standard mechanisms |
| Module replacement | The task is typical, there is a solution with active support | We migrate settings and accumulated data, re-check compatibility with templates |
| Rollback and re-adaptation | The update has already disrupted the site's operation | The site runs on the previous build while adaptation is underway; without identifying the cause, the conflict will repeat |
| Custom build | The logic is unique, there is no ready-made equivalent | We maintain core changes ourselves with every update |
We make a decision only after reproducing the conflict on a test environment: we look at which files the module overrode, what of this is covered by the platform's standard mechanisms, and evaluate maintenance cost.
Isolation gives the core freedom to update, replacement removes dependence on a single developer, and rollback buys time when the site is already down. After that, updates proceed normally, not through separate approval with the contractor.
Common technical questions about ready-made solutions
Before installing a module from the marketplace on a production site, we check it the same way as our own code: structure, dependencies, calls to the database and external services. Below are the concerns most often raised in technical discussions, and substantive answers.
Is the module compatible with the current build and other extensions?
We deploy a test environment with the same core and the same set of modules as on the production site. Conflicts usually occur in event handlers and template overrides: two solutions intercept the same call or override the same component. We record the check result in a report and resolve intersections by priority.
How secure is the vendor's code?
We look at handling user input, access permissions, and database queries: where there is escaping and permission checking, and where a parameter goes directly into a query. We separately check outbound calls — the module must not transmit data externally without your knowledge. We either close the found issues in our own wrapper or do not take the solution.
Will customizations break the module's updatability?
Modifications live in the local directory and in our own components; we do not touch the vendor's files. Then the marketplace update proceeds without conflicts, and our changes remain on top.
If logic must be changed inside third-party code, we move it to a separate layer and describe it in documentation.
What will the team have after project handover?
We hand over the configuration, dependency diagram, change log, and update procedure — maintenance continues without us. Each customization is described in the repository: why it was made and what it will affect in the next update.
Let's discuss the task: we will select a solution and scope of work
To discuss the task concretely rather than in general terms, we need a minimum of input data.
Gather what you already have at hand — this will be enough for us to return with an estimate of the scope of work and an implementation plan, rather than with clarifying questions for two weeks.
- address of the current site or store and access to the test environment or a database copy;
- which processes should be covered: catalog, orders, prices, roles, exchange with the accounting system;
- what ready-made solutions are already installed and which modules raise questions;
- constraints that must not be violated: procedures, approval order, composition of data exchange;
- priorities by stage and desired timelines;
- contacts on the business side and on the IT side — so that decisions are coordinated without delays.
Then we analyze the current state, compare it with the task, and determine where configuring a ready-made solution is sufficient and where customization is needed.
The proposal comes as a structure of stages: what we do, in what order, what we consider the result of each stage, where the risks and approval points are.
The format is a short document with the scope of work, implementation plan, and acceptance criteria. Describe the task in a convenient form — we will return with an estimate and plan.