Portal permissions in plain English: who should see what in your client portal

Portal permissions are rarely set up on purpose. More often they get decided the week a new client signs — someone is in a hurry, Circles get copied from the last engagement, and a few one-off toggles get flipped so the client can "just see their stuff." Then nobody looks again.

Months later, one of two emails arrives:

• "I think I can see something I shouldn't."
• Or: "Where do I find my invoice?"

Neither is really a SuiteDash problem. Both usually mean the map of who sees what no longer matches how the business actually works. The fix is less dramatic than a rebuild: decide roles, give each role only what it needs, and test from the client's side — not from your admin view.

Below is how we talk about portal permissions with small-business owners and professional services teams. Plain English. No jargon. A checklist you can run in one sitting on a small portal.

Why permissions drift

A client portal starts clean. Then reality happens.

A teammate gets temporary admin access for a launch week and keeps it. A former client login stays active because nobody owned offboarding. Two Circles overlap for the same service line, so one client sees forms meant for another. An internal document lands in a shared folder because that was the fastest place to put it on a Friday afternoon.

None of these moments feel like a crisis. Together they produce a portal that surprises people — yours and theirs. Automation and new modules make the same confusion louder, which is why we prefer to tidy permissions before we layer more on top.

Two problems, one root cause

When owners describe portal pain to us, it almost always falls into one of two buckets.

Oversharing. A client sees another client's folder, a draft proposal, an internal checklist, or staff-only notes. Trust takes a hit even when nothing sensitive was meant to be exposed. The client does not report this as "Circle misconfiguration" — they report it as unease.

Undersharing. The file they need exists, but their role cannot reach it. They email you. You dig it up. The portal quietly stops being useful, and email becomes the real system of record again.

Both come from the same root: permissions set once, quickly, and never revisited against real roles. Software did what it was told. The map was wrong.

Roles beat one-off toggles

Hand-picked permissions feel flexible in the moment. They become hard to audit six months later.

Roles (in SuiteDash terms: Circles and clear access patterns that match how your firm works) are easier to explain, easier to hand over when someone joins or leaves, and easier to test. A short map beats a long list of exceptions:

• Internal admin — full portal hygiene: Circles, modules, templates, client-facing links
• Internal staff — day-to-day client work for their service line; not every module, not every client
• Client (active) — their documents, forms, invoices, booking paths — nothing else
• Client (former) — usually no login, or a deliberately limited archive path if you keep one
• Partner / contractor — only the projects and folders they are hired for

You do not need ten roles. You need a few that match reality, written in language a new hire can understand. If you cannot explain a Circle in one sentence, it is probably doing too much.

A five-minute permission check

On a small portal, this is one sitting — not a project. Use it as a light audit:

1. List everyone who has a login. Active clients, staff, partners, and former clients who never got removed. If the list surprises you, that is already useful information.
2. Match each person to a role. Prefer roles over one-off permissions. If someone needs a special exception, write down why and who approved it.
3. Ask what each role genuinely needs to see. Most roles need less than they currently have. Start from "documents and tasks for their engagement" and add only what earns its keep.
4. Test with a real client login. Not from admin impersonation habits you half-remember — sign in the way a client does. Click the menu. Open a document. Try a booking or form. Note every dead end or surprise.
5. Name who owns permissions when someone joins or leaves. Same-day removal when a client or teammate exits should be a checklist item, not an afterthought three weeks later.

That five-step pass prevents the two emails owners hate most. It also gives you a clear baseline before you turn on more automation, more modules, or a bigger client load.

What "good enough" looks like

You do not need a perfect portal to serve clients well. You need a portal that does not surprise people.

In practice that means:

• A short written map of who sees what (internal roles, client types, partners)
• Circles that match that map — boring and predictable
• No orphan "admin because we were in a hurry" access
• Former clients and ex-staff removed on a known cadence
• At least one person who reviews access quarterly

Permissions should feel dull. Dull is a compliment. Exciting permissions usually mean someone is guessing.

When a Portal Health Check helps

Sometimes the five-minute check surfaces more than a tidy afternoon can fix: overlapping Circles across service lines, years of former logins, documents with no owner, or booking paths that only work from certain roles. That is where a structured look helps.

WrightClick's SuiteDash Portal Health Check (and Free Assessment path) is built for that moment. We walk goals and current setup in plain English, then hand back a practical fix list — not a jargon report. Permissions and Circles are usually near the top of what we review, because they sit under almost every other portal complaint.

If your portal still works but you would not want a new hire explaining it to a new client, that is enough reason to look.

A practical checklist

Use this as a light audit — not a scorecard:

• Everyone with a portal login is listed (including former clients and old vendors)
• Each person maps to a named role; one-off exceptions are written down
• Circles match real roles; overlapping Circles are intentional or removed
• Clients see only their documents, forms, invoices, and booking paths
• Staff see what their service line needs — not "everything"
• At least one login has been tested from the client side recently
• Join and leave checklists include same-day permission changes
• Someone owns portal access on a recurring cadence

If several items are open, pause before adding modules or automations. Automation amplifies whatever is already there — including confusion.

Next step

If you would rather walk the list with someone who does this often, that is exactly what we do. Start with a clear look at goals and current setup — not another toggle flipped in a hurry.

Book a Free Assessment / Portal Health Check and we will give you a plain-English fix list for who should see what.