Enterprise system
Employee, customer and supplier portals
Define the experience, identity, orchestration and status boundary of a portal while authoritative transactions remain in enterprise systems.
Page purpose
Define the responsibility and boundary of Employee, customer and supplier portals before choosing extension, integration or replacement.
Employee, customer, and supplier portals provide role-based access to journeys that cross enterprise systems. A portal should own presentation, session context, submitted request state, and user communication only where agreed; it should not silently duplicate authoritative HR, customer, supplier, order, invoice, inventory, or case records.
The decision starts with complete journeys, not front-end products. Identity proofing, delegation, accessibility, Arabic-English parity, source-state freshness, exception ownership, and support demand determine which experiences can share a shell and services and which audience-specific channels need separate treatment.
Failure modes
How system failures surface in real work.
- Users navigate separate portals and repeat identity, contact, document, and request data.
- A portal displays stale status because it copies records instead of reading or subscribing to authoritative state.
- Self-service stops at submission and gives no owner, evidence request, exception path, or resolution status.
System boundary
What the system owns and what remains outside it.
- Which state belongs to the portal and which must be read from or written to a source system?
- Which journeys genuinely benefit from a shared shell and services, and which have distinct identity, delegation, or support constraints?
- How are individuals, organizations, delegates, support agents, and account recovery verified and authorized?
Target state
Clearer responsibilities and a target operating state.
- A coherent role-based journey that preserves authoritative records in source systems.
- Shared identity, delegation, notification, document, and case patterns across portal audiences.
- Accessible bilingual experiences with traceable requests and transparent operational status.
System design
Models and contracts specific to the system boundary.
- Portal journey, audience, identity, delegation, and source-record boundary map.
- Experience and integration contracts for profiles, requests, cases, orders, invoices, documents, and status.
- Journey-by-journey channel decisions scored on identity, delegation, accessibility, data freshness, service ownership, and reuse.
- Rollout design for accessibility, localization, session security, traffic, support, analytics, and coexistence.
Transition
Changing the system while operations continue.
- Prioritize complete user journeys and identify each source record, decision, exception, and responsible team.
- Define identity proofing, role, delegation, organization membership, and account-recovery boundaries.
- Build reusable channel services without letting the portal database become the unintended authority for enterprise data.
- Release journeys incrementally with bilingual, assistive-technology, load, security, and service-desk testing.
Record and operating integrity
Protecting record integrity and continuity during transition.
- Duplicating operational data in the portal and presenting a plausible but stale status.
- Using one role model for employees, customers, and suppliers despite different identity and delegation needs.
- Splitting requests across old and new channels during coexistence so that evidence, ownership, or status is lost between them.
System measures
Measures that reveal improvement in real work.
- End-to-end journey completion without assisted channel, repeated entry, or unresolved handoff.
- Status freshness, source-write success, synchronization error, and request-to-case reconciliation.
- Accessibility findings, Arabic-English parity, page and API performance, authentication failure, and support demand.
Decision questions
System decisions a product alone cannot answer.
Should a portal store copies of enterprise records?
Copies should be limited to bounded caches or channel state with explicit freshness and recovery rules. Customer, employee, supplier, order, and financial authority should remain in the relevant domains.
Can one portal serve employees, customers, and suppliers?
A shared platform may serve them, but identity proofing, roles, delegation, journeys, data boundaries, and support must remain audience-specific.