A practical way to decide when customer, partner, supplier, and employee portals need a shared core.
A supplier changes a delivery date. The ERP system has the new value. The customer portal still shows the old one.
Support opens several systems to find the current status. The customer waits. Someone has to decide which record is right.
This is rarely caused by one bad integration. It is often the result of a product growing one audience at a time.
A company launches an account for customers: orders, invoices, documents, support requests. Later comes a partner portal, then a supplier portal, then an interface for employees. Each decision is understandable in isolation. Over time, every audience gets its own accounts, directories, statuses, permissions, and integrations.
The real question is no longer how to add another portal. It is whether the company is building another product on top of the same business reality.
The fifth portal creates a fifth version of the same status
The number of screens is not the issue. Fragmentation appears at the boundaries between them.
One contractor may exist under different names in different products. A change to company details has to travel through several systems. One portal talks to the ERP, another connects to the same ERP through a separate integration, and an admin interface receives only part of the information through the CRM.
Access follows the same pattern. A partner may represent several legal entities. An employee may move between branches. A customer may gain administrator rights for their organization. When every portal holds its own user model, each change becomes a chain of requests, approvals, and checks.
The impact becomes visible when a team adds the next role. Login, permissions, directories, notifications, reporting, and audit history are assembled again. The launch takes longer, or part of the process returns to email and spreadsheets.
Four operational signals make the problem easier to discuss:
Time to onboard a new role. Measure the path from agreeing on a scenario to the first user working in the system. A growing interval often means the basics are being rebuilt each time.
Requests about access, statuses, and documents. Separate process questions from cases where a person cannot sign in, cannot see the right organization, or receives stale data.
The number of systems that can change one entity. If partner details, order status, or a limit can be edited in several places, ownership is already unclear.
Regression scope before a release. A new feature may affect customers, suppliers, managers, billing, and notifications. The test scope shows how tightly those roles are connected.
These are team diagnostics, not universal benchmarks. Their shared direction matters: when all four grow, every new audience starts to look like a standalone launch.
One login is only the beginning
Single sign-on makes authentication less repetitive. It does not decide which organization a person represents, which status is authoritative, or which service may change a document.
A product ecosystem needs a shared layer for those rules. It can support distinct interfaces for customers, partners, suppliers, employees, and administrators. Their tasks remain different. The shared elements are the business entities and the process state behind them: organizations, users, documents, payments, permissions, events, and integrations.
This is the difference between a collection of portals and a connected account product.
The public Altprof project illustrates the pattern. A customer publishes a task and chooses an executor. A specialist works with responses and orders. The business team manages users, roles, payments, and critical scenarios. Their actions affect deals, statuses, and administration, so the roles were designed inside one system.
One person can act for three companies
An account identifies a person. A role defines the actions available to that person. An organization context shows whose behalf they are acting on right now.
Those three concepts need separate places in the model.
In a B2B scenario, the same person may place an order for one company, approve documents for another, and administer employees for a third. Separate profiles make support and auditing harder because the history splits with the accounts. A shared profile can preserve that history while the user switches context deliberately.
Roles are a useful base for stable permission sets. Context completes the decision when access depends on the organization, region, object type, amount, status, or another attribute. The interface can guide the user, but authorization must be checked on the server for the requested action and object.
That approach also makes the next role less expensive to connect. The new interface receives a scenario and a permission model while identity, organizations, and audit history already exist in the core.
Give every important entity a home
The first integration should begin with a simple decision: where is the source of truth for each key entity?
For example, an invoice may be created in an ERP system, a deal in a CRM, signing status in an electronic document system, and notification preferences in the account product. The specific distribution depends on the business. What matters is that the team can name the authoritative system, the owner of the boundary, and the permitted point of change.
Then define the direction of exchange and the behaviour during a failure. What happens while the ERP is unavailable? Can an event be delivered again? Could a repeat request create another order or payment? Will a manager see the problem before a customer reports it?
Queues, idempotent operations, and event logs are practical tools for this work. They do not remove the need for decisions about ownership. They make the decisions traceable when systems become unavailable or messages are repeated.
If your account product is reaching this point, map the shared layer before adding the next portal: roles, organization contexts, shared entities, systems of record, and the teams that own them.
A shared core has a cost too
A platform layer is an investment. Teams need to define organization boundaries and access rules, reconcile duplicate data, plan migration, introduce SSO where it is appropriate, and monitor integrations. Regression testing also needs to cover the relationships between the interfaces.
Moving from several existing systems can be particularly demanding. Adapters let a team connect legacy parts gradually, yet each adapter still needs maintenance, monitoring, and updates when an API changes. Migrating a directory will not repair poor source data by itself.
For a simple account with one or two roles, shallow integrations, and no complex approval flow, a packaged portal may remain the sensible choice.
A shared custom core becomes worth considering when the account product affects money, documents, permissions, or a critical customer path — and when launching the next role already requires a separate project.
The test: can the next role connect as a module
The clearest test is simple. A new role should reuse the identity model, organization model, data sources, integrations, and audit trail. The team should add its scenario and interface as a module.
If the new audience needs another authorization system, another contractor directory, another ERP exchange, and another event history, the company still has independent products with similar screens.
Start with a map of intersections. For every role, list the key actions, the data involved, the current system, and the process owner. The entities and rules that overlap are candidates for the shared core. Unique work can stay in the interface built for that role.
That map gives a team a way to choose the first module without trying to build the entire future architecture at once. At Qtim, we can turn that map into a phased implementation plan.
Top comments (0)