SAP Business ByDesign extension development without unnecessary overhead

Tivoli builds SAP Business ByDesign extensions for processes that the standard product does not cover: connected portals, workflow tools, operational applications, custom services, and side-by-side solutions. The extension runs on SAP BTP, AWS, Azure, or inside the ByDesign landscape according to the problem—not habit.

Workflows and portals Side-by-side applications BTP, AWS and Azure

Standard stays stable New behavior is separated from the ERP core wherever that gives a cleaner upgrade path.
Users stay in flow The extension follows the task and the decision the user needs to make.
Platform stays proportionate The architecture reflects complexity, ownership, security, and expected lifetime.
Delivery stays concrete Architecture leads to a working application, integration, workflow, or prototype.

What a ByDesign extension can add

Extensions are most valuable when they remove the gap between a real operating process and the point where the standard ERP stops. The result should feel like part of the process, even when it runs beside it.

Operational workflows

Approval, exception, scheduling, review, and handoff flows built around roles and business status.

Customer and supplier portals

Focused experiences for orders, documents, requests, catalogs, status, and collaboration outside the ERP UI.

Process-specific applications

Tools for warehouse, logistics, service, project, finance, or field teams that read and write the right ByDesign data.

Custom business objects and services

Purpose-built data structures and interfaces when standard objects cannot represent the required behavior safely.

Reporting and decision support

Operational dashboards, alerts, reconciliation views, and actions that turn ByDesign data into a working queue.

Automation around the ERP

Event-driven services, document processing, scheduled jobs, and integrations that remove repetitive manual steps.

Choose the smallest architecture that will last

A ByDesign extension does not automatically require a large platform programme. We compare the available patterns against the process, landscape, security model, and team that will own the result.

  1. Confirm the standard gap

    Separate configuration opportunities from requirements that genuinely need new code, data, or user experience.

  2. Define the extension boundary

    Decide which data and decisions remain in ByDesign and which behavior belongs in the extension.

  3. Compare platform options

    Assess in-app capability, SAP BTP, AWS, and Azure against identity, APIs, operations, cost, and existing expertise.

  4. Prototype the risky interaction

    Prove the interface, authorization model, user workflow, and write-back behavior before scaling the build.

  5. Deliver and operate

    Build the production solution with deployment automation, monitoring, documentation, and a supportable ownership model.

Where pragmatic extensions help

The strongest candidates are usually visible as repeated workarounds, duplicate entry, spreadsheets, or an expensive platform assumption.

Supplier purchasing

A supplier webshop connected to the ByDesign purchasing process so a selected basket becomes a purchase request automatically.

Logistics visibility

A focused AWS extension for real-time shipment events and ByDesign write-back without the overhead of a full BTP implementation.

Connected operations

Internal tools, APIs, and middleware that expose the right ERP capability to a team without reproducing the whole ByDesign interface.

Questions before extension development

The platform choice matters, but it should follow the process and ownership decisions.

Does every SAP ByDesign extension belong on BTP?

No. BTP is often appropriate for SAP-centered governance and services, but AWS or Azure may be a better fit when the company already operates there or when a focused serverless application is simpler. In-app capability may also be enough. We compare the options before committing.

Can an extension use custom fields and business objects?

Yes, provided they are exposed through an appropriate interface and their lifecycle is understood. The design should account for authorization, validation, extensibility behavior, and how those fields participate in downstream integrations.

Can you start with a prototype?

Yes. A scoped prototype is often the best way to test API limitations, authentication, user workflow, and platform cost before defining the production build.

Can an existing extension be modernized?

Yes. We can review its coupling to ByDesign, API usage, deployment model, security, monitoring, and support burden, then propose a staged improvement rather than an automatic rewrite.

Show us the workaround your team has learned to live with.

We will help decide whether configuration, integration, or a focused ByDesign extension is the most practical answer.