Your customers phone and e-mail to ask for information you already hold. Someone looks it up and re-types it into a reply. A portal fixes that, but only if you can be certain that each customer sees their own records and nothing else — which is the part that makes people nervous, and the part the platform handles rather than leaving to your code.
Launch a secure customer portal.
The information is not missing. It exists, it is accurate, and it is sitting in a system your customers cannot reach. Every request for it is a small tax paid by someone on your side, and the volume is high enough that it never quite becomes anyone's priority to fix.
The reason portal projects stall is almost never the interface. It is isolation. The moment one login can see another customer's invoice, the portal is worse than no portal — and if that guarantee is implemented as a WHERE clause somebody remembered to add to each query, then it holds until the day a developer writes a new screen in a hurry. That is a real class of breach, and it is why cautious organisations quietly decide to keep answering the phone.
The second thing that stalls them is scope. A portal is easy to specify as "everything the customer might want", at which point it is a year of work and gets cancelled. The version that succeeds does three things the customer asks for most often, and gets used.
A branded portal on your own domain, with sign-in either through platform accounts or your existing identity provider, and two-factor authentication where the data warrants it. Customers see their own records — documents, orders, cases, invoices, whatever the relationship consists of — and can raise the things they currently phone about.
Isolation is enforced at the data layer through security groups and row-level permissions rather than in each screen. A record belongs to a customer, and the permission model decides visibility before a query is written. New screens inherit that model, which is the property that matters: the guarantee does not depend on the next developer remembering it.
Where the portal needs to accept as well as show — an order, a claim, a document upload, a support request — that goes through the same forms and workflow engine as the internal side, so a customer submission lands as a real record in your process rather than as an e-mail someone has to transcribe.
Every record that a customer will ever see needs to be attached to that customer. This sounds obvious and is the step most often skipped; getting it right at the start is what makes everything after it safe by default rather than safe by review.
Platform accounts with self-service password reset, or federation to Active Directory, Azure AD or Google for corporate customers who will not tolerate another password. Two-factor by SMS or an authenticator app where the data justifies it, and account end dates where access should lapse on its own.
Security groups and row-level permissions define what a customer account can reach, and the rule lives with the data rather than in each screen. Field-level permissions handle the cases where a customer should see the record but not every column on it — internal notes, margin, the assessor's comments.
Status, documents, and the ability to raise something. Almost every portal that gets used is mostly these three, and almost every portal that does not get used spent its budget elsewhere first.
Custom domain, your branding, responsive so it works on a phone, and a page builder for the surrounding content so marketing can change the wording without a developer.
Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.
| Feature | What it does | Why it matters here |
|---|---|---|
| Security groups & row-level permissions | Unlimited groups, membership in several at once, and visibility rules that run down to individual fields. | This is the whole ballgame for a portal. Isolation is a property of the data model, so a screen added next year inherits it rather than having to re-earn it. |
| AD / Azure AD / LDAP | Link multiple existing domains and tenants so users sign in with the account they already have. | Corporate customers increasingly refuse to issue their staff another password. This is often the difference between adoption and a portal nobody logs into. |
| 2FA — SMS & TOTP | A second factor after username and password, by SMS code or an authenticator app. | Once a portal holds anything personal or financial, this stops being optional in your customers' security questionnaires. |
| Document management | A library with version control, full-contents indexing, custom fields and an audit trail on every upload. | Replaces e-mail attachments with one current version and a record of who has seen it. |
| Forms & workflows | Generated forms with conditional fields and save-and-resume, feeding multi-stage workflows. | What the customer submits arrives as a record inside your process, not as an e-mail someone re-types. |
| Auditing | Every change recorded with who, when and from which IP address. | When a customer disputes what they were shown or when they were told, there is an answer. |
Sign-in, isolation and one thing the customer can see. Deliberately small, deliberately real — proving the access model with live data is worth more than any amount of design work.
Documents, submissions and the routing behind them, then whatever the first cohort of customers asks for once they are actually using it.
Adding a screen, a field or a permission afterwards is configuration. Most clients take that over; a few keep us on retainer for it. Both are fine.
Because it is not enforced per screen. Records carry their owning customer, and security groups plus row-level permissions decide visibility before any query runs — so a screen written later inherits the rule instead of having to reimplement it. That is the structural difference between a portal that is safe and one that is currently safe.
Yes. The platform links to Active Directory, Azure AD and LDAP, including several domains or tenants at once, and those users work with security groups exactly like platform accounts do.
Yes — custom domain, your branding, and a page builder so the surrounding content can be edited without a developer.
Yes. The layout is responsive, and it can be installed as a progressive web app where customers would rather have an icon than a bookmark.
Then the portal can read it rather than replace it — external databases can be linked directly, or the API and datastore sync can keep the two in step. See systems integration.
Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.