Monito now tests beyond login: roles, 2FA and repeatable setup

The test you want to run often starts several steps inside your application. A manager needs to approve a request. A new user needs to confirm their email. A customer needs an existing order before they can request a return.

To test those flows, the browser needs the right account, the right permissions and the right starting data.

Monito now supports saved login roles, reusable login sessions, authenticator codes, email codes and magic links, plus reusable setup and cleanup for configured test resources. You can test more of the work your users actually do, with less preparation between runs.

The scenario stays in plain language. Describe what to do and what should happen. Monito finds the controls, performs the actions and records the evidence.

Here is what that makes possible, with scenarios you can adapt to your application.

Test the same feature with different permissions

Save your test accounts as named Login roles in a project's environment. For example, manager, member and viewer. Select the role when you create a scenario.

A role tells Monito which saved account to use. The account's permissions still come from your application. You can configure different accounts for staging and production without putting passwords in the scenario.

Suppose your app lets managers edit tasks while viewers can only read them. Save two scenarios against the same prepared workspace.

Select the manager role:

Sign in with the selected login role and open the QA workspace.
Open the task named "Update the welcome page".

Change its priority from Normal to High, then save it.
Reload the page and reopen the task.

Expect the priority to remain High. Expect the task's title and
description to remain unchanged.

Select the viewer role:

Sign in with the selected login role and open the QA workspace.
Open the task named "Update the welcome page".

Expect to be able to read the task. Expect no available action
that lets this account change its priority or delete it.

Open the task's edit-page URL supplied for this test.
Expect the application to refuse editing and keep the task unchanged.

Use your application's expected access-denied behavior in the second scenario. Some applications show a permission message; others deliberately show a not-found page. State the behavior you expect.

These are separate runs, each with one selected role. They give you a practical way to check both the allowed journey and the restricted one.

Reuse a login when you are testing work inside the app

If a test is about editing a task, signing in is a prerequisite. If a test is about signing in, login is the feature under test.

You can now make that choice explicitly.

Enable Reuse login sessions on a saved role to let Monito reuse its encrypted login state. Each run still gets a separate browser. Saved state is scoped to the account, project and environment, and retained for up to one hour.

This lets several scenarios reach the authenticated part of your app without repeating a fresh login on every run.

Open the dashboard using the selected login role.
Filter tasks to show only items assigned to this account.

Expect every visible task to belong to this account.
Clear the filter and expect the full workspace task list to return.

For a login regression test, select Start logged out in the scenario. That makes the run exercise sign-in even when the role allows saved sessions.

Start on the sign-in page and use the selected login role.
Expect a successful login to open the dashboard.

Log out, then navigate directly to the dashboard URL.
Expect the sign-in page to appear and no private dashboard data
to be visible.

A separate browser keeps browser state separate. If several tests change the same records in your application, use separate test data too.

Complete authenticator-based two-factor login

Monito can now complete login flows that use time-based one-time passwords, or TOTP: the rotating codes shown in authenticator apps.

Configure the test account's authenticator secret in its login role. Monito generates and enters the current code through its protected credential handling. The AI does not need the secret or a code pasted into the scenario.

Select Start logged out when you want the test to cover both login steps.

Sign in with the selected login role.
Complete the authenticator-code step when it appears.

Expect the account dashboard to open only after that step succeeds.
Open Account settings and confirm that the account shown matches
the selected test account.

Log out and expect to return to the sign-in page.

You can also save a separate scenario that checks the boundary before the code is entered:

Enter the selected account's email and password to reach the
authenticator-code screen. Leave the code field empty.

Navigate directly to the dashboard URL.
Expect the application to require authentication and keep private
dashboard content hidden.

This support is for authenticator codes. SMS codes, push approvals and hardware security keys use different authentication methods.

Test email verification with a real test inbox

Email authentication spans your application and the inbox. Monito can now follow that journey using a configured Resend test inbox.

Monito creates a fresh receiving address for each login attempt. It looks for a new message addressed to that attempt, from the configured sender, with the configured subject prefix. It can use either a one-time code or a magic link.

That gives each attempt its own email destination and keeps an old message from being mistaken for the current login email.

The inbox setup belongs in the login role: a dedicated receiving domain, a Resend API key that can read received email, the expected sender, the subject prefix, and the message type. Keep those credentials out of the scenario.

Example: email-code signup

Use a disposable test-inbox role configured for one-time codes. Your application must allow signup with the generated address. If signup requires a password, configure that password in the role too.

Open the signup page and register using the provided test email
address and the configured signup password.

Expect the application to ask for email verification.
Retrieve the code from the matching test email and enter it.

