Client Portal User Management Done Right

A client portal rarely has one user per client. A corporate client may have a main contact, a finance team, project staff and an executive who wants a summary, and people join, change roles and leave all the time. If every change needs an email to your support team, access drifts out of date: former employees keep logins, new staff share passwords, and sensitive invoices are visible to people who should not see them. Client portal user management is the set of features and rules that control who in each client organisation can access what, and how that access changes over time. This guide explains how to model client organisations and roles, how to handle invitations and offboarding, how to let clients manage their own users safely and how to audit it all, with a worked example.

Organisations, users and roles

The foundation is a clear data model:

• Organisation: the client company, which owns its data in the portal
• User: an individual person, belonging to one organisation (or occasionally several)
• Role: a named set of permissions within an organisation, such as admin, finance or viewer
• Scope: optionally, a subset of the organisation's data, such as specific projects, sites or subsidiaries

Every data request in the portal should be filtered by the user's organisation, then by role and scope. This must happen on the server; anything enforced only in the browser can be bypassed. The OWASP Authorization Cheat Sheet recommends denying by default and checking permissions on every request, which applies directly here.

Client portal user management: roles clients understand

Keep roles few and named in your clients' language. Three to five roles usually cover most needs:

RoleTypical permissionsClient adminManage the organisation's users, see all dataFinanceView and download invoices and statements, update billing contactsProject memberView and contribute to assigned projects, upload documentsViewerRead-only access to assigned projects or reports

Resist creating a new role for every special request. If many clients need a variation, add it as a permission option on an existing role or as a scope, rather than multiplying roles until nobody understands them.

Invitations and onboarding

Invite users by email with a single-use link that expires after a set time. On first use, the user sets a password or signs in with their organisation's identity provider, and enrols in multi-factor authentication if required. Record who sent each invitation and when it was accepted.

Decide who can invite. Usually your staff can invite anyone, and client admins can invite users to their own organisation only, with roles no higher than their own. For larger clients, single sign-on with the client's identity provider lets their IT team control access centrally, which many enterprise clients prefer.

Offboarding and access reviews

Offboarding is where access control most often fails. A former employee of a client who still has portal access can see invoices, documents and project details long after leaving. Reduce the risk by:

• Letting client admins deactivate users immediately
• Deactivating accounts that have not signed in for a set period, after warning the user and their admin
• Sending client admins a periodic reminder to review their user list
• Ending sessions and revoking tokens when a user is deactivated

The OWASP Session Management Cheat Sheet covers session expiry and invalidation in more detail.

Self-service for client admins

Delegating user management to client admins reduces support work and keeps access current, because the client knows who has joined or left before you do. A good admin screen lets them see all users, roles and last sign-in dates, invite and deactivate users, change roles within their own limits and resend invitations. Every change should be logged and visible to both the client admin and your staff.

Authentication choices

• Email and password with multi-factor authentication suits most small and mid-sized clients
• Single sign-on with the client's identity provider suits enterprises with central IT
• Passwordless email links can work for low-risk, infrequent users, but weaken security if email accounts are compromised

Offer multi-factor authentication to everyone and require it for roles that see financial or sensitive data. The OWASP Multifactor Authentication Cheat Sheet compares methods.

Worked example: user management for a managed IT provider's portal

Suppose a managed IT services provider runs a portal where its 150 business clients raise tickets, view assets and download invoices. Clients range from 5 to 2,000 staff. The provider designs user management like this:

AreaDecisionRolesClient admin, finance, requester, viewerScopeLarger clients can limit requesters to specific sitesInvitationsClient admins and provider staff can invite; links expire after 72 hoursAuthenticationPassword plus authenticator app, required for admin and finance; SSO offered to clients over 250 staffInactivityAccounts unused for 120 days are deactivated after two warning emailsReviewsClient admins receive a quarterly email listing users and last sign-in datesOffboardingDeactivation ends all sessions within one minuteAuditAll role changes, invitations and deactivations logged and shown on the admin screen

The quarterly review emails are designed to surface accounts belonging to people who have left, and delegating changes to client admins is meant to move routine access requests away from the support desk. The provider plans to track both: deactivations prompted by reviews and the number of access-related support tickets. The figures and periods are this provider's choices, shown to illustrate the approach.

Testing user management

• Test that each role sees exactly what it should, and nothing from other organisations
• Try changing IDs in requests to access another organisation's records
• Confirm deactivated users lose access immediately, including open sessions and API tokens
• Check that client admins cannot grant roles above their own or invite users to other organisations

Automate these checks where possible, so every release confirms that access rules still hold.

Common mistakes

• Filtering data in the browser rather than on the server
• Shared logins for whole client teams
• No way for clients to remove leavers themselves
• Sessions that survive deactivation
• Too many custom roles to understand or test
• No audit trail of who changed access

For the broader architecture of portals, see our guide to client portal development. The same access principles apply inside your own systems; our guide to CRM security covers them for internal users.

Frequently Asked Questions

What is client portal user management?

The features and rules that control which people in each client organisation can access the portal, what they can see and do, and how access changes when people join, move or leave.

Should clients manage their own portal users?

Usually yes, through a client admin role limited to their own organisation, with every change logged. Clients know about joiners and leavers first.

How do we stop former client employees accessing the portal?

Let client admins deactivate users instantly, deactivate inactive accounts automatically, send periodic access reviews and end sessions on deactivation.

Do client portals need single sign-on?

Not always. Password with multi-factor authentication suits many clients, while single sign-on suits larger clients that manage access centrally.

Get portal access right

We design and build client portals with role-based access, self-service user management and audit trails. See our custom app development services, or talk to us about your portal.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.