Two step types connect a Test Case to an Authenticated Profile. Inject Profile loads a saved session so the Test Run starts signed in, and Capture Profile saves the current session as a Profile part-way through a run. Most Test Cases only need Inject Profile, at the very top, in place of the sign-in steps you would otherwise write.

Both steps find a Profile by its name, which is why Profile names matter and why renaming one breaks the steps that point at it. On a Test Run, the name resolves like a Variable: the Profile of the run's Environment wins over the project Profile with the same name. See How do I make my tests start already signed in?

The Test Run now begins with your application already signed in, and your remaining steps can go straight to the screen under test.

Under the field, one line tells you what the step uses on the Environment selected in the editor, for example "On Staging, this step injects the profile admin." If nothing matches the name, the editor warns you up front: "No profile or pool is named "admin". An earlier capture step can create it." That is a warning rather than an error, because a Capture Profile step earlier in the same test is a legitimate way to create it.

Open Advanced settings in the step to see three options.

Inject Profile has an Exclusive option. It reserves the Profile for this Test Run, and other runs that inject the same Profile wait until this one finishes, then continue. A run that waits more than 15 minutes fails.

Use it when the Test Case changes state that belongs to the signed-in user, such as editing that user's settings or consuming a one-time item. Two Test Runs doing that at once on the same account interfere with each other, and the failures look random.

Leave it off for Test Cases that only read. Reserving a Profile that many Test Cases share turns parallel runs into a queue, which is a common cause of a suite that suddenly takes far longer. When parallel runs each need their own account, inject a pool instead: see How do I give each parallel run its own account?

A Test Case can try the saved session first, and sign in with its own steps when the session no longer works. It then passes alone and inside a Test Set.

When the saved session works, the sign-in steps do not run.

Capture Profile stores the current browser session under a name you choose. Put it after steps that sign in.

Use it when the sign-in must happen inside the Test Case, for example when the account is created earlier in the same Test Run, and you want later Test Cases to reuse the result.

By default, the step writes to the Profile of that name on the run's Environment if one exists, and to the project Profile otherwise. When neither exists, it creates a project Profile. Turn on Save per environment to make each run save the session into the Profile of its own Environment, and create that Profile when it is missing. A sign-in Test Case that runs once on each Environment then fills every Environment with no manual recording.

A Capture Profile step targets one Profile. It cannot name a pool.

Both steps accept a Variable in the Profile name, so one Test Case can reach a different Profile per Environment or per data row.

Write the name with a Variable in it, for example acme-[ENVIRONMENT_NAME], and Thunders resolves it when the step runs. The Variable resolves first, then the Environment rule applies. A Profile name cannot contain the | character. To use another account per Environment, an Environment Profile with the same name is usually simpler than a Variable in the name. See How do I make my tests start already signed in? and Variables.

First, before any step that assumes a signed-in user. Injecting after you have already navigated means the earlier steps ran signed out.

When the Test Case writes state belonging to the signed-in user, so two Test Runs cannot collide on the same account. Leave it off for read-only Test Cases, because it serializes every run that injects that Profile and one waiting over 15 minutes fails.

Keep the Profile name stable, since steps resolve a Profile by name, and leave Renew the saved session on. When a Profile shows Session rejected in the Authenticated Profiles list, record it again under the same name. To keep a Test Case passing while nobody has recorded it yet, set the step to Continue with a warning and add sign-in steps behind a Conditional Step.

Yes, as long as Exclusive is off. With Exclusive on, the Test Runs queue behind each other.

A single Inject Profile step at the top of the Test Case. That is the whole point: it takes out the part of a test most likely to break on a multi-factor prompt or a redirect, and it makes every run start faster.

Yes. Both steps accept one, so acme-[ENVIRONMENT_NAME] resolves at run time. The name cannot contain |.

Keep one Profile name in the step, and give Production its own Profile with Override for this environment in its Environment settings. A Test Run on Production injects the Production Profile, and a Test Run on any other Environment injects the project Profile.

With Fail the test, the default, the Test Run stops at that step. With Continue with a warning, the step reports an issue and the Test Run goes on, and it passes if the later steps pass. A run that waited too long for a reserved Profile or a pool fails in both cases.