Expect verification to succeed and the welcome screen to open.
Complete onboarding with the display name "QA Member".
Expect the dashboard to show that name.

This exercises requesting the email, receiving it, submitting its code and continuing into the application.

Example: magic-link entry into a new account

Use a disposable test-inbox role configured for magic links. This example fits an application that creates an account when a new email address signs in.

Open the email sign-in page and request a magic link using the
provided test email address.

Expect a confirmation that the email was sent.
Open the matching magic link from the test inbox.

Expect the application to open onboarding for the new account.
Finish onboarding and expect the account dashboard to appear.

The current inbox integration uses disposable addresses. For an existing account with a fixed email address, use the existing-account login method where supported; this inbox flow does not read that account's personal mailbox.

Prepare a starting state once and reuse it

Many scenarios share the same first steps: sign in, select a workspace, open a project and find a record.

You can keep those steps in each scenario, or save them as Reusable setup in the project's Environments area. The setup is also plain language. Monito runs it before the selected test and checks that it succeeded.

For example, save a setup named Open the QA workspace:

Sign in with the selected login role and open the QA workspace.
Open its Tasks page.

Expect the workspace name to be visible and the task list to load.
Expect the task "Update the welcome page" to be present.

Select that setup for scenarios that check filtering, task editing or assignment. Each scenario can focus on its own behavior:

In the workspace opened by setup, filter tasks by High priority.
Expect "Update the welcome page" to appear when its priority is High.

Change the filter to Low.
Expect the task to disappear from the filtered list.

The test's starting data must match those expectations. Prepare the task with the required priority, rather than depending on a previous test to leave it that way.

If setup fails, Monito stops the test and records the setup failure. A missing workspace should be explained as a missing prerequisite before the task-filtering test starts.

Give each run its own data and clean it up afterward

For workflows that create or change records, shared starting data can cause interference. Two tests that edit the same order are still editing the same order, even in separate browsers.

Monito now supports configured test resources with setup and cleanup. A developer connects the application's test-data endpoints through the CLI/API. Monito gives each run a unique identifier so those resources can be created and removed within that run's scope.

For example, a configured setup could create a disposable workspace with a draft order. The scenario then tests the browser flow:

Open the draft order prepared for this run.
Add two units of the $12 test item.

Expect the item subtotal to be $24 before tax and shipping.
Save the order, reload the page and expect the quantity and subtotal
to remain unchanged.

Afterward, Monito runs cleanup for the configured resources. Cleanup recovery can continue if the test executor stops unexpectedly. The report shows when cleanup remains unresolved so you can act on it.

Automatic cleanup covers the resources declared in that setup. A browser-created record needs its own cleanup strategy; Monito does not infer which records in your database are safe to delete. A disposable workspace can be useful when deleting it also removes the records created inside it.

The reusable browser setup works without test-data endpoints. Add the resource integration when your tests need isolated data and cleanup that can recover after an interruption.

Keep reruns tied to the setup they used

Reusable setup is versioned. Editing it creates a new revision, while existing scenarios retain their saved selection until you choose the updated setup.

That matters when investigating a failure. You can see which setup the test used, instead of finding that a shared prerequisite changed between runs.

Monito's existing rerun controls also let you choose the original or current scenario configuration. The original configuration now includes its saved setup references.

An original-configuration rerun preserves that test configuration. The application and its external services can still change between runs.

Inspect the journey without exposing login secrets

Authentication tests need useful evidence. They also need to protect the credentials used during the run.

Monito keeps configured passwords, authenticator secrets and inbox API keys out of AI requests. Protected authentication capture masks private fields. These runs can use a replay assembled from masked checkpoints, so the report remains useful without exposing a continuous recording of sensitive input.

Setup results, test results and cleanup status help explain where a run stopped. You can also read the evidence through the Monito CLI:

monito run view <run-id> --evidence --json

The output includes evidence completeness and screenshot references. Check any reported missing artifacts alongside the verdict.

Run your first authenticated scenario

Start with one journey your users depend on:

1. Open your project's Environments area and add a Login role for a test account.
2. Add authenticator or disposable-inbox settings if that journey needs them.
3. Create a scenario and select the role under Saved login and setup (optional).
4. Select Start logged out if you are testing sign-in itself. Attach reusable setup if the test needs it.
5. Write the actions and expected result in the scenario, then run it and inspect the report.

For a saved scenario, you can also launch it from the CLI:

monito scenario run <scenario-id> --no-wait --json
monito run view <run-id> --evidence --json

The first command returns the new run ID. Use that ID in the second command to read its current result and evidence as the run completes.

Open Monito and create your authenticated test. Choose the account, describe the journey and tell Monito what a successful result should look like.