The warehouse manager wants a new field on the purchase order. Sales wants online store orders to land in the ERP on their own. Finance needs one more approver for payments above a certain amount. Three reasonable requests, three different paths, and the next SAP Business One upgrade is already on the calendar.
When you bring in an SAP Business One consultant for custom development, the first thing they should ask you is whether anything needs to be built at all. A large share of what gets requested as development can be handled with configuration, user-defined fields or a standard approval procedure. What does need code is best built with the tools SAP maintains across versions, because every feature pack puts everything you added on top to the test again.
Below are the real SAP B1 development options, when to use each one, and what to ask for so your SAP Business One add-ons survive the next upgrade.
Before writing code: what the standard product already does
An experienced consultant works through these options before quoting development hours:
- User-defined fields and tables (UDFs and UDTs) to store data the standard product doesn't cover.
- User-defined objects (UDOs) when you need a full entity with its own form and numbering.
- Configurable approval procedures and alerts.
- Formatted searches and saved queries to fill in fields or validate data.
- The product's own reporting tools, before anyone considers a custom print layout.
SAP explains how to create user-defined fields and tables in its SAP Business One 10.0 help portal, along with the rest of its developer documentation. If a requirement fits here, the cost of carrying it through each upgrade is close to zero.
SAP B1 development tools and when to use each one
When the standard product falls short, there are several routes. They are not interchangeable, and a poor choice gets paid for at the next upgrade.
| Tool | What it is | Use it for | Watch out for |
|---|---|---|---|
| Service Layer | HTTP API using the OData protocol | New integrations: e-commerce, CRM, mobile apps, Power Platform | Check that the object you need is exposed in your feature pack |
| DI API | COM API that gives access to SAP B1 business objects | Existing desktop add-ons or processes that have relied on it for years | Since version 10.0, only 64-bit add-ons are supported |
| UI API | COM API that changes the desktop client interface at runtime | Adding fields, buttons or validations to desktop client screens | This is the layer most likely to break when menus and forms change |
| Web Client extensions | Web apps deployed through Extension Manager | New experiences for users who work in the browser | A desktop add-on does not automatically run in the Web Client |
| SAP Business One Studio | .NET-based development environment | Designing forms and extensions; it replaced the old Screen Painter | You need a team that knows the SDK |
The descriptions of DI API, UI API and Studio come from SAP's client components guide. The retirement of Screen Painter and the move to 64-bit-only support are covered in the official Compatibility Issues in SAP Business One 10.0 document.
For almost any new integration, the Service Layer is the sensible place to start. It speaks HTTP, any language can call it, and since FP 2602 it supports webhooks that notify other systems when something happens in SAP B1, instead of polling it every few minutes.
When custom development makes sense
Sometimes writing code is the right call:
- Integrations with systems your business can't let go of: an online store, a WMS, a field service app or a large customer's platform.
- Processes of your own that set you apart and that no add-on on the market covers well.
- Automations that remove repeated data entry between SAP B1 and other tools, such as approvals in Teams or loading supplier documents.
- Analytics that combine ERP data with other sources, which is often better done outside SAP, in Power BI, than inside it.
In these cases the question becomes where the development lives. A practical rule: the less code running inside the SAP client, the less breaks with each upgrade. A Service Layer integration or a Power Automate flow sits outside the ERP and depends only on the API. A UI API add-on lives inside every screen it touches.
When it doesn't
There are also clear signs that development is a bad idea:
- The request duplicates something the standard product already does, just "the way we've always done it." Adjust the process before the system.
- An established vendor sells an add-on that does the same thing and keeps it current with every release.
- The proposed solution writes straight into SAP tables with SQL or triggers. That route skips the ERP's business logic and is a common source of inconsistent data. The DI API and the Service Layer exist for writing data.
- Nobody is going to maintain the code. A development delivered without source code or documentation becomes the roadblock for the next upgrade.
Upgrades: where custom work shows what it's worth
SAP delivers innovation for version 10.0 through cumulative feature packs, which according to its upgrades page include new features, corrections, security fixes and legal changes. Falling several feature packs behind has a cost. Version 10.0 is in mainstream maintenance until December 31, 2028, according to SAP's maintenance strategy, with version 11 on the horizon.
Every jump tests what you added. In its compatibility document, SAP warns that add-ons depending on the database structure may run into additional issues. Before any upgrade, ask your partner for:
- An inventory of add-ons, integrations, UDOs and stored procedures, each with an owner.
- Testing on a copy of the database, using the exact target feature pack and patch.
- Confirmation that each third-party add-on is compatible with that version.
- For in-house add-ons, a rebuild plus tests of installation, startup and main workflows, not just checking that it "opens."
- A review of each add-on's registration (ARD) file if you want the client to upgrade it silently, as described in SAP's administrator guide.
If your support contract doesn't say who does this work, check what your SAP Business One support contract should include before your next renewal.
What to ask an SAP Business One consultant before approving development
A serious proposal answers these questions in writing:
- Did anyone try solving it with configuration, UDFs or UDOs? Why wasn't that enough?
- Which tool will be used (Service Layer, DI API, UI API, Web Client), and why that one?
- Does the development write data through SAP's APIs, or does it touch the database directly?
- Who owns the source code, and where is it delivered?
- What documentation is left behind, and who keeps it up to date?
- How many hours does it take to review with each feature pack?
If the answer to that last question is "zero," be skeptical. Every piece of custom work has a maintenance cost, and it's better to know it from the start.
Frequently asked questions
Which is better for integrating SAP Business One: Service Layer or DI API?
For new integrations, usually the Service Layer, since it runs over HTTP and any platform can call it. The DI API is still a valid choice for existing add-ons or when you need an object the Service Layer doesn't expose in your version.
Will my add-ons stop working with every feature pack?
Not necessarily, but you should always test them. The riskiest ones are those that modify the desktop interface or depend on the internal database structure.
Can I use Power Platform with SAP Business One?
Yes. Power Apps, Power Automate and Power BI can work with SAP B1 data, usually through the Service Layer with a custom connector or an integration layer. It's a good way to add approvals, forms or dashboards without putting code inside the ERP.
Let's talk about your next development
At Disrupsoft we work with companies that already run SAP Business One: Service Layer and DI API integrations, extensions built with Power Apps and Power Automate, Power BI analytics, migrations and upgrades, and corrective and evolutionary support. If you have a list of requirements and aren't sure which ones need code, we can start by reviewing it with you. Learn more on our SAP services page.
