Testing portal access after a customer account is closed

Before closure, define who authorises it, whether a read-only interval applies and which records must remain internally. Use a fictional customer account and record the pages, records, search results, downloads and API requests it can access while active. Run the checks at closure and again when any authorised read-only interval ends.

After closure, open a clean InPrivate or Incognito window and try to sign in with the closed customer’s credentials. A rejected sign-in passes this check; a successful sign-in fails it, even if later page permissions deny access to records.

Keep the browser session that was signed in before closure open; do not sign out or clear its browser state. Reload a protected page and try to reuse that session. If it still returns data for the closed account, the session test fails.

Open a shared link created before closure and try the direct URL for a previously accessible record. Search for that record as well. Closed-account data returned through any of these routes is a failure; no matching data or denied access passes.

Try the existing download link after closure. If the portal serves file content, the test fails; if access is denied or no file content is returned, it passes. Revoking portal access cannot recall a file someone has already saved, so assess saved copies separately.

Repeat the authenticated API request used in the baseline test, then try the request without signing in. Either request returning closed-account data is a failure; denied access or no such data passes.

Repeat the protected-page and direct-record URL checks without signing in. A sign-in prompt, access-denied response or no matching closed-account results passes; any closed-account record or file content means the test fails. Apply the same rule to search and API results.

In Power Pages, Dataverse access through forms, lists, Liquid, the Portals Web API and other components is controlled by table permissions associated with web roles. In design studio, open Security > Table permissions, select the ellipsis next to the relevant table, choose Edit and check the assigned roles.

Check that the Anonymous users web role has not been granted a table permission for the data being tested. Anyone who visits the site can access table data when that role is granted permission; hiding a menu item alone does not establish that a record is inaccessible.

Record the closure time, role changes and a pass/fail result for each check at both runs. Keep any records that must remain internally separate from portal access.