Business integrations
Website, CRM, 1C, payments and delivery share agreed data. Orders move from the first enquiry to fulfilment.
Discuss a business integrationExplore the scopeEvery record has a primary source. A repeated event does not create a second order.
Leads, contacts, deals and tasks. Fields, pipelines, duplicates and customer account statuses.
Website leads, contacts, companies, deals and tasks. Map fields and pipelines, define duplicate detection and assignees, and return statuses to the customer account.
CRM and internal workflows. Connection type, permissions and REST depend on the plan and hosting.
CRM, tasks and events for internal workflows. Choose the connection type and check permissions and REST availability under the current plan and hosting conditions.
Orders, products, prices, stock and documents. Exchange mechanisms depend on the version and configuration.
Orders, catalogues, prices, inventory and documents in the agreed configuration. Use available platform mechanisms and define which records are created or updated.
Payments, refunds and delivery. Confirmed statuses, reconciliation and external service failures.
Payment creation, status confirmation, refunds and reconciliation. Submit shipments to the carrier, receive delivery statuses and handle rejections under the selected service rules.
CRM tracks the manager’s work, the accounting system owns documents, and the payment service owns payment state. Agree how these events update the order.
Use phone, email and external identifiers under agreed rules. Resubmitting a form should not create an unnecessary deal.
Returning from a payment form is not the sole confirmation of payment. Check payment state through the mechanism provided by the payment service.
Invalid catalogue items, closed deals or changed stock generate a clear error and correction path. A generic “sent” status must not conceal rejection.
Not every field needs two-way synchronisation. First identify the data owner and the behaviour when changes occur at the same time.
| Source / scope | What we define | Outcome |
|---|---|---|
| Website → amoCRM / Bitrix24 | Lead, contact, source and assignee | Deal with an external identifier |
| 1C → website / app | Catalogue, price and agreed stock level | Catalogue with update validation |
| Order → 1C | Customer, items, totals and documents | Order linked to its accounting record |
| Payment / delivery → order | Events, confirmed statuses and rejection reasons | Order history and customer notification |
Acceptance includes staff and customer behaviour during failure. Check the record state in each system, as well as its transmission.
Review the pipeline, 1C configuration, payment and logistics services. Identify manual steps and the automation goal.
Map fields, sources and transitions. Check plans, access, API restrictions and duplicate handling rules.
Validate a successful order, declined payment, refund, duplicate event, unavailable 1C and delivery failure. Reconcile records across all systems.
Provide instructions and error monitoring. Assign owners for reference data, access and workflow changes.
We need the configuration name, platform version, hosting and customisations. These determine available exchange mechanisms and accounting-side work.
Where they fit the scenario and are available under current conditions. For each CRM, check events, permissions, restrictions and processing confirmation.
Preserve the original order and exchange state, define retries and monitor errors. Rules depend on system interfaces and acceptable processing time.
Yes. Choose the step where manual transfer causes the most errors and define its outcome. Add further connections using the same data model.
Tell us the CRM, 1C configuration and external service. Describe one operation — a lead, order, document or status — to start with.
Discuss a business integration
