“B2B portal” is not a product category with a fixed feature list. It may mean an ordering channel for dealers, a supplier data room or a service interface for connected machinery. All of them share one demanding property: one organisation works inside another organisation’s systems without giving up its own boundaries

The architecture starts with the tenant

In a consumer application, an account usually belongs to one person. In a B2B setting, that person belongs to a company and often to a site, department or contract as well. A user may work for several organisations. The same organisation may have buyers, engineers and administrators with different authority

Tenant isolation cannot therefore be a filter in the interface. Every query, export and background job must enforce the organisational context. Automated tests should deliberately try to reach another tenant’s records through altered identifiers, search functions or file links. This is where the most serious portal failures tend to occur

Five layers of a reliable B2B portal

1. Identity and organisation model

Invitations, role changes and the departure of external users need traceable processes. Larger business customers often expect single sign on through their own identity provider. Sensitive actions may justify fresh authentication or an additional approval

2. Domain model

Products, contracts, assets, service cases and documents need stable identifiers and clear relationships. Copying that structure from an existing spreadsheet often imports its ambiguity as well. The portal needs its own comprehensible model and a defined mapping to the system of record

3. Integration layer

ERP, CRM, document storage and logistics do not work at the same pace. Interfaces need retry rules, duplicate protection and monitoring. During an outage, users must still be able to tell whether an action was accepted, merely queued or fully processed

4. Working interface

Business users often arrive with a specific job: review every certificate due to expire, locate a serial number or reorder twelve items. Navigation should follow those jobs. A copy of the internal ERP menu is rarely clear and is usually poor on a phone

5. Operations and evidence

Logs, metrics and support access are part of the product. The team needs to see which interface is slow, which notification was not delivered and who changed a critical value. Administrators need safe support tools, not shared master accounts

The Data Act changes the data question

The EU Data Act has applied since 12 September 2025. It is particularly relevant to data from connected products and related services. Manufacturers therefore need a clearer account of which data a product generates, how users access it and how sharing with third parties is implemented. A machinery service portal is no longer just an interface for PDF files. It can become the controlled access layer for operational data

That requires a clean distinction between raw data, derived insight, trade secrets and personal information. A download button does not settle the issue. The system needs a data catalogue, purpose, retention rule, export format and a record of who received what. Qualified advisers should determine the legal position; the technical architecture must make that position enforceable

A sensible order for the first release

The first release should handle one transaction from end to end. In a supplier portal, that may be the journey from a requested certificate to technical approval. In a service portal, it may be an incident report containing asset data, priority and a confirmed response

Only once that path works measurably should more roles and processes be added. Starting orders, tickets, invoices, training and master data in parallel produces many screens but no dependable chain

  • one accountable owner for every business record
  • one documented system of record for every field
  • defined behaviour whenever an interface is unavailable
  • an authorisation test for every role and tenant
  • an operational view of errors, latency and outstanding work

Portal types are domain models, not skins

A supplier portal revolves around evidence, approvals and deadlines. A partner portal represents collaboration and responsibility. A dealer portal often needs price, availability and product data in the right context. They can share a technical foundation. Their domain logic remains different

The most reliable design therefore does not begin with the dashboard. It begins with organisations, permissions, events and the question of which system wins when records disagree