[Blog]()Portals # Portal permissions: each customer sees permitted records A valid session does not permit every file. Check the same boundary in search, downloads, exports and shared links. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** To define customer portal permissions, link each person to company, location, documents and allowed actions. Test allowed and denied access with fictional accounts, including direct links, files and open sessions after revocation. Preserve decision evidence and do not assume protection because a section is hidden. ## Test ten customer access boundaries Use fictional customers, locations and documents for allowed, denied and revoked access; observed results are blank. [Download CSV worksheet]() In this guide - [Signing in does not authorize every record]() - [Example: a North link reaches Green]() - [Test revocation from an open session]() - [Require allowed and denied cases]() ## Signing in does not authorize every record A customer portal should check who is accessing it, their company and location, the requested document and permitted action. Hiding a menu section does not establish file protection. The same rule must hold for search, direct links, downloads, exports and changes. [OWASP recommends]() granting only needed privileges, denying by default and checking authorization on every request. [Microsoft warns]() for Power Pages that hidden pages are not secured and direct downloads should be tested with unauthorized and signed-out users. These are those sources' recommendations and conditions; demonstrate your own boundaries. | Person |Scope |Allowed action | | --- | --- | --- | | North purchasing contact |Blue, North location |View authorized North orders | | North administrative contact |Blue, North location |View enabled North financial documents | | Central contact |Blue, Central location |Only enabled Central records | | Green contact |Green customer |Only Green records | | Signed-out or revoked |No private records |Denial without private data | ## Example: a North link reaches Green **Synthetic scenario in an authorized test** Blue and Green are fictional customers. DOC-41 belongs to Blue-North with a test financial document. BN may view those North documents; BC only Central; G only Green. No real accounts or documents are used and no third-party portal is tested without authorization. BN opens DOC-41 successfully. Copy its link and try as G: expect denial without file, amount or other private details. BC should also be denied despite belonging to Blue because the test scope is Central. Signing in identifies a person; it does not automatically expand permitted locations. G searches for DOC-41's number, exports permitted documents and opens a detail view. No path should reveal Blue. Staff examine content, totals and files, not just a hidden button. If special sharing links exist, define issuer, allowed actions, expiry and withdrawal; each exception needs its own test. North's purchasing contact sees orders but not DOC-41 under the matrix. Switching to the authorized administrative profile requires approval and scope reevaluation. A received URL must not expand access. Repeating the same assignment should preserve the same permission rather than enable every location. ## Test revocation from an open session In another variant, BN loses access while a session is open. The next request and new download should be denied under the defined rule; another sign-in must not restore permission. Preserve revocation approver and time. Check outcomes after the change as well as administration-screen text. Do not treat an already downloaded copy as disappearing when future access is revoked. Define handling and retention with responsible staff. Keeping permission history does not mean keeping a user enabled. If access was revoked by mistake, restoration needs approval and a new scope test. | Path |Check |Outcome for G requesting DOC-41 | | --- | --- | --- | | Menu and search |Content and totals |No record or private details | | Direct link |Document or view |Denial without content | | Download and export |Files and rows |Only authorized Green data | | Data change |Record and action |No changes to Blue | | After revocation |New request and download |Removed permission stays unavailable | ## Require allowed and denied cases - Create two fictional customers and two locations within one. Establish allowed access before comparing denied cases. - Test the same document from another company, location, unprivileged profile and signed-out person. - Use search, direct links, downloads and exports. Check private data in totals and error messages too. - Remove permission with the session open. Test an approved expansion and its repetition. - Record test user, action, expected outcome, observed outcome and evaluated version without passwords or production documents. These ten tests do not certify complete security. They examine concrete boundaries before invitations and after material changes. If another customer's data appears, record the case and correct the boundary before widening access; hiding information after delivering the file is insufficient. Technical staff should expand testing to actual scope. Prepare profiles, customers, locations, documents and actions. Decide access and revocation authority, sharing exceptions and private data. For general scope, review the [customer portal guide](); for commercial controls, [B2B customer prices](). A [custom portal]() consultation can examine the matrix before defining screens. ## Review who may see each document A free consultation can examine your customer, location and action matrix before defining the portal. - Customer profiles, locations and allowed actions, without credentials. - Three fictional document types and their permitted viewers. - Access, revocation and sharing-exception approval authority. [Book a free consultation]()[Ask on WhatsApp]() Related - [Sales and customer portal]() - [Custom ERP and CRM]() ## Frequently asked questions ### Does hiding a menu protect documents? It does not establish protection. Test search, direct links, downloads and exports with an unprivileged person. Deny content, not only hide a button. ### Do all contacts see every location? Only if your rule allows it. Define scope by contact, company, location and action; check that company membership does not expand permissions without approval. ### What should I test after revocation? New requests, downloads and sign-in from an already open session. Preserve approval and history, verifying that removed permissions do not return. ### Do ten cases guarantee security? No. They are a starting point for these boundaries. Expand and repeat testing for actual functions, documents, changes and risks. ## Sources 1. [Authorization and least privilege]()OWASP 2. [Power Pages security and download testing]()Microsoft Learn Last updated: October 8, 2026 ## Keep reading [SalesOct 8, 2026 ### Customer prices in a B2B portal: validity, discounts and tests]()[Change auditingOct 8, 2026 ### Change audit logs: who changed what and how to investigate a difference]()[GuidesOct 2, 2026 ### What a customer portal is and when your business needs one]() --- Canonical: https://nightlysoftware.com/en/blog/customer-portal-access-tests Updated: 2026-10-08 Description: Test boundaries by customer, location, document and action. Check direct links, downloads and revocation with ten downloadable synthetic cases.