Change Impact in Data Pools

When you rename, restructure, share, move, or delete a Data Pool, other parts of your project may already depend on it. A Scenario maps one of its parameters to a Column. Another project consumes it live. A replenishment Job keeps it filled. ACCELQ checks these dependencies the moment you start a change and tells you what will happen before you commit, so you are never guessing whether a delete is safe or who loses access when you narrow sharing.

This article explains what ACCELQ looks for, the two ways it responds, and exactly what each operation does to your dependencies. It assumes you already know how Data Pools, sharing, and Record Scope & Variability work; for those, see Data Pools: overview and concepts, Sharing a Data Pool, and Record Scope & Variability. Here we cover only one thing: what happens to everything connected to a pool when you change it.

What ACCELQ checks

Every pool operation that could break something consults the same three kinds of dependency.

The first is internal mapping. Parameters in Scenarios of your own project can map to a Column of the pool, drawing their values from it at run time. When the Column or the whole pool goes away, those parameters have nothing to read from.

The second is external consumption. When a pool is shared, Scenarios in other projects can consume it. Those projects depend on the pool continuing to exist and continuing to be shared with them. You cannot see or edit their Scenarios, so ACCELQ treats their dependency as something only they can release.

The third is replenishment. A Job may be set up to populate the pool on a schedule. Replenishment logic is never adjusted automatically by any change you make here; see After a change: replenishment for what to review yourself.

The two responses

Once ACCELQ knows what depends on a pool, it responds in one of two ways, and the difference matters because one stops the change and the other asks you to decide.

When a dependency cannot be resolved from your project, the operation is blocked. This happens when Scenarios in other projects consume the pool: you cannot delete the pool, and you cannot narrow its sharing to exclude a consuming project, because doing so would break Scenarios you have no control over. A blocked dialog explains which projects are involved and tells you the condition that clears the block, which is always the same in spirit: the dependency has to be released at its source, in the consuming project, before you can proceed.

When a dependency is yours to resolve, the operation is allowed with a decision. Internal mappings are the usual case. ACCELQ lists the affected Scenarios and asks what their delinked parameters should fall back to, then carries out the change and the delink together in one commit. Nothing is half-applied: either the whole change goes through or none of it does.

A third situation is not really a response at all. When nothing depends on the pool, the operation is clean and proceeds after a plain confirmation.

What "delink" means

Delinking is what happens to an internal parameter when the Column it reads from is removed. The parameter does not disappear. It is switched to a different value source so the Scenario keeps running. You choose that source as part of the operation.

What choices you get depends on the operation, and the difference is deliberate.

Deleting a whole pool can delink many parameters across several Columns at once, so ACCELQ keeps the fallback uniform and switches them all to Test Case values rather than asking you to resolve each Column separately. When you remove a single Column, you are making one focused decision and get the full range of sources. After any delink, the parameters read from their new source immediately; if that source is the Test Case, update the values in the affected Test Cases so your runs use real data.

What each operation does

The following covers every pool operation that carries change impact. Each entry states what blocks it, what it changes about your dependencies, and what survives.

Rename a Data Pool

Renaming has no impact. A pool is identified internally, not by its name, so every mapping and every consuming project keeps working. The new name appears everywhere the pool is referenced.

Edit Columns

Editing Columns covers renaming a Column, reordering Columns, and encrypting a Column, all committed together. Renaming and reordering carry no impact; mappings follow the Column's identity, not its name or position. Encrypting a Column does have impact, described next.

Encryption is one way. When you encrypt a Column, its existing and future values are stored encrypted and shown masked everywhere the pool is viewed. There is no decrypt action. If you later need the Column to hold plain values again, you delete it and create a new one, which means its mappings are lost and must be set up again. Because this cannot be reversed, treat encrypting a Column as a permanent decision.

Encrypting a Column also changes which parameters it can supply. An encrypted Column can feed only parameters marked encrypted, and a plain Column only plain ones, so every parameter mapped to the Column loses its mapping when you encrypt it. If Scenarios in other projects map to the Column, encrypting it is blocked until those projects stop mapping to it. If parameters in your own project map to it, ACCELQ lists the affected Scenarios and offers the delink choice described above. If nothing maps to the Column, it is encrypted after a plain confirmation.

