Custom CRM integration or an existing connector: how to choose
Consider custom CRM integration when the existing solutions you have tested do not meet the agreed exchange scenario and the systems' interfaces support implementing it. If a connector supports the required records, operations and diagnostics, start by testing it. A custom field alone does not mean you need a separate service.
For a project manager, the decision can be divided into three steps: describe one business scenario, test it with an existing solution, and request an estimate for the missing work. Compare the same outcome, including error handling, acceptance and support after launch.
Below are a connector evaluation matrix, discovery deliverables and questions about estimates. They apply to connecting a CRM with an accounting system, a document service or another application. Costs depend on the specific constraints; the examples illustrate a decision process without market rates.
Start with the action the business needs to perform
Describe the event, source record and result in the other system. For example, approving a deal in the CRM creates an order in the accounting system, and its number and status are returned to the manager. Specify who approves the action, when it is permitted and what should happen if it fails.
The phrase 'connect the CRM to 1C' leaves important questions unanswered. Do you need orders, invoices, payments, inventory or only a client directory? Can both systems change the data? Can a manager correct the result manually? Without these answers, two contractors will estimate different work.
Start with one complete scenario. List additional exchange flows separately: they may use the same transport mechanism but require different fields, rules and checks. Sending an order and returning payment information each need their own evaluation.
If your task is limited to receiving leads from a website, use the website-to-CRM integration guide. It covers form fields, lead sources and delivery checks. Exchanges between business systems require a description of each record's lifecycle.
When to test an existing connector
A connector is an existing tool for connecting systems. Its capabilities depend on the particular product, version, configuration and terms of use. One may support custom fields and several events; another may cover a narrow standard scenario. Review the documentation and test the selected solution.
Make a short requirements list and ask the contractor to demonstrate how each item is met. 'We have connected this CRM before' is useful background, but it does not confirm the required function in your configuration.
| Item to check | How to confirm it | When additional work is needed |
|---|---|---|
| Required record and operation | Create or change the agreed record in a test environment | The product supports a contact but not the required document or operation |
| Custom fields | Transfer values with the required types and mandatory fields | A field is unavailable in the settings or the transformation exceeds the product's capabilities |
| Exchange direction | Test the initial action and the confirmation returned | Required behaviour in both directions is not implemented |
| Error detection | Obtain a clear message and a diagnostic record for the responsible person | Errors are hidden or failed operations cannot be located |
| Reprocessing | Test the same event again and recovery after a failure | Required retry rules are missing or unconfirmed |
| Integration operation and support | Check access, documentation, updates and the support process | No one is responsible for maintaining settings or changes to an external API |
Record an unknown item as a question. A lack of confirmation is neither a reason to reject the solution immediately nor grounds for promising that the feature exists. Sometimes clarifying the settings or conducting a short test with the vendor is enough.
If the complete required scenario passes acceptance checks, compare configuring the product with custom development in terms of support costs and project constraints. Custom code remains an option for specific unmet requirements.
What to check in the API before custom development
An API is an interface through which programs perform permitted actions and retrieve data. A CRM's advertised API does not establish whether the required record is accessible, which fields can be changed or whether the necessary operation is supported.
Ask a technical specialist to confirm the following using test access:
- reading and changing the required records;
- availability of custom fields and status values;
- ways to detect changes and retrieve their results;
- access restrictions, request rate limits and data size limits;
- rules for validating required data;
- how to obtain diagnostic information when an operation fails.
For example, the standard 1C REST interface allows metadata requests and operations on application records through OData. This is a platform capability. The necessary records, permissions and permitted behaviour still need checking in the client's specific configuration.
The 1C documentation contains an important detail: reading and writing through this interface performs the usual permission checks and event handlers, except for field completeness checks. The availability of a write operation therefore does not establish that all your scenario's business rules are validated. Include required fields and the consequences of a change in discovery and acceptance.
A custom service also depends on the available interfaces. If the external system does not permit the necessary operation, first determine whether it can be extended or whether another supported exchange method is available. A promise to 'write an API and make everything work' leaves the central risk unresolved without this check.
How to run a short test before a full estimate
Choose one representative scenario and test data. The aim is to confirm that the exchange is feasible and identify constraints that affect project scope. This could involve configuring a connector, building a small adapter prototype or checking operations against documentation and a test system.
Follow this sequence:
- Create the agreed source record with its required fields.
- Transfer it using the selected method and find the result in the destination system.
- Check the linking identifier and any required confirmation returned.
- Repeat the action according to the agreed scenario and check the result.
- Cause a controlled failure in the test environment and locate it in the diagnostics.
- Record constraints and the work needed for a full implementation.
Do not run the experiment on production data without a separate plan. An anonymised example, a test environment and permissions for the necessary operations are sufficient for a preliminary check. Access credentials and secrets should be sent through an agreed channel separately from the general brief.
OWASP recommends limiting permissions to necessary actions and checking authorisation when protected resources are accessed. Define whose identity the integration uses and which records it may read or change. Broad administrative access should not be treated as a permanent requirement for the exchange.
This test does not replace full acceptance, load testing or operational readiness. It should produce confirmed capabilities and a list of unresolved conditions that help the contractor refine the estimate. Exchange mechanisms are explained in more detail in the CRM architecture and integration guide.
What discovery should deliver
Ask for a separate document containing the findings. Meetings and message threads alone are awkward for comparing proposals: an important agreement may remain in a private conversation.
| Discovery deliverable | What to record | How it supports an estimate |
|---|---|---|
| First release scenarios | Event, user, starting point and final result | Defines launch scope |
| Record and field map | Data source, mapping rules, required fields and identifiers | Identifies transformations and validation |
| Exchange method evaluation | Confirmed connector or API functions and a demonstration reference | Separates configuration from development |
| Unresolved conditions | What is unknown, how to establish it and who supplies the data | Allows discovery to be estimated as a separate stage |
| Failure and recovery rules | Where errors are visible, who investigates and how work resumes | Adds diagnostics and operation to scope |
| Acceptance plan | Data, actions, expected result and responsible person | Makes completed work verifiable |
After discovery, each mandatory requirement should have a status: confirmed, to be implemented as a separate task, or requiring a further decision. For the last category, identify the dependency and the owner of the next step.
If needed, agree on a limited first stage. For example, start with one document type and one direction, then add statuses and reverse updates. The division should preserve a useful first release rather than leave the manager with half an operation.
How to compare configuration, extensions and a separate service
Ask for estimates covering the same mandatory scenarios for each approach. Include testing, documentation, access and responsibility after system updates, as well as initial implementation. Check subscription and support terms with the selected vendor at the time of the estimate.
| Approach | What the project may include | What to clarify before choosing |
|---|---|---|
| Configure an existing solution | Configuration, field mapping, scenario checks and instructions | Supported functions, restrictions and the product's operating terms |
| Extend a connector | Configuration plus changes to parts of the product that may be modified | Extension options, update compatibility and ownership of maintenance |
| Build a separate integration service | System adapters, exchange rules, diagnostics, tests and deployment | Infrastructure, access, documentation and support ownership |
An estimate for a separate service should state what each stage delivers: what is investigated, what is implemented, which checks are performed and what is handed over. A line labelled 'CRM integration' without scope does not allow meaningful comparison.
More systems do not always require a completely custom implementation. Equally, two systems do not make a task simple: one change may depend on document approval, roles and a rule preventing data from being overwritten in reverse. Complexity comes from the rules and available operations.
For the overall project structure, use the CRM development cost guide. When integrating an existing CRM, the estimate should show the exchange and necessary changes separately so that an unagreed platform replacement is not included.
Who is responsible after launch and system updates
Assign responsibilities before release. The CRM owner is responsible for its configuration and permitted changes, the accounting specialist for that system's configuration, and the integration contractor for the agreed integration layer. Exact obligations depend on the contract and team.
| Situation | What to agree in advance |
|---|---|
| A field or status changes | Who reports the change, assesses its consequences and updates the data map |
| An external API changes | Who follows vendor notifications and checks compatibility |
| An operation fails | Who receives the alert, where they investigate and how the question is passed to the other party |
| An operation needs reprocessing | Who may initiate it and which data confirms the result |
| The contractor changes | Which source files, settings, instructions and access are available to the new team |
Receiving custom source code helps a team continue the project, but dependencies on an external platform's API, infrastructure and team expertise remain. For an existing product, also check what settings can be exported and whether maintenance can be transferred.
At launch, provide a short guide explaining how to find a failed operation, what to check first and whom to contact. Known limitations should be available with the documentation rather than only to the developer who built the integration.
Two illustrative choices
First scenario: a change to a deal's status in the CRM needs to send agreed fields to another system. The selected connector supports the record, transformations and confirmation returned; test data passes the checks, and the responsible person can find and investigate errors. There is a basis for estimating configuration and support of the existing product. Separate development would need its own justification.
Second scenario: creating a document requires approval by several participants, checks on related records and a result returned to the manager. Some operations are unsupported by the selected product. Discovery confirms that the necessary actions are available through the systems' interfaces. Compare extending the product with a separate adapter against the same scenario, acceptance checks and support needs.
If discovery has not confirmed the necessary operations, the second scenario remains unresolved. The next step is to agree on system or process changes. An estimate for the full exchange before that decision will depend on assumptions.
For a verified existing solution, discuss implementation of CRM. For a custom integration layer and necessary changes, consider CRM and feature development. The initial request should state the systems, action, expected result and known constraints.
FAQ
Can an existing connector be extended instead of building a separate service?
That depends on the product's terms, extension options and support for modifications. Ask how the extension will be implemented and check that it survives updates. Compare its maintenance with a separate integration layer covering the same scope.
Does a nonstandard exchange require replacing the CRM?
First check the existing system's interfaces and constraints. If the required scenario can be implemented through supported operations, replacement is not a mandatory condition. If capabilities are missing, evaluate process changes, platform extensions and replacement separately.
Can I get an estimate without granting access to the systems?
A preliminary estimate can use documentation and a task description with explicit assumptions. Confirming a complex scenario requires operation checks, test data and a technical representative from each side. Estimate discovery and subsequent implementation separately when constraints remain unknown.
Sources
Documentation checked on October 11, 2026. The decision matrices, discovery deliverables and two scenarios are recommendations and illustrative examples; they do not describe NBM-IT project results or the capabilities of every connector.