Why an app from Bitrix24 Market conflicts with the portal
The portal runs stably for months — and stops after an app is installed from the catalog.
Data exchange with the accounting system shows discrepancies, some employees lose access to their sections, and the log contains messages from someone else's handler instead of a clear error.
Formally, everything succeeded: the portal update was applied, and the app installed without errors.
The reason is that installing apps in Bitrix24 Market is almost never isolated. An app registers its own event handlers, adds fields to entities, and subscribes to changes in deals, tasks, and users.
If your exchange with the accounting system is already subscribed to the same event, the execution order is unclear: the action runs twice or does not run at all — this is an integration conflict.
A separate issue is app access rights. To work, an app requests access to entities and often receives broader access than its stated function. Role separation then drifts: an employee sees extra sections, and built-in checks stop being the only control point.
Then a delayed effect kicks in: a portal update changes the behavior of methods, the app is not ready for it, and what worked for years breaks.
It is impossible to find the trigger without an event log and step-by-step disabling of subscriptions — so we start with a map of handlers and rights, not with reinstallation.
We explain how such a failure is localized and what to check before installation so you do not catch it on a live portal.
What changes after putting apps in order
Order in apps is not a one-time cleanup but a framework: a list of approved solutions, an update policy, and an installation log.
Bitrix24 Market has built-in mechanisms for this, but the effect appears when they are enforced by rules rather than held in the administrator's memory.
Updates stop breaking the portal
An update first goes through a test environment, then is installed in a low-load maintenance window, with a rollback point to the previous set.
The share of failures after installation drops from "every other one" to isolated cases, and the cause of each is visible in the installation log — reproducible, not guesswork.
Installation and decommissioning timelines become predictable
It is clear which rights an app needs, which entities it works with, and what will remain after removal. Installation and decommissioning fit into a preannounced window, rather than stretching indefinitely due to hidden dependencies.
Support workload decreases
Typical requests — "it broke after an update," "who installed this app," "why did rights increase" — are closed with a reference to the policy and log.
Eliminating a class of failures frees the team's time for development tasks instead of dealing with consequences.
Portal stability stops depending on one person
Rules, roles, and the update approval procedure are fixed, so replacing an administrator or contractor does not stop operations. The set of apps and their versions are always known — this is app management as a process.
Connection formats: an app from Bitrix24 Market vs. custom development
The fork appears at the start: cover the need with a ready-made solution from the catalog or build your own. The answer depends not on the size of the task but on the share of unique logic in it and how often that logic will change.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made app from Bitrix24 Market | Standard need: communication channel, reporting, exchange with an external service | Logic, fields, and rights are limited by the app developer's settings — a non-standard rule cannot be added here |
| Custom development | Your own policies, integration with the accounting system, roles absent from the standard model | Longer design, testing, and acceptance; platform updates are maintained by us |
| Hybrid | A ready-made core covers most of the task, while a bottleneck requires customization | Edits in third-party code: an app update may overwrite them |
We separately check how the chosen option will survive a platform update. Ready-made apps are updated by their developer, but not always on a schedule convenient for us, while custom code requires rerunning scenarios with every release.
In practice, the choice is rarely binary. We break down requirements point by point, mark what a ready-made app covers, and leave custom code only where it produces a measurable effect: processing speed, removal of manual operations, custom access rules.
This keeps the support scope predictable and prevents the system from becoming overgrown with duplicate modules.
Implementation procedure: from audit of installed solutions to handover
Before changing the production portal, we record the current state: which apps are installed, who authored them, which rights they requested, and what is actually used.
Without an inventory, installation turns into a lottery — a version conflict or excessive access surfaces after launch.
- Portal audit — we export the list of apps, webhooks, business processes, and robots. We mark duplicates, unused solutions, and excessive access rights: we get a risk map.
- Relationship diagram — we show how solutions exchange data with CRM, tasks, and Drive: where the source of truth is, where duplication exists. We agree on the diagram before work begins.
- Implementation plan — stages with the correct installation order: first dependencies, then add-ons. We fix what is migrated and what is disabled.
- Test environment — we deploy a copy of the portal structure and run rights, roles, and scenarios on it. Errors do not reach the production database.
- Integration check — we run end-to-end scenarios in full: request, deal, invoice; task, notification, report. We verify exchange with 1C and exports to analytics.
- Documentation handover — we provide policies: app inventory, owners, update procedure, and actions in case of failure. Plus employee training.
Then the portal lives by these policies: new apps are installed according to the described procedure, not "on the fly."
What remains in the customer's environment: artifacts and policies
Configuring Bitrix24 Market is not only installed apps but also the management layer for them that remains with you. After handover, the customer has a set of artifacts that the internal team can use to install, update, and remove apps without contacting us.
- Integration diagram: which apps are connected to the portal, through which accounts and rights, where access keys are stored, and who is responsible for rotating them.
- Access rights matrix: administrator, integrator, and employee roles with the minimum sufficient set of rights — app installation is separated from access to data.
- Update policy: where new versions are checked, in which window the update is installed, who makes the decision, and under what conditions a release is postponed.
- Rollback policy: a configuration snapshot before changes, retention period, responsible person, and criteria for initiating a return — a failed update becomes a planned operation, not an incident.
- Team instructions: step-by-step guides "install an app," "grant access," "disable an integration" with the expected result at each step.
- Change log: what changed in Market and when, who made the edit, what data remains on the portal after app removal.
- Responsibility map: who on the customer side makes decisions about apps, whom to contact during a failure, and who stores access credentials.
These documents live together with the portal: when an administrator changes, during an audit, or when bringing in your own engineer, context is restored from records, not from memory.
Case study: a portal with dozens of apps moved to managed updates
The customer's portal is a corporate system with several dozen apps from Bitrix24 Market connected to it: tasks, document flow, reporting, and data exchange with external services.
They were installed and updated manually: the administrator deployed a new version directly to the production portal and learned about conflicts from employee requests. Every update turned into evening work with the risk of restoring from a backup.
What the metrics showed before
Out of two dozen updates per quarter, every third ended in a rollback: a mismatch between core and app versions broke business processes.
Portal downtime in such moments reached several hours, and support spent more than half its time dealing with consequences instead of developing the system.
There was no single picture of what was updated and when — lists were kept in a spreadsheet and diverged from the actual state.
What was changed and what the result was
We assembled a managed environment: a test portal with a copy of data, where an update is checked before release to production, a fixed installation order, a rollback point before each change, and a log for each app. Updates became planned — with a window agreed with the business.
The share of rollbacks dropped from a third to isolated cases, and returning to the previous version takes minutes instead of restoring from a copy. Support requests on the topic "the module broke" decreased by about three times — the freed-up time went to improvements. Responsibility is fixed: each app has an owner, a current version, and a record in the change log.
What to do if the portal is already loaded with third-party apps?
A portal that has been running for several years almost always has accumulated apps from Market and customizations: some tasks are already covered by other tools, some hold outdated access rights, and the administrator does not remember who installed them.
The legacy of integrations is dangerous not because of quantity but because the connections between apps, robots, and business processes are not described anywhere.
We start with an app inventory: we collect the list of installed items, requested access scopes, owners, and, most importantly, who calls each app.
The source is request logs and portal events, not the team's memory: this reveals both apps with no calls for months and those quietly working in the background.
Next is managing decommissioning risks. We move an app into observation mode: disable active scenarios, keep the data, and for two to four weeks monitor logs for errors and requests.
We check version compatibility separately: some apps are tied to a core version and start returning errors after a portal update, so we first run them on a copy.
We build phased decommissioning on the principle "replacement first, shutdown second": duplicates and apps with no calls, then those whose logic is covered by built-in robots and business processes, and only then those requiring data migration. At each step there is a rollback point: a portal copy, saved settings, and keys.
Order is established without stopping business processes: the portal remains operational, the load from unnecessary apps decreases, and support gets an up-to-date integration map.
Common technical objections to app installation
Most doubts arise not around installation itself but after it: what will happen to the running portal, who is responsible for updates, and whether exchange with 1C will suffer. Below are answers to the most common questions before connecting an app from Market.
Will installation stop the portal?
No. The app is installed on a running portal and does not require putting it into maintenance mode. Risk appears only where an app overrides built-in handlers or accesses the core — we check such cases separately and schedule them in an agreed work window.
Will the app stop being updated?
Before installation, we check the last build date, edit history, and support activity. If the app is abandoned, we deploy it in our own environment and take over updates — we monitor compatibility with the current platform branch ourselves.
Will this affect data exchange with 1C?
Built-in apps work through the same handlers as other modules and do not touch exchange rules. We record the exchange scheme before installation, then run a test exchange and verify the set of attributes on both sides.
How do you check app security?
We look at requested rights, external addresses where data is sent, and whether encryption is used in transit. An app that needs access to the entire portal for one button is a reason to refuse it or reduce its rights to the minimum.
What about licenses and who is responsible after handover?
The license is issued for your portal, not for our account — if the contractor changes, access remains with you.
After handover, you receive the installation scheme, a list of apps with rights, and the update procedure; we provide support according to the policy, not on an ad-hoc basis.
Let's discuss the task: we will prepare a plan and estimate for your portal
To make the work plan based on facts rather than general considerations, we start with a portal review: we look at which apps from Bitrix24 Market are already installed, who authored them, and how they are updated.
After the review, you see the full picture — what is currently in place, what duplicates each other, and where an app brings extra rights with it.
Then we fix the boundaries: what we cover in this project and what we put into a separate stage so the scope does not creep during the work.
- What we look at on input: administrator access, portal structure, list of installed apps and their sources, role-based access separation.
- How we describe the scope of work: installation, update, replacement, or removal of apps, role setup, integration with the accounting system.
- Estimation procedure: by stages, with dependencies between them and a clear separation — what we do, what remains on your side.
- Project stages: portal review, scope approval, work in the test environment, migration to the production portal, acceptance, handover of policies.
- Acceptance criteria: what we consider the result of each stage and how we check that a new app does not break existing scenarios.
- What form the result takes: work plan, app registry with owners and update procedure, access provisioning rules, instructions for the portal administrator.
Describe the task in free form — what kind of portal it is, which apps are needed, and what is unsatisfactory now. We will come back with a work plan, scope, estimation procedure, and timelines by stage, with approval points at each step.