Discuss your project
Business platforms

Designing a secure and useful client extranet: architecture, rights, documents, and user experience

An extranet is not a site to which one adds a connection. It becomes a boundary of the information system and must be designed as a business product.

Designing a secure and useful client extranet: architecture, rights, documents, and user experience

A client extranet is often presented as a series of screens: dashboard, documents, orders, profile, and support. In reality, it becomes a gateway to the information system. It exposes data, triggers operations, and represents the company in every interaction. Its design must therefore bring together product, architecture, security, and operations.

Success is not measured by the number of features. A good extranet reduces manual requests, makes information reliable, speeds up recurring tasks, and gives the client a clear understanding of their situation. It must also prevent a user from accessing another company's file, presenting an outdated document, or repeating an operation by mistake.

Start from the tasks, not the menu

The framing starts with customer relationship events: requesting a service, submitting a document, tracking a file, approving a proposal, downloading a report, paying, reporting an anomaly, or adding a collaborator.

For each task, document:

  • the trigger;- the necessary information;- the actor and his organization;- the possible states;- validations;- the systems involved;- the evidence to keep;- notifications;- errors and retakes.

This method avoids reproducing the internal structure of the company in the portal. The client does not need to know the names of departments or the technical codes to achieve their goal.

Define a single source of truth per data

The portal can display information from a CRM, an ERP, a business application, or document storage. The owner of each piece of data and the direction of synchronization must be designated.

A local copy can improve performance or resilience, but it requires a freshness rule, conflict management, and visibility on the last synchronization. Data entered in the extranet must be validated before being propagated into critical systems.

The browser should never become the source of truth for an important operation. Any action must be controlled server-side with an idempotency key when double submission is possible.

Design the authorization before the screens

Authentication answers 'who are you?'. Authorization answers 'what can you do on this specific resource?'. This second question is the most difficult.

A client can belong to a company, access multiple sites, delegate rights, or have a temporary role. The same person can be an administrator of one establishment and a simple reader of another. The model must therefore combine role, scope, and conditions.

The essential rules are:

  • default refusal;- server-side control on each action;- explicit scope by organization or resource;- separation of sensitive functions;- expiration date of the delegations;- logging of rights changes;- systematic tests of horizontal and vertical access.

Trust chain of an extranet, from authentication to business services and to the audit log.

Authentication: adjust the level of confidence to the risk

An account and a password do not always constitute a sufficient strategy. The extranet can offer multi-factor authentication, SSO with the client's identity provider, access keys, or enhanced recovery mechanisms.

The level must depend on the actions. Consulting news does not have the same impact as downloading a sensitive document or modifying a beneficiary. Reauthentication may be required before a critical operation.

The processes of creating, inviting, suspending, and deleting a user must be designed with the same care as the login. Orphan accounts and invitations without expiration are common risks.

Build an action-oriented dashboard

The dashboard must answer three questions: what is happening, what requires my attention, and what is the next action?

A stack of statistical cards is rarely sufficient. Priorities can be: missing parts, pending validation, deadline, incident, new version of a document, or support message. Each item must lead to a clear action and retain its context.

Indicators must use definitions shared with the business. A 'file in progress' should not mean one thing in the extranet and another in the back office.

Documents: version, proof, and access control

Document storage must distinguish the file, its version, its metadata, and its rights. A guessable or permanent URL must not bypass authorization. Sensitive downloads can use signed short links, always verified by the server.

For each document, provide:

  • type and status;- owner and perimeter;- date of issue and expiration;- replaced version;- fingerprint or proof of integrity when necessary;- storage rules;- logged access and downloads.

The preview must be isolated and incoming files analyzed. Unsafe formats must not be executed in the application context.

Notifications without sound or information leaks

A notification must inform without revealing sensitive data in an uncontrolled channel. The email can announce that a document is available, then redirect to the authenticated extranet instead of attaching the file.

The user must be able to choose certain preferences, but security alerts or contractual obligations may remain imposed. Sendings must be idempotent, traceable, and grouped when multiple events occur.

Integrations and asynchronous processing

Calls to third-party systems fail. The architecture must provide for message queues, retries, rate limits, delays, correlation, and visible status. An action must not be presented as completed if it is only waiting to be processed.

Incoming webhooks must be authenticated, safely replayable, and deduplicated. Outgoing APIs must apply appropriate delays, circuit breakers, and retry policies in order not to amplify a failure.

Research and navigation

Navigation by internal organization is rarely intuitive. A cross-sectional search can cover files, orders, documents, and references, while respecting rights before and after indexing.

Filters must remain understandable, preserve the state in the URL when it helps sharing, and provide an alternative to wide tables on mobile. Exports must follow the same scope as the screen.

Accessibility and actual usage

An extranet is often used in urgent situations, on a locked computer, a mobile device, or with assistive technologies. Forms must retain data in case of an error, clearly announce validations, and allow full keyboard navigation.

Complex tables require properly associated headers, a responsive view, and sometimes a card version. Session timeouts must be indicated and the user must be able to extend their session without losing their work.

Audit log and support

It must be possible to reconstruct important events: login, change of rights, download, validation, modification of data, sending to a third party. An audit log must be protected, timestamped, correlated, and limited to the necessary information.

The support has an assistance view that explains the context without allowing silent impersonation. Any takeover or impersonation must be explicit, authorized, temporary, and tracked.

Design the operation from the framing

The extranet requires technical and business supervision: availability, errors, blocked queues, delayed synchronizations, failed notifications, and abnormally abandoned workflows. Realistic service objectives must be defined according to criticality.

Backup, restore, disaster recovery planning, and secret management are part of the product. Test environments must use anonymized or synthetic data.

Measure the value

Good indicators are not limited to the number of connections. Track:

  • time required to complete a task;- share of requests processed without manual intervention;- number of follow-ups for missing part;- data entry errors and revisions;- deadline for making the documents available;- avoided or better qualified support contacts;- satisfaction on critical paths.

A decrease in connections can be positive if notifications and automations make some visits unnecessary.

An extranet is a durable product

The first version must prioritize a few complete, safe, and measurable paths. The foundations — identity, rights, data, audit, integrations, and observability — then make it possible to add functions without multiplying exceptions.

Partitech designs, takes over, and maintains business platforms connected to the information system. The intervention can cover functional scoping, architecture, user experience, development, security, testing, and the operation of the extranet over time.

Let's talk about your project

Frame or modernize your extranet with Partitech.Contact Partitech.

Share this article