A Small Customer Portal Needs More Than a Login Screen

Imagine a document preparation agency handling this situation. A customer portal prototype looks useful, but one customer can open another customer's file by changing a link.

For a document preparation agency, this is an illustrative situation, but the difficulty is familiar: the team can see individual pieces of work without a dependable explanation of what should happen next. It deserves a closer look before another tool is added. The aim is to make the next action clear without adding unnecessary administration.

The design focuses on signing people in without checking permission for each requested record. Identity and authorisation are confused.

Each request for data needs an authorisation decision beyond the login. The rule must apply to direct file access as well as the application's normal navigation.

The test should cover both ordinary navigation and direct requests for a known record reference. Hiding a link in the interface is insufficient if the underlying file remains accessible. Support access and administrative exceptions also need a deliberate authorised scope rather than unrestricted convenience. An isolated correction may be quick, but the same ambiguity can affect several people downstream. Before calling it a training issue, examine whether the process gives every person enough evidence to reach the intended conclusion without guessing.

Define which records each user may access and enforce those checks on the server for every action. Test file access, exports and support-user access as well as screens.

Use realistic records to check that staff can complete the whole task, including correcting a mistake. Describe the required relationship between records before discussing a new screen. The proposed tool should make its current state understandable rather than hide important uncertainty behind a simple button. Permissions, recovery and operational support belong in the design from the beginning. Keep the scope narrow enough that users can evaluate one complete workflow before more features are added. An existing application may already provide the needed structure through configuration or a supported extension. If a small custom component is justified, define what it owns and what remains maintained elsewhere.

A login alone does not make a portal secure, and specialist security review may be warranted.

For background relevant to portal record permissions, see The Cost of Building Software Nobody Uses. The issue here is the narrower workflow described in this example.

Use separate test customers and attempt to retrieve each other's records through direct file links. Compare the proposed result with the original source and the business's intended next action. A record arriving in the right application is not sufficient if its meaning changed on the way. Staff should be able to explain both what happened and what remains to do.

For portal record permissions, review the proposed outcome with the staff responsible. Check what an authorised user can see, change and recover in the proposed tool. The result should remain understandable to a colleague who did not create the record, including when the task is corrected or handed over. Keep ownership of the business rule separate from responsibility for maintaining the technology. Both matter if the process is to remain understandable after its initial setup.

At Software Logic, we help businesses examine practical improvements to small internal tools, starting with the work their existing tools need to support. What prevents an authenticated customer from opening somebody else's information?