Operational workflows
Approval, exception, scheduling, review, and handoff flows built around roles and business status.
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
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.
Approval, exception, scheduling, review, and handoff flows built around roles and business status.
Focused experiences for orders, documents, requests, catalogs, status, and collaboration outside the ERP UI.
Tools for warehouse, logistics, service, project, finance, or field teams that read and write the right ByDesign data.
Purpose-built data structures and interfaces when standard objects cannot represent the required behavior safely.
Operational dashboards, alerts, reconciliation views, and actions that turn ByDesign data into a working queue.
Event-driven services, document processing, scheduled jobs, and integrations that remove repetitive manual steps.
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.
Separate configuration opportunities from requirements that genuinely need new code, data, or user experience.
Decide which data and decisions remain in ByDesign and which behavior belongs in the extension.
Assess in-app capability, SAP BTP, AWS, and Azure against identity, APIs, operations, cost, and existing expertise.
Prove the interface, authorization model, user workflow, and write-back behavior before scaling the build.
Build the production solution with deployment automation, monitoring, documentation, and a supportable ownership model.
The strongest candidates are usually visible as repeated workarounds, duplicate entry, spreadsheets, or an expensive platform assumption.
A supplier webshop connected to the ByDesign purchasing process so a selected basket becomes a purchase request automatically.
A focused AWS extension for real-time shipment events and ByDesign write-back without the overhead of a full BTP implementation.
Internal tools, APIs, and middleware that expose the right ERP capability to a team without reproducing the whole ByDesign interface.
The platform choice matters, but it should follow the process and ownership decisions.
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.
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.
Yes. A scoped prototype is often the best way to test API limitations, authentication, user workflow, and platform cost before defining the production build.
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.
We will help decide whether configuration, integration, or a focused ByDesign extension is the most practical answer.