Connecting a customer portal to SAP: scope and architecture

A customer portal creates value when it replaces specific enquiries and manual tasks. Sales, customer service and IT should first identify information customers currently request by email: order status, invoices, delivery dates or account-specific documents. These needs define a manageable first release. The portal does not need to reproduce the entire ERP interface. The selected information must be reliable and belong to the correct customer organisation.

Starting point and project boundaries

• Separate read-only document access from ordering, claims and master-data changes; each write workflow needs its own approval boundary.
• Identify customer organisations, subsidiaries and contacts so that portal access matches the actual business relationships.
• Record delivery-date and invoice enquiries separately: frequency and resolution effort help determine which self-service workflow to implement first.

Start with the actual SAP version and the interfaces approved for use. Middleware can decouple the portal from the ERP, translate data models and handle temporary failures. Decide which system owns each record and how retries after timeouts are identified. Authenticating a portal user does not replace server-side checks on customer and document permissions.

• Assign each displayed value to an authoritative SAP object, an acceptable freshness limit and defined behaviour when data is unavailable.
• Check the approved interfaces in the actual SAP landscape.

An existing endpoint does not establish that every required field is accessible.

• Separate authentication from document authorisation.

Server-side organisation filtering must also cover downloads, search results and cached responses.

One possible delivery approach starts with read-only document access. Customers receive only documents belonging to their organisation, with short-lived download links issued after permission checks. Ordering or claims handling can follow in a later release. Every write operation needs validation, a clear response and retry behaviour. This is an illustrative architecture approach, not an additional GSWE customer reference.

Practical acceptance scenarios for the first release

• A customer changes the document number in a download request. The portal must not disclose a document belonging to another customer organisation.
• SAP becomes temporarily unavailable. Cached status information identifies its age, while a binding order is not incorrectly shown as confirmed.
• An order response is lost. A repeated request must identify the original transaction instead of creating a second order.

Include test environments, internal owners and ERP release constraints. Acceptance criteria should cover practical situations: documents from another account cannot be accessed, an ERP outage is explained clearly, retried actions do not create duplicate orders and support can trace failed transfers.

For commissioning, accept three access patterns separately: reading documents, changing master data and placing orders. Specify the customer organisation, acceptable data freshness and behaviour during an SAP outage for each workflow. Ask for the same test using two different customer accounts. This demonstrates whether the backend actually separates customer data or the interface merely hides it.

Ask the provider to demonstrate a complete transaction from the portal to the ERP response. A screen demonstration alone does not establish whether permissions, document ownership and error handling work together. Also agree who resolves master-data problems and how customers continue after a failed transfer.

A checklist for commissioning the work

• Request a mapping from portal actions to SAP objects and a role model covering customer administrators, staff and internal processing teams.
• Agree how status enquiries, rejected access and failed orders will be traced and investigated after launch.

For a comparable proposal

• Identify the SAP system, available interfaces and initial self-service workflows.
• Map customer organisations, contacts and permitted document access explicitly.
• Test other customers' documents, delayed SAP responses and master-data changes.

A focused self-service workflow with reliable SAP integration is often a sensible starting point. A new interface alone does not reduce coordination work. Data quality, permission checks and an operating process make the portal a dependable part of customer service. Progress can be assessed through manual status enquiries, adoption and processing times for the selected workflows.

Assess the benefit and control further expansion

• Measure the share of status and document enquiries resolved through self-service and identify the questions still reaching customer service.
• Before adding ordering, verify that user assignment, document access and data freshness work reliably in the read-only portal.
• Include the effort of maintaining users and customer organisations: a self-service portal still needs accountable business ownership.

Select the first SAP-related task customers should complete without contacting your team. GSWE reviews data access and the role model with you to begin customer portal development.

Commission an SAP customer portal: Connect a Customer Portal to SAP via API.