# Test authenticated user journeys

Test signed-in user flows with Composal Verify. Set up dedicated accounts, assign personas, and check role-specific outcomes using recorded browser evidence.

## Choose test accounts and roles

Choose a journey whose result depends on sign-in, such as an administrator inviting a teammate or a member viewing a restricted page. Use dedicated test accounts and only the permissions that journey needs. Use a separate persona for each role you want to exercise.

Decide which actions the run may take and which records it may create, change, or delete. Include cleanup in the journey when you permit temporary test data. Keep passwords and other secrets out of scenario text, source control, and screenshots.

## Configure sign-in

Open the project's **Credentials** and configure how the browser should sign in. Owners and administrators manage credentials; members can view metadata without revealing saved secret values.

- Use [managed credentials](/docs/verify/credentials/managed) for passwords, authenticator codes, email sign-in, saved browser sessions, or passkeys.
- For a Better Auth application, use [Composal sign-in with test personas](/docs/verify/credentials/better-auth) when you want sign-in without saved passwords or cookies.

Follow the [credential reference](/docs/verify/credentials) to choose the account and describe when to use it. If the app is private, [configure network access](/docs/verify/guides/private-apps) as well: reaching the app and signing in are separate requirements.

## Write a role-specific journey

State the starting URL, account or persona, allowed actions, and observable expected outcome. For example: sign in as a member, open the billing settings, and verify that administrator-only controls are unavailable. Use a dedicated administrator persona in a separate journey when testing those controls.

Describe the product behavior you expect rather than implementation details. An account reaching a dashboard does not prove that its permissions are correct. Check the protected operation or visible restriction that matters to the user.

Save the Scenarios and prepare a run using the [Verify workflow](/docs/verify#test-runs). To repeat the journey on pull requests, follow [GitHub preview testing](/docs/verify/guides/github-previews).

## Start a journey in Messages

When Composal enables Messages for your organization, open the assistant's Environment and enter its iMessage number in **Your App’s iMessage Number**. Choose the country or paste a complete international number; Composal formats it as you type. **Composal Test Number** selects a configured Composal number, with a sole available number selected automatically. An Environment can have a website URL, a number, or both. Save it and record the customer's approval for that exact pair. Sendblue requires the assistant to message the tester first; a dedicated Photon line can initiate after approval. In a version 2 Scenario file, give its single actor `messaging: true`. The run starts on Messages and texts the assistant from Composal's tester number. It can exchange attachments and open an account link in a new tab. Put sign-in in an explicit `authentication: true` step so the browser signs in after receiving the link. Add a later step to return to Messages and check the continuing conversation. The browser can open any link in a new tab; a rich preview appears automatically when available.

Messages waits up to two minutes for an assistant reply within the run's overall time limit. A reply from another run or an unverified message does not count. Review both tabs in the run's browser recording and the Messages conversation in its evidence.

When the assigned credential uses Google or GitHub, its provider sign-in can be completed during the explicit authentication step after opening the account link.


## Numbers for staging and PR previews

For staging, edit the number on the Environment. New runs use the new target revision; existing runs retain their captured conversation and history.

In **PR Testing**, use **Configured number** to copy one destination to each preview, or choose **From deployment** to resolve it from your selected comment or CI source. Dynamic URL and number fields must come from the same complete announcement. Hosting deployment events and Composal previews support a configured number; dynamic phone discovery uses GitHub comments or CI.

For GitHub comments, detect a deployment announcement or enter the literal label immediately before the number. Trust only your deployment bot. A dynamic phone announcement must include the full deployed head SHA on a `Commit:` line:

```text
Preview URL: https://preview.example.com
 iMessage Number: +15552220000
Commit: 1111111111111111111111111111111111111111
```

Omit the URL line for a phone-only template. Incomplete, ambiguous, untrusted, or stale announcements leave the run waiting. Numbers from CI use the action's `imessage-number` input or GitLab's `COMPOSAL_IMESSAGE_NUMBER`. Include the preview URL in the same handoff when the template has one.

Open the resolved preview Environment from the run to approve the conversation and inspect readiness. One tester/destination pair can serve one active Environment. To test overlapping previews against the same destination, choose another configured tester locally on the blocked preview before preparing it. This leaves the PR default and other previews unchanged. No number is allocated automatically.

Closing, archiving, revoking, or expiring a preview stops new admissions. Its conversation retires once leases and uncertain sends clear, preserving history. Retirement only permits a later reservation when pair reuse is enabled for the organization. A new reservation needs fresh approval. Phone-only Environments run authored Messages Scenarios; discovery and relative identity probes require a website URL.

## Check the result

Review assertions and browser evidence to confirm the journey used the intended role and reached the expected state. If sign-in fails, inspect the credential setup and refresh expired sessions before interpreting later steps as product failures.

Recordings and findings are part of the result. Read [evidence and verdicts](/docs/verify/agent#evidence) to distinguish a passed assertion, a reproducible failure, and work that could not run.