Packaged connectors cover standard objects moving in standard directions, and for a lot of businesses that is enough. Then someone asks for an approval gate above a discount threshold, a second company database, or a contract object the template has never heard of. Twopir Consulting builds the layer that handles those — without turning your integration into something nobody can upgrade. Configuration first. Code only where configuration genuinely cannot reach.
Trusted by 500+ organizations — including distributors, manufacturers and field-service businesses running HubSpot in front of an ERP with Twopir Consulting.
Customization Coverage
Every one of these starts as a reasonable business request and ends as a spreadsheet, a hard-coded value, or a rule nobody can explain. The problem is rarely the connector; it is where the logic was put.
Above a threshold a deal needs approval before it may become a sales order. A packaged connector has no concept of your approval matrix, so the rule ends up enforced by a person remembering to check — which is to say, not enforced.
Service contracts, rental agreements, project milestones, equipment under warranty. Real to your business, absent from the connector's supported objects, and currently living in a spreadsheet.
Two or three SAP Business One company databases, one HubSpot portal. Most packaged apps assume one of each, so the second entity becomes a second subscription, a second set of rules, and no single view of the customer.
Somebody made it work by embedding customer IDs, tax codes and thresholds in the integration logic. It worked until the price list changed, and now every business change is a development ticket.
The integration was extended in a way that cannot survive a connector update or a SAP Business One upgrade, so both get deferred — and the deferral becomes permanent.
An undocumented condition in the mapping that somebody added for a reason nobody recorded. It is now load-bearing, and everyone is afraid to touch it.
The question worth asking is not whether something can be customized. It is where each piece of logic should live — and whether you will still be able to upgrade afterwards.
SAP Business One HubSpot integration customization is the work that goes beyond what a packaged connector or a standard configuration can express: business rules with conditions, objects neither platform ships, logic that has to run between the two systems, and extensions on either side that make the rest possible.
The useful distinction is not custom versus standard — it is where each piece of logic lives. Some requirements are configuration in HubSpot. Some are configuration in SAP Business One, through user-defined fields, user-defined objects and approval procedures. Some genuinely belong in the integration layer, because they are about the relationship between the two systems rather than about either one. Putting logic in the wrong place is how integrations become unmaintainable.
Our default is configuration first, code only where configuration genuinely cannot reach, and anything custom written so it survives an upgrade: no hard-coded identifiers, thresholds held as data rather than logic, and a written record of why each rule exists. We help growing and mid-market companies solve complex CRM, integration, and business system challenges. Exact extension behaviour varies by SAP Business One version, localization and configuration, so every design is validated against your environment and SAP’s own Business One documentation before it is built.
Nine requirements we are asked for regularly, and where each one actually belongs. Read this before scoping: several of these are configuration that people assume is custom development.
| Requirement | Verdict | Where it lives | Notes |
|---|---|---|---|
| Map an extra field between existing objects | Configuration | Connector or integration mapping | No code. If a packaged connector cannot map a field it already carries, that is a product limit worth confirming before assuming customization. |
| Store the ERP customer number on the CRM record | Configuration | HubSpot property + SAP user-defined field | A property on the Company and a U_HubSpotId-style field in SAP. This is the identity foundation, not a customization. |
| Only sync deals above a value, or in one pipeline | Configuration | Filter in the integration layer | A condition on an existing flow. Keep the threshold as configuration data so finance can change it without a release. |
| Require approval before an order reaches SAP | Custom | Integration layer, or a SAP approval procedure | Which side depends on who must approve. If the approver works in the CRM, the gate belongs there; if they work in the ERP, use SAP’s own approval procedures. |
| Model a service contract or rental agreement | Custom | HubSpot custom object + SAP UDO or UDF set | Both sides need somewhere to put it. Design the object once and map it, rather than overloading an unrelated standard object. |
| Non-standard pricing or discount logic | Custom | Usually SAP-side, surfaced to HubSpot | Pricing should stay in the ERP where the rules already live. The integration surfaces the result; it should not become a second pricing engine. |
| Multiple company databases behind one portal | Custom | Integration layer routing | Entity resolution, per-entity numbering, currency and tax handling, and a rule for which company a new customer belongs to. |
| Write to a SAP object the connector does not support | Custom | Service Layer call from a custom service | The Service Layer exposes far more than most packaged templates use. Confirm the object and behaviour against your installed version first. |
| Custom validation before an ERP write | Custom | Integration layer | Catching a predictable rejection before it reaches SAP gives a better error message and keeps the queue clean. |
Scroll the table sideways to see every column
Seven extension points across SAP Business One, HubSpot and the integration layer. Using them as designed is what keeps custom work upgradeable.
| Extension point | Platform | What it is | What we use it for |
|---|---|---|---|
| SAP user-defined field (UDF) | SAP Business One | An extra field on a standard object — Business Partner, Item, a sales document. | Integration identifiers such as U_HubSpotId, plus business attributes like tier or region. |
| SAP user-defined object (UDO) | SAP Business One | A whole object you define, with its own table and behaviour. | Entities that genuinely belong in the ERP and have no standard equivalent. |
| SAP approval procedures | SAP Business One | Native document approval rules on the ERP side. | Where the approver works in SAP. Preferable to rebuilding approval logic in middleware. |
| HubSpot custom object | HubSpot | A first-class object with its own properties and associations. | Contracts, installations, assets — anything the sales and service teams need to see and report on. |
| HubSpot custom properties | HubSpot | Fields on standard objects, including the ERP identifiers and status mirrors. | CardCode, invoice status, credit state, stock snapshots. The cheapest extension point on either side. |
| Integration-layer rules | The custom layer | Conditions, routing, validation and transformation that belong to neither system alone. | Approval gates, entity routing, pre-write validation, anything about the relationship between the two. |
| Custom Service Layer calls | The custom layer | Direct REST calls to objects a packaged connector does not cover. | Reaching a document type or query the template omits, without replacing the connector. |
Scroll the table sideways to see every column
Extend what exists before building new, build deliberately when you must, and engineer either so it does not block the next upgrade.
Keeping a packaged connector for what it does well and building only the part it cannot reach. Usually the cheapest correct answer.
Where the rules are genuinely yours — approvals, multi-entity routing, non-standard objects — and no template is going to express them.
Custom work that does not become the reason you cannot upgrade either platform.
Five steps, and the second one — testing the requirement against configuration on both sides — regularly removes the need for the other three.
Not “we need customization” but the actual condition: who, what threshold, what happens on each branch.
Can HubSpot configuration do it? Can SAP configuration do it? Only what survives both questions is a candidate for code.
CRM side, ERP side, or the integration layer — decided by who owns the rule and who has to change it later.
Which UDFs, which UDOs, which HubSpot custom objects and properties. Specified for your SAP partner to apply.
Built against a test company, with the rule's reason recorded and a regression test so the next upgrade is routine.
Custom integrations do not usually fail. They ossify — until every business change is a development ticket and nobody will approve the upgrade.
A discount limit, a credit ceiling, a routing rule — held as configuration so finance can change it without a release. Hard-coding these is the most common reason custom integrations calcify.
SAP Business One already holds price lists, customer-specific pricing and tax rules. The integration surfaces the result; building a second pricing engine in middleware guarantees the two will disagree.
A contract or an asset needs a home on both sides. Design it as a HubSpot custom object and a matching SAP structure, rather than overloading a standard object that will later be needed for its real purpose.
Custom work without tests turns every platform update into a risk assessment. With them, an upgrade is a scheduled task with a known verification step.
These are architecture patterns, not client metrics — we publish numbers only where a specific engagement has measured them. The case study beside them is real and linked.
Deals above an agreed threshold wait for approval before a sales order is created. The threshold is configuration data, and where the approver works in SAP the gate uses SAP’s own approval procedures rather than a parallel one.
A HubSpot custom object for the commercial view, a matching SAP structure for the operational one, and a mapping between them — instead of a spreadsheet and a field called “notes”.
The integration layer resolves which SAP Business One company a customer belongs to, routes the document accordingly, and handles per-entity numbering, currency and tax without duplicating the whole flow.
A document type or query the packaged connector does not cover, reached directly through the Service Layer from a small custom service beside it — leaving the connector in place for everything it already handles.
Custom quote and approval logic built across CPQ and the systems around it. Different platform pair, the same principle: configure what can be configured, build only what cannot, and document why each rule exists.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. The requirements that do not fit a template are exactly the ones that decide whether the integration is an asset or a liability.
Not as a formality. A surprising amount of what gets scoped as customization is a HubSpot property, a SAP user-defined field or an approval procedure that already exists.
Pricing in the ERP, engagement rules in the CRM, and only the genuinely cross-system logic in the integration layer. Misplaced logic is what makes an integration unmaintainable.
No hard-coded identifiers or thresholds, extension points used as designed, and regression tests — so custom work does not become the reason an upgrade keeps being deferred.
Every non-obvious rule carries the reason it exists. It is the difference between a rule someone can change confidently and one everybody is afraid to touch.
UDFs, UDOs and approval procedures are applied by the people who know your ERP configuration. We specify precisely; they apply. We help growing and mid-market companies solve complex CRM, integration, and business system challenges.
When it is genuinely needed, what it costs you in upgrade risk, and how to keep that risk small.
When it cannot be expressed as configuration on either side. Run the test in order: can HubSpot configuration do it — a property, a pipeline, a workflow? Can SAP Business One configuration do it — a user-defined field, a user-defined object, an approval procedure? Can the integration layer do it with a filter or a mapping rule?
Only what survives all three is genuinely custom. In our experience a meaningful share of requirements that arrive described as customization are configuration somebody had not found yet, which is why the boundary table above is worth reading before scoping.
You can configure them, and within their own model that goes reasonably far. What you generally cannot do is change how the app itself behaves — that is the vendor's product.
The practical approach is to keep the connector for the standard objects and directions it handles well, and build a small custom service beside it for the rules it cannot express. Two components, one mapping document, one owner. Replacing the connector is the last option, not the first.
A user-defined field adds a field to a standard SAP Business One object — a Business Partner, an Item, a sales document. A user-defined object is a whole object you define, with its own storage and behaviour.
Almost every integration needs at least one UDF: somewhere to store the HubSpot identifier so matching is deterministic rather than name-based. UDOs are a bigger decision, warranted when an entity genuinely belongs in the ERP and has no standard equivalent. Both are applied by your SAP partner; we specify exactly what is needed.
It should not, and avoiding that is a design constraint rather than a hope. Extension points used as designed — UDFs, UDOs, approval procedures, the Service Layer — are intended to survive upgrades.
What causes trouble is work that goes around those mechanisms, or that hard-codes identifiers, tax codes and thresholds into logic. We keep those as configuration data and add regression tests, so an upgrade becomes a scheduled task with a known verification step rather than an open-ended risk. Exact behaviour still varies by version and localization, so upgrade testing stays part of the plan.
Almost never. SAP Business One already holds price lists, customer-specific pricing, currency and tax rules, and it is the system that has to defend those numbers to an auditor.
Build a second pricing engine in middleware and the two will disagree — usually at the worst moment, on a document a customer is looking at. The integration should resolve and surface the ERP's price, not compute its own. Where CRM-side pricing flexibility is genuinely needed, the right conversation is about what the ERP can express.
Yes, and it is a common starting point. The first piece is an assessment: what the custom logic does, what depends on it, which rules are load-bearing and which are leftovers from a requirement that no longer exists.
The output is a written record of the behaviour, and a judgement on what to keep, what to move into configuration, and what to rebuild. Rebuilding everything is rarely the right answer — a lot of undocumented custom work is doing something sensible that was simply never written down.
As a routing problem in the integration layer rather than as several parallel integrations. The layer resolves which company a customer or document belongs to, applies per-entity numbering, currency and tax handling, and writes to the right database.
The design questions that need answering first are which company a new customer defaults to, what happens when one customer trades with two entities, and whether one HubSpot portal should serve all of them at all. That last one is a business question and it is worth settling before any build.
Four companion pages. This one covers the work past the template; the others cover architecture, scope, delivery and the data model.
Bring the requirement as a rule, with its conditions. We will tell you whether it is HubSpot configuration, SAP Business One configuration, or genuinely custom — and what keeping it upgradeable would take.
Configure before you code — and document why
