> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/web-testing/environment-data-management.md).

# Environment Data Management

{% hint style="info" %}
**Who is this for?** Testers, SDETs, and QA managers who manage the data their tests depend on — environment variables, database connections, data-driven profiles, and workspace-wide global variables — from a single place.
{% endhint %}

**Environment Data Management** is the consolidated workspace for everything your tests read and write at runtime. It brings environments, test data profiles, and global variables together under one page, with read-only and read-write permissions on individual values so teams can share data without overwriting each other.

Open **Environment Data Management** from the Test Development area of the portal. The page opens on the **Environments** tab and provides three tabs:

| Tab                    | Manages                                                                                                           |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Environments**       | Per-environment variables, database connections, and the test data profiles linked to each environment            |
| **Test Data Profiles** | Data-driven tables whose structure is shared across environments and whose values are independent per environment |
| **Global Data**        | Environment-agnostic variables available to every test case in the workspace                                      |

All values use the same `${variableName}` reference syntax in test steps. See [Test Data Management](/web-testing/test-data-management.md) for how variables resolve inside steps.

## Prerequisites

* You have a workspace created with at least one environment.
* You are a workspace member with permission to edit data (Editor or Admin role).

***

## Permissions: read-only and read-write

Most values in this workspace carry a permission setting shown as a toggle:

* **RW** (read-write) — test cases and team members can both read and update the value.
* **RO** (read-only) — the value is visible and usable in test steps, but protected from edits.

Set a value to **RO** to lock down shared data — such as a stable account ID or a reference table — so that a test run or another team member cannot change it accidentally. Switch back to **RW** when you need to edit it.

***

## Environments tab

The **Environments** tab lists every environment in the workspace. Each environment is a named deployment target (for example, `Staging`, `QA`, or `Production`) that holds its own variables, database connections, and linked profiles.

### Browsing environments

* Use the **Search environments...** box to filter by name.
* Use the view toggle to switch between **grid** (cards) and **list** (table) views.
* The environment marked **DEFAULT** is used when no other environment is selected. You cannot delete the default environment.

### Creating an environment

1. Click **New environment**.
2. Enter a **Name** and an optional **Description**.
3. Save the environment. It appears in the list, and you can open it to add variables, databases, and profiles.

### Environment actions

From an environment card or the environment detail header, you can:

* **Clone** — create a copy of the environment, including its configuration.
* **Edit details** — change the name or description.
* **Delete** — remove the environment. This is disabled for the default environment.

### Working inside an environment

Click an environment to open its detail view. The detail view has three sub-tabs:

#### Environment variables

Key-value pairs scoped to this environment. Test cases read and write them according to each variable's RO/RW permission. Reference them in steps with the `${ENV.KEY}` syntax.

The table shows four columns — **NAME**, **TYPE**, **VALUE**, and **PERMISSION** — plus row actions.

To add a variable:

1. Click **Add variable**.
2. Enter the **Name** and **Value**.
3. Select the **Type**:

   | Type         | Use for                                                  |
   | ------------ | -------------------------------------------------------- |
   | **String**   | Plain text values such as URLs and labels                |
   | **Number**   | Numeric values                                           |
   | **Boolean**  | `true` / `false` flags                                   |
   | **Password** | Secrets that are masked in the UI and redacted from logs |
   | **Vault**    | Values resolved from a connected secrets vault           |
4. Set the permission to **RW** or **RO**.
5. Save the variable.

{% hint style="warning" %}
Store every credential, API key, and token as a **Password** or **Vault** type so it does not appear in the UI, logs, or exported data.
{% endhint %}

#### Databases

The **Data base configurations** sub-tab connects SQL databases to the environment. You can attach multiple databases and use them alongside variables — there is no forced choice between the two.

To add a connection:

1. Click **Add DB config**.
2. Enter a **Connection name**.
3. Select the **Driver** (for example, MySQL).
4. Enter the **Host** and **Port**.
5. Save the configuration.

Database connections defined here are available to [Database Steps](/web-testing/database-steps.md) running in this environment.

#### Profiles

The **Linked test data profiles** sub-tab lists the profiles visible to test cases running in this environment. Only linked profiles appear in the step picker for this environment.

* Click **New profile** to create a profile and link it to this environment in one step.
* Click **Link profile** to attach an existing profile.

When you link an existing profile, the **Link profile** dialog lets you search profiles, select one or more, and choose a source environment under **Copy from which environment**. The selected source's row values become the starting point for this environment and can be edited afterward. A profile with no existing data is linked with no rows.

***

## Test data profiles