Add a Column

Adding a Column has no impact. The new Column starts empty, and nothing maps to it until you create a mapping, so no Scenario or project is affected.

Delete a Column

Deleting a Column removes its values from every row and cannot be undone.

If Scenarios in other projects map to the Column, the delete is blocked. Those projects must stop mapping to it before you can proceed.

If parameters in your own project map to the Column, ACCELQ lists the affected Scenarios and offers the delink choice described above. Confirm the fallback source and the Column is deleted and the parameters delinked in one step.

If nothing maps to the Column, it is deleted after a plain confirmation.

Delete a Data Pool

Deleting a pool permanently removes it and all of its records.

If Scenarios in shared projects consume the pool, the delete is blocked until those Scenarios stop consuming it.

Otherwise the pool can be deleted. If parameters in your own project are mapped to its Columns, they are delinked to Test Case values as part of the delete. If the pool is shared with projects that have no references to it, those projects lose access when it is gone. Because the data is destroyed and cannot be recovered, you confirm by acknowledging the impact explicitly before the Delete action becomes available.

Deleting the project that owns a pool is governed by the same consumption rule. If you try to delete a project that owns pools consumed by other projects, the deletion is blocked. Change ownership of those pools to another project, using [Move Ownership in the pool actions menu], before deleting the project.

Share a Data Pool

Sharing controls which projects can consume the pool. You can keep it to This project, share it with Specific projects, or share it with All projects, where projects added to the tenant later also gain access.

Narrowing sharing is where impact appears. A project whose Scenarios already consume the pool cannot be dropped from sharing, and you cannot switch to this-project-only while any project consumes it, because either change would break those Scenarios. Consuming projects are shown as fixed entries that keep access; the owning project always keeps access as well. Broadening sharing, or adding projects that do not yet consume the pool, carries no impact.

For how to find which projects and Scenarios consume a pool, use [Show References in the pool actions menu].

Record Scope & Variability

Record Scope & Variability controls whether records in the pool vary by Application Environment and by Application Variant. These dimensions affect only which records ACCELQ selects during provisioning based on where a test runs; nothing outside the pool depends on them, so turning them on or off never blocks and never breaks a mapping.

Turning a dimension on asks what to do with existing records: keep them valid for all values of the dimension, or assign them to one specific value. A record left blank for a dimension applies to every value of that dimension, which is why existing records keep working unchanged when you leave them blank.

Turning a dimension off removes that dimension's values from all records. No records are removed; records that were specific to one Environment or Variant simply become valid for any. If you need to remove records tied to a particular Environment or Variant before turning the dimension off, filter and delete them in the grid first.

One thing to watch: if you kept separate records for the same logical item across Environments or Variants, for example one account record for QA2 and another for UAT, turning the dimension off leaves both as independent records that now apply everywhere. They are not merged, and both become available for any run. Review such records if having both in play would affect how tests pick data.

Move Ownership

Moving transfers ownership of the pool to another project. The destination becomes the only project that can edit the pool. The project you moved it from keeps read-only access, and any other projects it was shared with are unchanged. Parameters in the original project that map to the pool keep working, now consuming it read-only.

A pool can be moved to any project in the tenant.

Remove a Data Pool (consumer side)

When a pool is shared with your project but owned by another, your only structural action is to remove it from your project, which detaches it. Removing it requires the Manage Data Pools permission in your project. The pool itself is untouched; this only affects your project. If parameters in your project map to the pool, removing it offers the delink choice described above. Once removed, you regain access only if the owning project shares the pool with you again.

A pool that is shared with every project in the tenant cannot be removed from a single project, because the owner's sharing setting has no way to carve out an exception. Ask the owning project to switch to specific-project sharing instead.

After a change: replenishment

ACCELQ does not adjust replenishment Jobs when you change a pool. A Job that populated a Column you deleted, or a pool you moved, will not be corrected for you. After deleting Columns, moving a pool, or changing Record Scope & Variability, review any replenishment logic that targets the pool and update it yourself if the change affects what it should write.

Quick reference