Nobody owns the portal's scope
A ServiceNow customer portal stays maintainable for as long as one named person can refuse a page. Most portals lose that person inside the first year. The portal ships for one purpose, customers log cases and read knowledge, and the project team moves on.
Then the catalogue team wants their items on it, because customers already sign in there. Field service wants order status, because most of the phone calls are about order status. Marketing wants community content surfaced. Somebody's director saw a competitor's portal and wants three things from it. Every one of those requests is reasonable on its own and was defensible in the meeting that approved it.
Two years later the portal carries case submission, knowledge, a service catalogue, community threads, order status and a shipment tracker, and no page explains why it sits beside the next one. The architectural problem here is ownership of scope rather than capability. Nobody rejected anything, so the portal became the union of everything anyone asked for.
One portal for everyone, or one for customers
The first structural decision is whether internal users and customers share a portal. Sharing saves genuine build effort. One theme, one page set, one search configuration, one place to fix a bug. Teams already running CSM and ITSM against one CMDB tend to reach for one portal by the same instinct, and the saving is not imaginary.
The cost arrives on every access decision afterwards. Once an employee and a customer contact can land on the same page, every widget has to answer which of them is looking at it. Record access rules carry part of that weight, and so does every conditional in the page and every link in the header. Getting account hierarchy and contact visibility right matters more in a shared portal, because one page has to be correct for both populations.
My default is separate portals when the two audiences have genuinely different jobs, and one portal when the difference amounts to a handful of extra links. A support agent working a queue does not need the customer portal. A partner engineer who books jobs and raises cases probably does. Decide it once, write down the reasoning, and expect to be challenged in a year by somebody who only sees the duplicated theme.
Widgets that do too much and widgets that do too little
A portal page is a set of widgets, and maintainability lives at that boundary. A widget that renders the case list, handles the filter, runs the attachment upload and posts the customer comment cannot be tested in pieces or reused elsewhere without dragging all four behaviours along. It becomes the widget only one person will touch, and that person changes jobs.
The opposite habit produces its own bill. Thirty widgets, each rendering one label or one button, turns every page change into a hunt through a dozen records and every upgrade review into a lost afternoon. The useful size is a widget that owns one visible thing a customer would name out loud. A case list. A knowledge search box. An entitlement summary.
Where business logic sits is the part that hurts later. Logic written into a widget's server script is invisible to anyone reading the platform's server-side configuration. A developer investigating why cases from one account come out at the wrong priority checks business rules, script includes and flows, finds nothing, and concludes the behaviour must come from an integration.
Keep the rule in a script include the widget calls, or in a business rule on the table, and let the widget handle presentation and the call. The test for where a rule should live is who must never be able to bypass it. A rule enforced only in a portal widget is bypassed by every integration, every API call and every agent touching the record in the platform interface.
Search failure comes back as case volume
A portal without good search turns into a case-creation machine. The customer types three words, sees nothing useful, and does the only other thing the page offers. The portal built to reduce contact volume drives it instead, and the numbers show deflection close to zero while case counts climb.
Search quality on a portal is mostly content and configuration. Which knowledge bases the search reads, whether entitlements filter the results, how results are ordered, and whether anybody reviews the searches that returned nothing. That last report is the cheapest improvement on offer and almost nobody opens it weekly. The same economics drive self-service deflection on other platforms.
The catalogue fails in the same shape. Two hundred items in a flat list with internal wording produces exactly the behaviour bad search produces, because the customer gives up and opens a case describing what they wanted. Categories customers recognise, titles in the words a customer would use, and a hard annual review that retires items nobody ordered will do more than any redesign.
Decide what an anonymous visitor may see
Anonymous access is a security boundary, and it usually gets settled in a design conversation about friction. Somebody points out that making people sign in to read an article is unfriendly, the knowledge base opens to the public, and nobody writes down which articles that decision covers.
Work it from the other end. Name what an unauthenticated visitor may see, category by category, and keep that set to the smallest one that still answers a prospect's questions. Public knowledge, public catalogue items anyone may request, a contact form. Anything naming a customer, an entitlement, an asset or a case stays behind authentication.
The common failure is quieter than a widget exposing the case table. A search index picks up an internal knowledge base. A widget renders for anonymous visitors because nobody loaded the page while signed out. Test the portal signed out as carefully as you test it signed in, and repeat that test after every release that touches search.
Fast for you, slow for the customer
A portal page assembles data from several places. A case list, an entitlement lookup, a knowledge suggestion, an order status call into an external system. Each is fine alone. Together they set the page load, and the slowest call decides what the customer sits through.
The testing gap is geography and network. Developers open the portal from the corporate network on a laptop a few hops from the instance, and it feels quick. A customer opens it on a phone on a home connection in another country. Nobody on the project has measured that, and the first evidence is a complaint that the portal runs slowly, with no page named.
Measure it properly. Take the three pages customers actually use, load them from outside your network on an ordinary connection, and record how long each widget's server call takes. The method used for other external-facing portals transfers cleanly, because the causes repeat. Too many server calls on one page, a list query with no limit behind it, and an integration call made while the customer waits.
Customisation is the upgrade bill
Branding pressure lands on the portal early, because it is the one part of the platform customers see. A theme, a logo, fonts and spacing cost nothing at upgrade time. Copying a delivered widget and changing fifty lines inside it costs plenty, because you have taken ownership of that code permanently. Every family release improves the original, your copy gets none of it, and somebody has to compare the two by hand.
The discipline is configuration first, extension second, forking last and recorded. Most delivered widgets take options. Where they do not, a small wrapper widget that calls a delivered one survives an upgrade far better than a fork does. When a fork really is the only route, record which delivered widget it came from and which version, because the person handling the next upgrade will not know.
Before the next team asks for a page, write the portal's scope on one page and have the platform owner sign it. Name the audience it serves, the three or four jobs it exists to do, the test a new request has to pass, and the person who decides when the answer is no. Then take the next request to that document in front of the people who asked. The document is what gives somebody the standing to refuse.