The **Test Data Profiles** tab manages data-driven test tables. A profile defines a set of named columns once; each linked environment then stores its own independent set of row values. The column structure is shared across environments, but the values are independent — so the same test logic can run against staging data and production data without duplicating the profile.

### Browsing profiles

* Use the **Search profiles…** field to filter by name.
* Use the environment filter to show only profiles linked to a specific environment.
* Use the permission filter to show only read-only or read-write profiles.

### Creating a test data profile

1. On the **Test Data Profiles** tab, click **New test data profile**.
2. Enter the profile **Name** and optional **Description**.
3. Save the profile.

You can also create a profile directly from an environment's **Data profiles** sub-tab using **New profile**, which links the new profile to that environment automatically.

### Editing profile data

Open a profile to view its detail page. The detail page shows one sub-tab per linked environment, each with that environment's row values.

* The banner reads **"Structure is shared across environments, values are independent"** when you view an environment tab.
* Click an environment sub-tab to edit that environment's rows.
* Click **Assign to more environments** (the **+** tab) to link the profile to additional environments.
* Click **Manage columns** to add, rename, or remove columns. Column changes apply across all environments because the structure is shared.
* Click **Add row** to append a row to the active environment's data.

{% hint style="info" %}
Profiles created before per-environment data may show a **master data (deprecated)** tab. These legacy rows are read-only. Assign the profile to an environment to start editing per-environment data.
{% endhint %}

### Profile detail actions

The profile detail header provides:

* A **permission toggle** to set the profile read-only or read-write.
* **Clone to environments** — copies the profile's data into other environments.
* **Edit** — changes the profile name and description.
* **Delete** — removes the profile. If the profile is linked to test cases or environments, the confirmation dialog lists them first.

***

## Global data

The **Global Data** tab manages workspace-wide variables. These variables are environment-agnostic: they are accessible from every test case regardless of which environment is selected, and their names must be unique across the entire workspace.

### Creating a global variable

1. On the **Global Data** tab, click **New global variable**.
2. Enter the variable **Name** and **Value**.
3. Select the **Type** — **String**, **Number**, **Boolean**, or **Password**.
4. Optionally add **tags** to group related variables.
5. Save the variable.

### Filtering and exporting

* Use the **Search global variables…** field to filter by name.
* Use the tag chip bar to filter by one or more tags.
* Click **Export JSON** to download the current global variables as a JSON file.

### Global variable vs environment variable

| Use a...                 | When the value...                                                                              |
| ------------------------ | ---------------------------------------------------------------------------------------------- |
| **Global variable**      | Is the same across every environment (a standard test product name, a default search term).    |
| **Environment variable** | Differs by environment (the base URL, credentials, or API keys for staging versus production). |

***

## Tips and best practices

* **Set a default environment early.** The default environment is used whenever no other environment is selected, so configure it before your first run.
* **Use Password-type variables for all secrets.** Store credentials, API keys, and tokens as Password-type environment variables or global variables so they are encrypted and masked rather than stored as plain text.
* **Keep profile structure stable, vary the values.** Because a profile's columns are shared across environments, design the column set once and let each environment supply its own rows. Avoid one-off columns that only apply to a single environment.
* **Link only the profiles a test needs.** Only profiles linked to an environment appear in that environment's step picker, so linking selectively keeps the picker focused.
* **Tag global variables.** As the global variable list grows, tags make it fast to find related variables with the tag filter.

## Troubleshooting

**A test data profile doesn't appear in the step picker** The profile must be linked to the environment the test case runs against. Open the environment's **Data profiles** sub-tab and link the profile, or open the profile and assign it to the environment.

**A profile shows a "master data (deprecated)" tab with read-only rows** These are legacy rows from before per-environment data. Assign the profile to an environment to create editable, per-environment rows.

**Can't delete an environment** You can't delete the default environment. Promote another environment to default first, then delete the original.

**A global variable can't be saved because the name already exists** Global variable names must be unique across the entire workspace. Choose a different name, or check whether the value belongs in an environment variable instead.

## Related pages

* [Test Data Management](/web-testing/test-data-management.md) — variable reference syntax and data-driven testing patterns
* [Configuring Environments](/execution/environments.md)
* [Database Steps](/web-testing/database-steps.md)
* [Tutorial: Data-Driven Testing](/web-testing/data-driven-testing-tutorial.md)
* [Running Tests](/execution/running-tests.md)

{% hint style="info" %}
**70% less manual test maintenance with AI self-healing.** [**Book a Demo →**](https://contextqa.com/book-a-demo/) — See ContextQA create and maintain tests for your web application.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/web-testing/environment-data-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.