> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/creating-profiles/multi-step-profiles.md).

# Multi-step profiles

Add a confirmation step and decide which result should produce an issue.

Build a sequence with the step buttons at the top of Pro's **Active Profile** editor. Each step has its own request, payload, matching and issue settings. A later step runs when the preceding step matches.

## Add and configure steps

1. Open an active profile with **Add** or **Edit** and configure **Step 1**.
2. Click **+** (Add new step). The editor adds the next numbered step.
3. Select the new step and configure its request, payloads, insertion points, Response and Issue tabs.
4. For later steps, choose **Same insertion point than the previous request** or **Any insertion point** as appropriate.
5. Use **Reuse Cookie** only when the workflow needs cookies from the previous response.
6. Switch between the step buttons to review the sequence.
7. Click **OK** to save the complete profile. Pro creates the step array in the `.bb` file automatically.

The **-** button removes the current step; the profile keeps at least one step. Switching steps preserves the current editor values in memory, but **OK** is still required to save the file.

## Reporting

For an intermediate step, open **Issue** and check **Don't show this issue alert**. On the confirmation step, leave it unchecked and enter the final issue title, severity, confidence and explanatory text.

Do not report a confirmed vulnerability merely because the preliminary request produced an interesting response.

## Example: probe and confirmation

For a controlled fixture whose original query is `?id=1`:

| Step | Original Request settings                                    | Response conditions                                                                                       | Reporting                       |
| ---- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | ------------------------------- |
| 1    | Param url value; Append a quote (`'`)                        | A specific database diagnostic                                                                            | Suppress the intermediate alert |
| 2    | Same insertion point; Replace with the known valid value `1` | A marker specific to the normal item response; add an AND NOT condition for the diagnostic if appropriate | Report a tentative indicator    |

Use the actual diagnostic and normal-response marker from your fixture. A generic success page is not a reliable control. The second step tests a known valid value; it does not reuse the already quoted request wholesale.

{% hint style="warning" %}
**Editing the supplied control**

The [downloadable multi-step example](https://github.com/BountySecurity/burpbountypro_documentation/tree/main/examples/profiles/multi-step-sqli.bb) is another preconfigured probe/control profile. Its control uses an enabled empty payload in the saved file. The current editor omits blank payload rows when saving, so verify or redesign that control in the editor before saving a modified copy. Do not assume a blank table row preserves the imported control.
{% endhint %}

## Cookie, insertion and engine differences

**Same insertion point** keeps the selected location; **Any insertion point** permits the next step's applicable points and can increase work. With Server's `$BBOUNTY$` mode, every step stays on the selected span even when the profile says Any insertion point.

**Reuse Cookie** carries response cookies from preceding matched steps into the selected step in both engines, including raw-request steps. New values replace an existing cookie with the same name/domain/path; deletion, expiry, Domain, Path and Secure restrictions are honored. Independent profile/payload chains have separate histories. Leave the option unchecked to retain the step's original cookies.

Neither engine is a full browser session: redirects, CSRF values and application state need deliberate design. See [redirect compatibility](/creating-profiles/redirections.md) when a step itself redirects.

Raw requests, method conversion, cookie reuse and match/replace are incompatible with Server's exclusive marker mode. See [compatibility](/creating-profiles/compatibility.md) before distributing the saved file.

## Validate the whole sequence

Test a positive sequence, failure at each intermediate step, and negative controls. Confirm intermediate steps do not report and the final finding has the expected request/response chain. Reopen the saved file in Pro and review every step. Conditional execution means total requests are not simply payload count multiplied by step count.