Italiano 
When data passes through someone's hands
In many companies SAP is the heart of the data: customer records, items, orders, stock, invoices. Yet for the people working every day in the order desk, accounting or customer service, that heart is often far from the actual work. A customer emails to ask about a delivery, a colleague opens the ERP, looks up the order, copies the status and replies. A sales rep on the road asks for an updated price list and someone runs an Excel export, tidies it up and sends it as an attachment.
None of these steps is difficult. The problem is that there are many of them, they are repeated, and they rely on people's memory. Every time a piece of data passes through someone's hands to get from one system to another, time is lost and the door opens to a typo, an old file sent by mistake, or information that stays in the inbox of whoever received it.
The instinctive reaction is to think you need a new ERP, or a deep customization of SAP. That is almost never the case. What is missing is a connection between the ERP and the web tools people actually work with: a portal, a form, a dashboard. This is what SAP web integration is about, and in this article we try to explain it without jargon.
What integration means, in plain words
Integrating means making two systems exchange information on their own, following precise rules, without a person acting as the bridge. SAP remains the official source of data; the portal or web workflow becomes the window through which the right people view or update it.
There are several ways to build that bridge, and the choice depends on what the ERP already offers. APIs are access points through which one piece of software requests or sends data to another in a controlled way. Middleware is an intermediate layer that translates and routes information between systems that speak different languages. In some cases scheduled exports are enough: files generated automatically at set times and read by the portal. There is no single best route: there is the one that suits the process, the data and the company's technical constraints.
One point worth clarifying straight away is that integration does not mean opening the whole ERP to everyone. A good project takes out of SAP only the data a given process needs, only for the people who need it and only in the form that is useful to them. Everything else stays where it is.
Event organizers already know this reasoning: we covered it in the article on how to integrate event management with business systems, where registrations and payments reach the ERP without being retyped. The principle is the same; only the process changes.
Portals, forms and workflows: three ways to open up SAP
In practice, a web integration with the ERP almost always takes one of three forms, often combined.
The first is the portal: a private area, accessible from a browser, where customers, agents or partners find the information that concerns them. The status of an order, delivery notes, invoices, their dedicated price list. Whoever logs in sees only what is relevant to them, and the data is SAP's own, not a copy from a few days earlier.
The second is the operational form: a web form, simpler than the ERP's native screen, used to enter a request, a return, an order or a report. The form guides the user, checks that fields are correct and sends the data to SAP. For the user it feels like filling in a web page; for the company, it is one less manual entry.
The third is the workflow, a sequence of steps with rules and approvals. A request comes in, is routed to the right department, someone approves it, the ERP is updated and the sender receives a notification. Dashboards for each department complete the picture, showing the figures that matter at a glance without running reports from the ERP.
As needs grow, these three forms come together in a single environment: this is where professional web platforms come in, bringing together data, users, permissions and workflows while talking to ERPs and CRMs. To understand when this step makes sense, you will find useful ideas in the article on custom web platforms and competitive edge.
Which data should flow, and in which direction
The most useful question at the start is not "which technology should we use?" but "which data needs to flow, where to and how often?". Some data leaves SAP to be viewed, some enters the ERP from a web form, some goes both ways. Frequency varies too: a shipment status may need to be up to the minute, while a price list may only need updating once a day.
The table shows some typical lines of reasoning. They are not specific project cases, but the way it pays to line up the information before talking about technology.
| Need | How it is often handled today | What changes with integration |
|---|---|---|
| Order status for customers | Emails to customer service and manual lookups in the ERP | Customers check the status in the portal, read from SAP |
| Price lists and availability for agents | Excel exports sent by email, often out of date | Up-to-date data available on the web and on mobile |
| Return or support requests | Free-form emails, then retyped by hand | A guided form that records the request and routes it |
| Figures for department managers | Reports run manually and copied into a spreadsheet | A dedicated dashboard with the data that role needs |
Writing this map down has a valuable side effect: it forces you to ask which data is reliable. If a customer record in SAP is incomplete, the portal will show it incomplete. Integration does not fix data on its own, but it makes clear where it needs fixing.
A process example, from email to portal
Imagine a company selling spare parts to a network of resellers. Today resellers order by email, attaching a list of item codes. In the office someone reads the email, checks availability in SAP, enters the order and replies with a confirmation. If a code is wrong or out of stock, an exchange of messages begins that can last days.
With a portal connected to the ERP, the reseller logs into their area, searches the catalogue, sees availability read from SAP and submits the order through a form that does not accept non-existent codes. The order reaches the ERP already filled in; the office checks and confirms it instead of retyping it. The reseller receives a notification and, in the following days, tracks the delivery status from the same portal.
Notice two things. First, the person in the office does not disappear: their job changes from copying to checking. Second, the project starts from a single flow. Once orders work, invoice lookup can be added, then returns, then an area for agents. It is the safest way to build something people will actually use, as we also explain in the article on the 6 phases of web platform development.
Access, errors and control
Connecting the ERP to the web means carefully deciding who sees what and who can do what. A customer sees their own orders and not anyone else's; an agent sees their territory; accounting sees the information within its remit. These permissions are designed at the start, together with roles, and must be consistent with those already in place in the company's systems.
The other aspect not to overlook is what happens when something goes wrong. A connection can drop, data can arrive in an unexpected format, an order can be rejected by the ERP. A well-built integration includes logs that record every exchange, notifications that alert whoever needs to act, and procedures that automatically retry the operation. Without these controls, errors stay silent and are discovered only when a customer complains.
Personal data in the portal. If the portal displays or collects data about people, such as contacts, private customers or employees, agree with your privacy advisor which information to make visible, to whom and for how long. It is a decision to take before development, not after.
Once ERP data can be reached in a controlled way, another possibility opens up: adding an AI assistant that reads and summarizes it, for example to prepare a reply to a customer or a draft quote. This is the step we describe in the article on how to make AI, customer data, emails and quotes work together and on the page about AI integration in business processes. A well-designed connection with SAP is the foundation these developments can build on.
How to connect SAP to a web workflow in 5 steps
You don't need a huge project to get a concrete result. You need a precise order, in which the process comes before the technology.
- Choose one process and describe itPick a flow that currently goes through emails, exports and manual copying, ideally frequent and well known. Describe who uses it, which data is needed and when.
- Define data, direction and permissionsDecide which information to read from SAP, which to write, how often, and who can see or change what. Put it in writing so it is clear to every department involved.
- Design architecture and interfaceThe most suitable connection channel is chosen among APIs, middleware or scheduled exports, and the web interface is designed around the people who will use it every day, not those who already know the ERP.
- Test with real data and controlsIn a test environment, data accuracy, error handling, logs and notifications are checked. This is when incomplete records and special cases come to light.
- Release, train the team and extendThe solution is put into use, supporting people in the first days. Once the first flow works, new modules, areas or departments are added.
Checklist before you start
Before the first meeting with whoever will build the integration, try to answer these questions with the colleagues involved.
SAP web integration: what to be clear about
First process chosen. You know which flow to connect first and why that one.
Users identified. It is clear who will use the portal or form: internal colleagues, customers, agents or partners.
Data mapped. You have listed which data to read, which to write and how often.
IT contact involved. Whoever manages SAP knows about the project and can point out the technical access available.
Permissions decided. Each role sees and changes only what concerns it.
Error handling planned. It is clear who receives alerts if a synchronization fails.
Frequently asked questions
Do we need to replace or modify SAP to connect it to a portal?
Usually not. The integration relies on what the ERP already provides, such as APIs, databases, scheduled exports or middleware, and builds the portal or web workflow on top of it.
Can this be done with an ERP other than SAP?
Yes. The same approach works with other ERPs, CRMs and business systems: the available data exchange channels are assessed case by case.
Is the data updated automatically?
Yes, automatic flows can be designed with logs, checks and validation rules. How often data is updated depends on the process: some data is needed in real time, other data is fine once or a few times a day.
How long does an SAP integration take?
It depends on available APIs, data quality, test environments and the number of flows to connect. That is why it starts with a process analysis, which is used to estimate timing, priorities and risks.
Who checks if a synchronization fails?
Logs, notifications, technical dashboards and retry procedures can be set up, so that an error is reported and handled instead of going unnoticed.
Does your process still run on emails and spreadsheets?
Do you have an SAP system and a flow that someone retypes by hand every day? Tell us about it: we start from that process and make it accessible on the web, with up-to-date data and clear permissions.
