For apps where what you can see and do depends on the role, and each role needs its own test account.

Your setup

Say this to Certyn

We have admin, member and guest roles. Save a test account for each, so runs can test what every role can and cannot do.

Opens the sign-in form for the main account, for example the member. It saves LOGIN_USERNAME and LOGIN_PASSWORD.
For each other role, opens a secret form per value with a clear name: ADMIN_USERNAME, ADMIN_PASSWORD, GUEST_USERNAME, GUEST_PASSWORD. A username is not secret, so you can also type it in the chat and Certyn saves it as a plain variable (app.variable.set). You approve.
Saves them on the current environment, or on the project if all environments use the same accounts.
Writes the account map to the wiki's testing rules, for example: admin: ADMIN_USERNAME / ADMIN_PASSWORD; member: LOGIN_USERNAME / LOGIN_PASSWORD; guest: GUEST_USERNAME / GUEST_PASSWORD. Every run reads these rules.
Offers to restart the Machine, so it gets the new variables.
Proposes test cases that name the role, for example As guest, open /admin and expect "Access denied".

You type passwords only in the forms. The chat never sees them.

It lists the variable names (account.env.list) and types a secret into the focused field by its name (account.secret.type), without seeing the value.
Scripts on the Machine read them as environment variables, for example process.env.ADMIN_PASSWORD.

The sign-in form saves one account (LOGIN_*). Other roles are named variables, one form per secret.
Runs pick the account from the goal, the test case or the wiki. Name the role in each test case.
For a test with two roles (admin invites, guest accepts), write the steps to sign out and sign in as the other role.
Do not use reserved names such as USERNAME, USER or names that start with CERTYN_. The Machine leaves them out.
A role with authenticator 2FA needs its own key, for example ADMIN_TOTP_SECRET. See App with 2FA from an Authenticator App.