Start a journey signed in
There are two ways to test an authenticated feature:
- Let the journey sign in itself, using variables or credentials published by a parent journey. Choose this when the login flow is part of what you are testing.
- Give several journeys a saved browser session so they start inside the product. Choose this when login is setup, not the behavior each journey should measure.
Saved sessions belong to one site. They contain browser cookies and storage, not a Journeys account session.
Create and refresh a saved session
- Create a custom or catalog journey whose job is to sign in from a signed-out browser. Teach and approve it like any other journey.
- Open Site settings → Sessions and choose Add a session.
- Give the session a recognizable name and select the login journey under Refreshed by.
- Optionally add a signed-in check for the session: a URL fragment under URL contains, text under Page shows, or both.
- Save, then run the login journey. Its next passing run fills the session.
Every later passing run of that login journey replaces the saved state, so a nightly login schedule can keep it fresh. A failed login run leaves the last working session untouched.
The Sessions list reports when the state was captured and how many cookies and browser origins it contains. It never reveals the cookies or storage. The state is encrypted and decrypted only for a browser run that uses it.
Use the session in another journey
Open the target journey and select the saved session under Start signed in. Save the journey and perform an attended run to confirm it starts in the right account and area.
If you configured a signed-in check for the session, Journeys tests it before the agent's first step. URL contains compares the destination's host and path, and Page shows looks for the supplied text; both must match when both are present. A journey cannot start with a session that has not been captured yet. A captured session that fails this liveness check is Could not check, not a false claim that the product is Down.
Deleting a session does not delete journeys that selected it. Their selection is cleared and future runs start signed out, so edit or pause them first.
Email confirmation
For flows using Journeys' test mailbox, the agent gets a unique test email address and generated password for that run. It can wait for the message, enter a verification code, or open a confirmation link. Codes and links travel through the same protected channel as secret variables and are redacted from evidence. On a resend, Journeys waits for the new message rather than reusing an invalidated code.
If a message says the address was refused or already registered instead of containing a code or link, the run reports that reading as the blocker. It does not guess a code.
Unsupported authentication paths
The current hosted interface does not provide SMS or TOTP retrieval. It also does not offer browser-session capture for third-party social-login flows, and Google is known to reject replayed automated sessions even when the cookies are valid.
Check the application after its own login when possible. If the exact provider handshake or a non-email second factor is essential to the journey, that flow is not currently supported.