Case labs

What a case is

A case is one attempt at one lab, in your lab environment, for your account. It lists the resources the lab works with, the checkpoints the lab must reach and the evidence the server recorded for each one. A case lab shows it in Your lab case, near the top of the page. The lab's own text says what to do; this page covers the controls.

Start opens the case

Pressing Start in the lab's Setup rebuilds your Lab Tenant fresh, as for every lab, and opens a case for this lab. Everything Start sets up for the lab, such as its people, clients, album and services, is already in the case. The case shows its expiry time. Pressing Start again gives you a fresh lab tenant and a fresh case, and starting another lab replaces both, so finish one lab at a time. See What Start does.

Resources in this case

The checkpoints only look at resources in the case. Resources in this case lists each one with its type, ID, origin and version. Origin says whether the case created it (Created for this case) or it was already there (Already existed).

When a step asks you to create something the checkpoints look at, such as a signing key, an authorization rule or a federated credential, copy its ID from the portal page where you created it. Choose its type in Resource type, paste the ID in Resource ID and choose Add to this case. The server records the resource's current version. If a step changes it later, the lab says when to add it again so the case uses the new version.

Checkpoints

Open Checkpoints. Each list names a role in the lab, such as the client or the reader; choose the resource the lab names for it. Some labs also offer a fixed setting to compare, such as a clock allowance. Then choose Save checkpoint choices.

Some troubleshooting labs add an Incident block under Checkpoints. After you save your choices, Begin the incident makes the lab's fixed change to this case's own resources, such as rotating a client secret; a change window makes several. Audit records each change with Lab case automation as the actor, and your repair afterwards is recorded as yours. Your checkpoint choices cannot change once the incident begins.

Save before you do the steps the checkpoints look at: only activity after you save counts. You can change and save again until the first checkpoint is verified. After that the choices are fixed for this case; press Start for a fresh one if you chose the wrong resource.

Verifying a checkpoint

Checkpoints are verified in order, and the Checkpoint list offers the next one. Do the step, then choose Verify this checkpoint before you go on. Each checkpoint counts only what happened after the one before it, so a record from an earlier step, or from before you saved your choices, does not count.

Depending on the checkpoint, the form asks for one of these:

• Event or request ID: the Event ID of the record in your lab tenant's Audit that shows what the step did, or the ID of its request. The lab says which record to find and which ID to copy.
• Receipt ID: copy it with the copy button in the Receipt ID column of Safe service receipts in Guided services.
• Issuance event ID with a signed statement, or a token: what a hosted service gave you in the step. A token is sent for this one check and then cleared from the page. It is never stored.
• A cause to choose: what explains the result you saw.
• Nothing: the server reads the current state itself.

The server reads its own records and the resources in the case to decide. The page cannot mark a checkpoint as passed. When a check is refused, the message says why, for example that the record is from before the previous checkpoint, or does not match the resources you chose. Recorded evidence lists the record each verified checkpoint used, with its request ID, which finds the same request in Audit and Logs.

Recording completion

When every checkpoint is verified, choose Check case progress. The server checks the case again and records that you finished the lab. Checking uses your current permissions in your Lab Tenant, where Start makes you Tenant Admin and Lab Learner.

Hosted and guided services

Some cases come with services that BTL runs for them. Hosted lab services are fixed applications and workloads, such as an application that signs in through your lab tenant, a SAML receiver, a deployment pipeline or a workload. Guided services are the fixed agent with its order, render and storage services. Both use only the resources in the case and send real protocol requests to your lab tenant. They run only BTL's fixed code, never code you supply. See Hosted lab services and Guided services and the fixed agent.

Labs with Lab Mail

A lab that compares two tenants opens a partner case in your Second Lab Tenant, Lab Mail, when you press Start. Checkpoints show it under Partner case in Lab Mail. Add anything you create in Lab Mail with Add to the Lab Mail case, then choose it in the Lab Mail lists before you save your checkpoint choices.

Ending a case and cleaning up

You do not need to clean up after a case lab. The next Start, for this lab or any other, replaces your lab environment, and a case also ends when it expires.

End this case stops a case early. It removes the case's authority: its hosted and guided services stop, the tokens they were given stop working, and any keys the case held for its own comparisons are erased. It keeps the case's records: its resources, checkpoints and evidence stay readable, and your lab tenant's Audit and Logs keep their records as usual.

Where Start created an album and photos for the case, Delete this case's album and photos deletes exactly those. It refuses while the album holds a photo the case did not create. A case never deletes a resource marked Already existed, and never deletes people, clients or settings in your lab tenant. To stop one service without ending the case, use Stop this service in Hosted lab services or Stop this case's services in Guided services.

BTL staff in BTL's own organization

This section applies only to BTL staff working a case in BTL's own organization rather than in their Lab Tenant. BTL Admin offers the same guided-service controls as tenant management, built from the same components and permissions.

• Use existing verified BTL staff as the case's people. Skip the lab's temporary person fixtures and add those staff members' user IDs to the case. Tenant fixtures never create a BTL account.
• Create the case's album and photos through the case controls, for the staff member who acts as the subject.
• Staff added to a case are borrowed, never created by it, so cleanup preserves them, and adding them grants the case no authority to remove them.
• When BTL's own organization is the identity provider in a SAML or federation lab, choose an existing authorized BTL reader instead of creating one. The relying account in the other tenant is still a tenant-local account.
• BTL profile and email changes use that person's own Profile controls. Tenant editors cannot change BTL directory identity or credentials.