Web Portals

The Mapping Between a Login and a Customer Record

The portal has its own idea of who someone is, and the CRM or ERP has another one. Between those two sits a mapping, and it is the piece most often left implicit until it breaks. A person is not the same thing as an account: one buyer may need to see three ship-to locations, a contractor may work for several of your customers at once, and a distributor's staff change without anyone telling you. Deriving the link on the fly from an email domain works right up until a customer uses a shared mailbox, brings in a consultant, or gets acquired, so the mapping is better stored explicitly, with an owner and a record of who changed it.

The other half is what ends the link. An account that was correct when it was created does not stay correct: people leave the customer's company, a partner agreement ends, a project finishes. Nothing inside your systems observes any of that on its own, so the portal needs a deliberate answer. These are decisions, and they cost less to make before the first account exists than after the portal has real users.

• Whether one login maps to one account, or to several accounts with a selector after sign-in and a clear indication of which one is currently in view.
• What happens when a person moves from one customer to another: the old link has to be severed without deleting the history of what they did under it.
• How much an administrator on the customer's side is allowed to do, whether that is creating logins for their own colleagues only, or also changing what those logins can see.
• What an account does on its own after long disuse, since dormant accounts are the ones nobody remembers to remove.
• Whether part of the audience arrives through their own identity provider while the rest need accounts you issue, because a portal serving both is running two account lifecycles side by side.

Reading From Systems Built for Internal Users

A portal asks questions of systems that were sized for internal staff doing internal volumes, and two costs show up immediately. The first is rate limiting: CRM and ERP APIs commonly meter requests per user or per organization over a rolling window and return HTTP 429 with a Retry-After header once you pass it, which a client is expected to honor rather than retry straight away. The second is round trips. A page showing one customer's order history can quietly become dozens of calls if every line, contact and document reference is fetched separately, so a bulk or query endpoint that returns a page of records in a single call is worth the less tidy code it produces.

The third cost is vocabulary, and it is the one that outlives the build. An order status inside an ERP may carry a dozen values, several of which describe things a customer should never be shown, such as a credit hold or a margin flag. Collapsing that list into a small set of external states is a business decision rather than a development one, and it has to be written down somewhere durable, because the internal list changes whenever the process changes and the portal will go on translating the retired values until somebody updates the map. The practical questions are these.

• Whether the source system exposes a documented API at all, or whether the only access is a read replica, a scheduled export, or a database view that someone has to keep maintaining.
• Whether calls run under one service account or under the end user's own identity in the source system, since that decides where authorization is genuinely enforced.
• What the portal does when a rate limit or a timeout is hit: a queued retry, a cached last known value with its age shown, or an honest message.
• Which internal status values map to which customer-visible states, and who owns that map when the process is revised.
• Whether writes carry an idempotency key, so that a customer who taps submit twice on a slow phone connection does not create two requests.

Documents Are the Part That Looks Simple

Every portal specification has a documents area, and it usually gets estimated as though it were a list. The list is the easy half. The files themselves live in other places: the ERP generates invoices and statements, a document management system holds signed agreements, and a shared drive holds everything nobody ever classified. Each of those has a different notion of which document belongs to which customer, and the shared drive normally has none at all, which means the association has to be created before anything can be exposed. That work is data preparation, not development, and it belongs to whoever knows the filing convention.

Delivery is the other half. Routing every large file through the application server makes the portal slower and its memory use unpredictable; where the storage supports it, the application checks the request and then issues a short-lived signed URL scoped to that single object, so the transfer happens directly from storage. A signed URL is a bearer credential for as long as it is valid, which is why the expiry belongs in minutes rather than days and why such links should never be emailed or logged. Both halves, where the files live and how they are handed over, reduce to a short list of decisions.

• Where each class of document actually lives today, and whether a usable link to a customer record already exists in that system.
• Whether documents are generated on demand from the source system or copied into portal storage, which decides what a customer sees after a document is corrected and reissued.
• How large files are delivered, through the application or by a signed URL with a short expiry, and what the expiry should be.
• Whether a document ever has to be withdrawn after posting, and what a customer who already downloaded it is told.
• Whether uploads are accepted, which brings file type and size limits, malware scanning before anything is stored, and a decision about who gets notified that something arrived.

Where the Authorization Check Actually Lives

A portal's authorization is only as strong as its least careful query. If the filter that restricts results to the signed-in user's organization is written by hand in each endpoint, every new endpoint is a fresh opportunity to omit it, and the omissions tend to appear in whatever was added after launch: an export, a printable view, a lookup that fills a dropdown. Pushing the constraint down into the data access layer changes the failure mode. The tenant identifier comes from the session, never from the request, and a query written without it fails instead of quietly returning everything.

Identifiers and logs are the supporting half. Sequential integers in URLs invite a curious user to change one and see what comes back; a correct check makes that harmless, but opaque identifiers remove the temptation and make the attempt stand out. Recording which identity read which record, with a timestamp, is what allows a suspected disclosure to be answered with evidence rather than with reasoning about the code. The checks below are the ones worth automating so they run on every change.

• Request each endpoint using one user's session together with another user's record identifiers, and assert that the response is a refusal rather than data.
• Run the same test against exports, printable views, and every API the front end calls, since those are routinely added after the first security pass.
• Verify that role limits hold on writes as well as reads, because read filtering is usually the only thing anyone tests.
• Check what an expired or revoked session does in the middle of a workflow, and that no half-submitted transaction is left behind.
• Confirm that a request for a record belonging to someone else returns the same response as a request for a record that does not exist, so the portal does not confirm what it refuses to show.

When Something You Already Own Could Be the Portal

Not every self-service requirement needs a portal built for it. A handful of customers who each want one report do not need a login; they need the report scheduled and delivered. A document exchanged twice a year does not justify an account and a password reset process. And many CRM and ERP products ship a customer or partner portal module already, so when the requirement sits close to what that module does out of the box, switching it on is the cheaper answer.

Those modules get abandoned for reasons of fit rather than capability: the fields the customer needs are custom ones the module does not surface, the screens cannot be reworded away from the vendor's own vocabulary, or the licensing scales with the number of external users. Custom development earns its place when the portal has to span more than one back office system, when the workflow is specific to how you operate rather than to how the vendor assumed you would, or when the external audience grows large enough that per user licensing becomes the dominant cost. Before deciding either way, put the module you already own to these questions.

• Does it read the custom fields you actually use, or only the vendor's standard data model?
• How are external users licensed, and does that price scale with the number of customers you intend to invite?
• Can it present data from a second system, or does everything it shows have to live in that product already?
• Can its screens be reworded enough that customers are not required to learn the vendor's terminology?
• What happens to it when the host product is upgraded, and do the changes you made to it survive that?