Test Customer Portal Invitations, Expiry, and Offboarding

A customer portal's access lifecycle starts before the first login and continues after someone leaves a customer organization. Testing only a successful invitation misses expired links, invitations sent to the wrong account, changed roles, and sessions that remain open after membership removal.

Build an acceptance exercise around one synthetic customer organization and several test users. The objective is to prove who can enter, what they can see, and what happens when the original permission no longer applies.

Write the invitation contract

Specify who may invite, which organization receives the member, the permitted role, the intended identity, and the invitation lifetime. State whether acceptance creates membership immediately or requires another approval. The email and the portal should describe the same process.

Auth0's organization invitation documentation illustrates that invitations can carry an organization, recipient, application, roles, and expiry duration. Those fields are useful review questions even when your portal uses another provider; its actual capabilities must be checked separately.

Choose the lifetime based on the workflow and risk review. Do not copy a provider's default as a universal business rule. Record what a person sees after expiry and how an authorized administrator issues a replacement.

Test the paths around successful acceptance

Use a harmless test document belonging only to the synthetic organization. Run the following scenarios and inspect actual access after each one:

• Accept a valid invitation with the intended identity and confirm the agreed role.
• Open the link after it expires. Confirm that no new membership is granted and that a replacement path is understandable.
• Cancel a pending invitation, then attempt to use the old link.
• Issue a replacement and test what happens to both the earlier and newer links.
• Open the invitation while signed in as a different test user. Confirm that membership cannot silently attach to the wrong identity.
• Use a second test organization to check that the link cannot grant access across customer boundaries.

If the product requires single-use invitations, include a second acceptance attempt as an explicit case. Verify the requirement against the implemented provider behavior rather than assuming that “invitation” implies every safeguard.

Inspect roles after the person joins

For a hypothetical portal, a customer viewer may read service updates but cannot invite colleagues or approve requests. Test those boundaries through both the normal interface and direct requests or links, with the development team's help.

Hiding an administrative button does not demonstrate that the underlying action is denied. Ask for evidence that the server applies the intended organization and role checks. Use a known test resource reference to verify that changing the URL does not reveal another organization's document.

Also change the user's role while a browser tab remains open. The next attempted restricted action should follow the new policy. Decide what message explains the change and how the user returns to an allowed task without losing unrelated work.

Rehearse offboarding with active sessions

Open the portal on two test sessions before removing the membership. Then attempt to load a new service update, open a document, and perform a previously permitted action from both sessions. Include a direct link saved before removal.

OWASP's session guidance explains why expiration and invalidation need server-side controls. Closing a tab or clearing a browser value is not sufficient evidence that access has ended.

Agree on how quickly removal must take effect and how the application enforces it across its identity and authorization layers. Test the actual timing and token behavior. Do not promise instant revocation if the implementation cannot demonstrate it.

Keep offboarding separate from deleting business history. A departed employee's past approval may need to remain attributable while their future access ends. Document who takes ownership of pending approvals and whether shared links or scheduled notifications require separate action.

Keep an access lifecycle record

For every scenario, record the initial membership, invitation or role change, attempted action, expected decision, observed decision, and time. Reference invitation records without copying usable invitation secrets into screenshots or support notes.

Ask the administrator to complete the expiry and removal paths using the intended controls. A developer's database edit can help investigate a defect, but it does not prove that an ordinary administrator can safely manage access.

These scenarios describe a proposed test plan, not an audit result or a guarantee about a provider. Contact Dynelink to define the invitation, role-change, and offboarding acceptance cases for a customer portal.