Why Bitrix24 certification drags on and what breaks
Rejection during certification of an app for the marketplace is almost never related to the fact that it does not work.
What fails the check is behavior in non-standard scenarios: revocation of permissions, repeated authorization, deletion of an employee, a delayed response from an external service.
Being sent back for rework is another round of review, and the installations already running at clients remain on the previous version all this time.
The most common cause is unclosed access permissions. The app requests more permissions from Bitrix24 than it actually uses, and some of them are not revoked upon deletion.
The marketplace requirements here are direct: the set of permissions matches the operating logic, and disabling the app removes all granted accesses and stops background scenarios.
The second group is unhandled errors and lack of logging. If the app crashes on an empty response or on an expired access, the reviewer sees a service failure.
Without an event log, the cause cannot be reproduced or presented during review — the vendor cannot prove that the failure was a one-off.
The third group is privacy: storage of personal data, transfer to external services, absence of a deletion policy when disabled. Here rejection costs the most — the data schema has to be rewritten, not just a handler, and this takes weeks while clients run the old build.
We explain how to close these causes before submitting for review.
What a certified app provides: speed and rejections
Publication timelines: from build to storefront
Review during publication follows a fixed list of requirements: access permissions, error handling, storage handling, correct lifecycle of installation and deletion.
We close this list before submission, so the review cycle is usually one — publishing to the Bitrix24 storefront takes days, not weeks of correspondence with moderation.
The number of rejected builds drops by a multiple
A returned build means an extra cycle: fix, new build, repeated queue. The main causes of rejection are removed in advance: unpredictable behavior without granted permissions, uncleared data after app deletion, crashes at boundary values.
The share of versions going to a second and third attempt falls severalfold — and with it, the time to first publication.
A class of installation rejections disappears
Installation on a clean portal should not require manual actions. We run scenarios on an empty account, during reinstallation, and when updating from a previous version — from this class disappear “did not install,” a blank screen, and conflicts with already connected solutions.
Only failures on the client’s external systems remain, and they can be read in the logs from the first request.
Support is unloaded from routine requests
When installation, update, and deletion are predictable, the main flow of “help me install and configure” requests dries up on its own. The team’s freed-up time goes to meaningful enhancements — for the client’s specific processes, not to sorting out recurring failures.
Ways to pass Bitrix24 certification: what to choose
Bitrix24 certification is not a single scenario but a choice of route depending on what you have at the start: a ready-made build, your own code, a working product outside the platform’s perimeter, or an external service.
We analyze this before starting: a wrongly chosen path costs weeks of rework already at the review stage.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made build | Quick entry is needed, logic is standard and matches the typical | Little controllability: changes are possible only within the boundaries set by the vendor |
| Custom development from scratch | The logic is unique and constitutes the product’s value | Longer cycle to publication, higher requirements for documentation and completeness of description |
| Enhancement of an existing solution | The code works but has not passed review | Requires code analysis and alignment with platform requirements; some modules are rewritten |
| Migration of an external service into the perimeter | The service already works at clients on its own hosting | Rebuilding authorization, access permissions, and data exchange to platform rules |
Limitations here matter more than speed. A hybrid is a workable scheme: take a ready-made build and add only your own logic, leaving the updatable framework untouched.
If the service already lives outside, we first assess what can be migrated and what will have to be rebuilt — this determines the route.
Certification stages: from code audit to publication
Certification in the marketplace is not a one-time application submission but a sequence of engineering work where each step closes its own class of review failures on the portal side.
The order is critical: if access permissions are adjusted after running the scenarios, the results are nullified and testing starts over.
- App code audit — static analysis and manual review of event handlers, calls to external services, cache handling, and queues. We look for blocking calls in user scenarios and places where an external service error breaks the interface.
- Integration schema — a map of external calls with failure points: timeouts, retries, behavior when a third-party service is unavailable, and the volume of data transferred per session.
- Environment setup — an isolated perimeter with a separate portal and data, access keys, installation and deletion handlers, so the app can be installed on a clean system without manual administrator actions.
- Access permission adjustments — we reduce requested permissions to the minimum necessary for the declared scenario: extra access areas slow down review and deter those who install the app.
- Marketplace test perimeter — running on several editions and plans, first-launch scenarios, updates from the previous version, and full deletion.
- Publication checklist review — reinstallation, correct migrations, error logging, interface responsiveness, texts and descriptions of the card.
- Handover and support — release of updates, handling reviewer comments, responding to user requests after publication.
Review comments send you back to the first step, so we keep the code audit and publication checklist in one regulation: this way, rework does not turn into a new testing cycle.
Artifacts and documents the client retains
After the app is delivered to the marketplace, the client is left alone with the code, settings, and questions from their own support.
To keep the app from turning into a “black box” accessible only to its authors, we hand over a package: it is enough to understand the design, repeat the installation, update the version without us, and pass re-review at the next publication.
- App documentation — which scenarios it covers, which portal entities it reads and which it modifies, what the interface consists of, and what happens when an external service fails.
- Integration schema — call directions, external systems, failure points, and behavior when each of them is unavailable.
- Access policies — roles, permission areas, separation of read and write rights, procedure for storing and replacing access keys.
- Environment configurations — a list of parameters for production and test perimeters, what is moved into variables, what cannot be changed without re-review.
- Installation and update regulations — step-by-step procedure for version publication, data migration, conditions and boundaries of rollback to the previous one.
- Support regulations — response times to requests, planned maintenance windows, who receives notifications and for which events.
- Pre-publication checklist — permission checks, error handling, running scenarios in the test perimeter, readiness of the new release description.
- Change and request log — what changed and when, which reviewer comments have already been closed, so as not to repeat the analysis.
The package is maintained in the repository alongside the code: changes to the regulations go through the same review as the code itself, so the documents do not diverge from the app’s actual behavior.
Case study: how the app passed review on the second attempt
What it was like before review
The app went to certification in Bitrix24 with a working core but did not pass review. Analysis of the comments revealed two groups of causes: excessive access permissions — the app requested sections it did not use — and unhandled installation scenarios.
Interrupting installation midway, re-running over the previous version, and deleting the app left the portal in an unpredictable state: some data remained, some settings did not fully roll back.
Fixing comments and re-review
We narrowed access areas to those actually used and split the permission request into stages: basic ones at installation, the rest upon user action, with an explanation of why the access is needed.
Installation was made idempotent: a repeated run does not duplicate entities and does not break an already configured portal, and app deletion cleans up everything created. Each step received logging and a specific error message instead of a generic failure.
Before re-review, we ran the app on a clean portal, on a portal with the previous version, and on a portal with partially configured data.
Metrics before and after: the share of installation scenarios covered by automated checks grew from 40 to 90%, access permission comments at re-review — zero, installation on a prepared portal takes a minute instead of crashing with an error.
Support requests about installation after publication stopped — typical failures are closed at the code level, not by instructions for the administrator.
How do marketplace requirements differ from internal code review?
Internal code review answers the question “is this convenient for us to support”: style consistency, module boundaries, test coverage, absence of duplication.
The review criteria here are set by the team itself, and it also defends contentious architectural decisions — this logic does not go outward.
Marketplace requirements are structured differently: the reviewer knows neither your codebase nor its history and evaluates the app as a black box.
They deploy it on a clean portal and go through installation, deletion, and reinstallation scenarios, checking whether tables, files, scheduler jobs, and access permissions remain after uninstallation.
Code style and library choices do not interest the reviewer — what matters is what the app does with client data and the portal itself.
Hence the shift in emphasis: requested permissions must be minimally necessary and justified, every call to an external service described, and errors handled so that an app crash does not take the portal down with it.
Special attention is paid to offline behavior, conflicts with other apps, and operation in cloud and on-premises editions.
Practical conclusion: code that has passed internal review is not yet ready for submission.
Before sending, we run installation scenarios on a clean portal, bring installation and deletion scripts to a repeatable form, remove unnecessary requested permissions, and describe every outgoing connection in the documentation.
Checks, logging, and data privacy: contentious points
Contentious issues during certification are almost always not about the app’s features but about data handling: what settles in the logs, who has access to them, what happens when an external service fails, and how an already published version lives. Below are short answers to what most often comes up in dialogue with the Bitrix24 committee.
What exactly should be logged, and for how long should it be stored?
We write events that affect trust in the app: login, permission changes, calls to external services and their result, exchange errors. We do not copy personal data into the log — only the record identifier. The retention period is set by policy: it should be enough to investigate an incident by time.
Who inside sees user data?
Access is role-based: the developer can see the schema and metrics but not the content of records. If context is needed for investigation, it is granted for a limited period by the app owner. Data privacy stops being a contentious review point.
What should be done with external dependencies?
We isolate them: limit waiting time, set retries with pauses, and move failed tasks to a queue for redelivery. The user sees a clear status instead of a blank screen.
How do you update an already published app?
First we test the build in a test perimeter where the current production version is installed, then we publish. We change the data schema only with backward compatibility — rollback to the previous version does not break already created records.
Let’s discuss the task and come back with an estimate and plan
To start the estimate, a working Bitrix24 portal with administrator rights, a list of methods the app calls, and a list of plans where it should work are enough.
Plus the contact of the person responsible for acceptance and draft developer details in the catalog — they are needed already at the submission stage. There is no need to assemble a full documentation package in advance: we analyze the code and settings ourselves.
The work plan comes as a document with stages, timelines, and approval points. It marks what we do and what is required from your side at each step. After publication, we hand over the result: accesses, instructions, and an update policy.
- analysis of the app and a list of discrepancies with catalog requirements;
- estimate of certification work broken down by stages and risks;
- work plan: checks, timelines, responsible parties, approval points;
- list of what is needed from the client at each step;
- test protocol with the procedure for reproducing detected defects;
- submission package: description, icons, screenshots, texts;
- handover of the result: accesses, instructions, app update policy.
To come back with an estimate and plan, describe the task: what the app is, which scenarios it covers, and which plans it works on. Then we will agree on a call and the project start dates.