Client portal permissions should follow each person's work and their relationship to a request. Being part of the same client company does not, by itself, settle who should see every conversation or approve every change.
Before choosing a portal, describe which requests each contact needs to see, which actions they can take, and who approves that access. A small example makes those decisions easier to discuss than a feature list.
One client can have three different jobs
Consider a hypothetical maintenance business building a portal for its commercial clients. This is an illustrative planning exercise, not a Wired Loom client case study.
One client has three contacts:
- Maya, the site coordinator, submits repair requests for one location and answers questions about those jobs.
- Jon, the operations manager, needs an overview of repair requests across that client's locations and decides which proposed work goes ahead.
- Lee, an outside specialist, contributes measurements and files to one assigned repair.
Calling all three people “client users” leaves important questions unanswered. Should Maya see a request from another location? Can Lee read the discussion about the proposed price? Does Jon's ability to approve work also let him invite new contacts?
Write the intended answers before designing their dashboards. For this example, Maya gets access to requests for her assigned location, Jon gets the client's repair overview, and Lee gets only the material needed for his assignment. Those are proposed business rules to validate with the people responsible for the work.
Choose the boundary around each request
There are several useful ways to describe visibility: a person's own requests, requests shared with selected participants, requests for an assigned location, or requests across a company. A portal may support only some of these patterns.
HubSpot provides a concrete product example. Its support portal offers individual contact tickets, tickets associated with the contact's primary company plus their own tickets, or company tickets for selected contacts who meet defined criteria. Those choices belong to that product; they do not establish the capabilities of every portal. HubSpot's customer ticket permissions documentation explains the available settings.
In the maintenance example, “own requests” could be too narrow for Maya when a colleague submits a job during her absence. Company-wide access could be too broad for her location-based responsibilities. That gap is useful information for a supplier: the requirement is location membership, not simply a bigger list of tickets.
Ask the supplier to demonstrate your actual boundary. If the product cannot express it, decide whether to change the process, choose a different product, or include the additional behavior in a custom build.
Separate seeing a request from acting on it
A person who can read a request may still need different permissions for replying, attaching files, approving work, closing a job, or inviting someone else.
Microsoft Power Pages illustrates this distinction by combining record access based on relationships, such as a contact or account, with specific privileges and web roles. Microsoft's table permissions guide documents that model.
For Jon, “can approve repairs” is still incomplete. The business needs to decide which client's repairs, whether approval covers the current proposal only, and what happens if the scope changes afterward.
For Lee, a single request page might combine technical details with commercial discussion. If he needs only the technical material, ask whether the product can separate those parts. Do not assume that hiding a menu item or removing a button establishes the underlying access rule.
Keep these distinctions in the scope document. Otherwise, “three user roles” can sound settled while the team still disagrees about what each role means.
Write one access worksheet before adding screens
Wired Loom's founder note on working with real business processes describes starting with the part of the business causing friction and keeping the first scope close to weekly work. Applied here, that means walking through one real request with the people involved before committing to a portal's screen list.
The following worksheet is a planning suggestion based on that approach. It is not a claim about a previously delivered project.
For each contact type, complete these five lines:
- Work to complete: the task this person needs the portal for.
- Requests and information visible: the company, location, assignment, conversation, and files included.
- Actions allowed: the specific changes or decisions they may make.
- Access approved by: the named business owner who authorizes membership or broader access.
- Access changes when: a reassignment, completed engagement, or departure triggers a review.
An example entry for Lee might read: “Supply measurements for repair R-104; see its shared technical brief and assigned files; upload measurements and answer technical questions; access approved by our service manager after client confirmation; review access when the assignment closes.”
That sentence gives a builder more to work with than “add a contractor role.” It also gives the business a chance to notice missing decisions while they are still inexpensive to discuss.
Decide what happens when contacts change
Return to the same example six months later. Maya moves to a different location, Jon appoints a replacement, and Lee finishes the assignment.
Who changes their access? Does the replacement inherit earlier request history? Should Maya retain access to old jobs after moving? Who confirms that a newly invited person belongs to the correct client and location?
Record those decisions alongside the original worksheet. Removing a person's access and deciding what request history the business keeps are separate matters. Avoid treating account deletion as the automatic answer to both.
The useful output is an assigned responsibility: someone knows who authorizes the change, someone applies it, and the expected result is clear.
Ask for a demonstration with separate sample clients
Use sample data to try one request type with the three contact patterns and a second, separate client company. Have the supplier demonstrate the agreed views and actions, including a saved link to a request a contact should not access.
OWASP distinguishes signing in from authorization and recommends defining permitted resources and operations, enforcing permissions on each request, and testing those rules. A hidden screen alone is not an access control. OWASP's authorization guidance provides the technical basis for those checks.
Use the demonstration to resolve business ambiguity too. If Maya cannot cover a colleague's open repair, the implementation may match the written rule while the rule still fails her job. Update the worksheet and agree on the revised scope.
For a first portal, a clear answer about one request and three contacts is a useful starting deliverable. Bring that request, the people involved, and your draft access worksheet to a discussion about Wired Loom's portal and custom software services.