A customer portal brings information into a shared workspace, but the useful question is who should see or change each item. A contact, an organisation and a particular service request may have different relationships. Softglimmer plans customer portals for Calgary teams around those boundaries and the tasks people need to complete. Our office is in Ranchi and we deliver the project remotely through agreed reviews. Discovery inspects the current process and systems before defining a custom portal or connection. The first scope should give customers and staff an understandable working journey, with permissions and ownership that can be tested.
Identify the account and the people attached to it.
Agree access to each request and document.
Show the stage and responsible next action.
An example journey, shaped around your requirements.
Imagine a hypothetical Calgary service business where one customer contact can request work and another can approve documents. Staff currently share updates through email, making it difficult to see which person should receive each item. This is a working example, not a delivered portal claim. A portal scope needs to model the account relationship and the relevant permissions before presenting every company contact with the same workspace.
Define what each person can view, submit, approve or administer. The business should decide whether those responsibilities apply to an entire account or only to particular requests. A role name is not enough on its own: reviewers need concrete examples showing what information becomes available and which actions remain outside the person’s authority.
A request may be received, under review, waiting for information or completed. Agree what each state means and who may change it. The portal should explain the customer’s next action where one is needed, without exposing internal notes by default or presenting a staff activity as a commitment the business has not made.
Identify the account and the people attached to it.
Agree access to each request and document.
Show the stage and responsible next action.
Hypothetical planning sequence.
Identify how contacts relate to organisations, requests and documents. Review shared accounts, changed contacts and a person who works with more than one organisation. The chosen model should follow actual business relationships. Avoid relying on a shared email address as automatic evidence that every associated person may see all records for that account.
OWASP recommends validating permissions on every request. Hiding a button in the interface is therefore not the whole access-control design. The implementation review must test direct access to records and files for the agreed roles, including a person who has lost access. These are scoped acceptance checks, not a blanket security guarantee.
Agree which documents belong in the portal, who may upload or replace them and how the recipient identifies the current version. A shared file may need a narrower audience than the general request. The scope should also define correction and removal decisions with the business owner, rather than leaving those actions as unrestricted editor choices.
An invitation, changed contact or lost access creates an operating task after launch. Identify who administers it and what evidence they need before altering a person’s relationship. The portal’s support route should remain understandable when someone cannot sign in. Those responsibilities belong in the handover alongside normal customer requests and staff updates.
A task-based description of who may view or change each type of request, document and administrative setting.
Reviewed screens and flows for submitting requests, reading updates and carrying out the staff actions included in the first release.
Acceptance cases for allowed and denied access, account changes and request transitions, using bounded fixtures before any authorised live step.
Instructions for invitations, contact changes, document correction and support, with the people and system dependencies responsible for each task.
Prepare anonymised examples of the account relationships the business needs to support. Include a simple account, one with different approval responsibilities and a contact whose access has ended. Bring the systems that currently own requests and documents, along with the way staff explain status to customers. These examples help determine the model without copying private customer records into an exploratory fixture.
Choose one complete request journey for the first scope. Review the customer action, staff response, document visibility and completion decision together. A dashboard can look persuasive while leaving ownership unresolved, so acceptance should follow the record through each state. Test what happens when the wrong person opens a direct link or a former contact tries to access the item.
Remote review needs a Calgary process owner who can make relationship and permission decisions. Our Ranchi team prepares concrete flows and bounded checks for that review. Connections to an existing CRM or document system require their own access and capability inspection. A locally validated portal is a development milestone; provider configuration, deployment and approved production operation remain separate evidence boundaries.
Kokoro is a real Softglimmer website introducing a local commerce and delivery platform, with customer, vendor, delivery partner and franchise information. It illustrates public communication for different audiences. The portfolio is website evidence; it does not prove the portal permissions, private document access or customer account workflow proposed for Calgary here.
Only if that reflects the business’s approved relationship and information policy. Discovery reviews the tasks and records involved before choosing roles. Some documents or approvals may require narrower access. The portal should make those boundaries explicit and test them with representative contacts rather than inferring authority from the company name.
The interface should reflect permissions, but access also needs enforcement when the request reaches the server. We test direct record and file requests in the agreed implementation. The review includes denied cases and changed access, because a hidden control alone does not establish that the underlying information is protected.
Nominate administrators and a support owner for account changes, invitations and document corrections. Our Ranchi team documents the agreed tasks and dependencies. The handover should explain when staff can resolve an issue themselves and when a technical or connected-system owner needs to investigate it.