Designing a Unified Account Ecosystem: From Fragmented Portals to a Shared Core

As businesses grow, it's common for different audiences (customers, partners, employees) to gain their own dedicated portals. While initially practical, this often leads to architectural fragmentation, where each portal maintains its own accounts, directories, statuses, permissions, and integrations. This siloed approach results in data inconsistencies, complex access management, and significant overhead when onboarding new roles or integrating new systems.

The Problem of Fragmentation in Multi-Audience Systems

The core issue arises when a single business reality is represented in multiple, disparate systems. For example, a supplier's delivery date might differ between an ERP system and a customer portal, or a contractor might exist under various names across different products. This leads to:

• Stale Data: Information changes in one system but isn't consistently propagated to others.
• Complex Access Management: Each portal has its own user model, making changes to user roles or organizational affiliations a laborious chain of requests.
• Redundant Development: New roles require rebuilding basic functionalities like login, permissions, notifications, and audit history.
• Unclear Ownership: When multiple systems can modify the same entity, the authoritative source of truth becomes ambiguous.

Building a Shared Core for a Connected Account Product

To counter fragmentation, the article proposes building a "shared core" layer. This layer would manage core business entities and process states, such as organizations, users, documents, payments, permissions, and events. This contrasts with simply implementing Single Sign-On (SSO), which only addresses authentication and doesn't resolve data consistency or authorization complexities.

The shared core should establish clear "systems of record" for each key entity, defining where the source of truth resides. This involves specifying the direction of data exchange and handling failure scenarios (e.g., using queues and idempotent operations for reliable event delivery). This architectural pattern allows for distinct interfaces for different user roles while ensuring consistency and a unified understanding of business reality underneath.

Key Components of a Shared Core

• Unified Identity Model: A single representation for a person, capable of acting for multiple organizations or roles.
• Organization Context: Explicitly manages the context in which a user is operating, allowing a single person to represent different entities.
• Centralized Role and Permission Model: Defines stable permission sets and uses context (organization, region, object type) for fine-grained authorization checks.
• Shared Entities & Systems of Record: Clearly designates the authoritative system for critical business entities (e.g., ERP for invoices, CRM for deals, account product for preferences).
• Robust Integration Patterns: Employs queues, idempotent operations, and event logs for reliable and traceable data exchange between systems.

While building a shared core is an investment, it becomes critical when the account product handles money, documents, permissions, or is part of a critical customer path. The ultimate test of this architecture is whether a new role can be connected as a module, reusing existing identity, organization, data sources, and audit trails, rather than requiring an entirely new standalone launch.