Sharing a Data Pool

A Data Pool starts out usable only in the project that owns it. Sharing lets other projects consume the same pool, so a set of test data you have already built and maintained can back Scenarios across several projects without being copied into each one. Because everyone reads from the same pool, there is one source of truth and no drift between copies to reconcile later.

Sharing is live and read-only. A project you share with consumes the pool as it stands at run time; it does not take a snapshot and it cannot edit the data. You keep full ownership and control, and consuming projects get current values every time they run. This article covers the sharing options, how to choose among them, and the rules that govern who keeps access as you change sharing.

How consumption works

When a pool is shared, Scenarios in the consuming project can map their parameters to its Columns exactly as if the pool were their own, except that they cannot change anything in it. They read values at run time from your live pool. Nothing is duplicated, so an update you make to the pool is seen by every project that consumes it on their next run.

Users in a consuming project can also change a record’s status, for example to allocate it for manual testing. The records’ data and the pool’s settings stay with the owning project.

A consuming project's dependency on the pool is real: its Scenarios will not run correctly if the pool stops being shared with them. For that reason a consuming project is the only one that can end its own consumption, by changing the Scenarios in that project to stop mapping to the pool. You cannot detach another project's Scenarios from your side, and ACCELQ will not let you remove access out from under a project that is actively consuming. See Change Impact in Data Pools for what happens when you try to narrow sharing in a way that would cut off a consumer.

The sharing options

Open the pool actions menu and choose Sharing... to set who can consume the pool. There are three options, and the right one depends on which projects need the data.

This project keeps the pool private. No other project can consume it. Use this for test data that is specific to one project and has no reason to be reused elsewhere. Note that a private pool does not necessarily stay private if its project is cloned or branched; see Cloning or branching a project.

Specific projects shares the pool with a set of projects you name. The owning project always keeps access, and you add the others. Use this when a known group of projects needs the same data, for example a core set of account records that several related suites all exercise.

All projects shares the pool with every project in the tenant, including projects created later, which gain access automatically. Use this for tenant-wide reference data that any project might need, where you want new projects to inherit access without being added one at a time.

Which one, when

Who always keeps access

Within Specific projects, two kinds of project appear as fixed entries that you cannot remove, and the reason differs.

The owning project is always listed, because a pool is always usable in the project that owns it. It is shown with an owner marker and is never editable as a sharing choice.

Any project whose Scenarios already consume the pool is also kept, because removing it would break those Scenarios. These appear alongside the owner as projects that keep access. Everything else in the list is yours to add or remove freely. For how to see which projects and Scenarios consume the pool, use Show References in the pool actions menu.

Changing sharing

You can move between the three options at any time, and broadening access has no impact. Sharing a private pool, or adding projects to a specific set, carries no consequence for anyone.

Narrowing access is restricted. You cannot drop a project that is consuming the pool, and you cannot switch to This project while any project consumes it, because either change would break Scenarios in projects you do not control. A pool shared with All projects likewise cannot be made private or narrowed in a way that excludes a consumer. When a change you attempt would cut off a consuming project, ACCELQ blocks it and points you at the condition that clears the block. For the full account of these rules, see Change Impact in Data Pools.

If you no longer want a specific project to consume the pool, the project itself has to stop consuming first, by updating its Scenarios to no longer map to the pool. Once it does, you can remove it from sharing.

Cloning or branching a project

When you clone or branch a project, the new project starts with copies of the original's Scenarios, and those Scenarios map to the original's Data Pools. To keep those mappings working, ACCELQ automatically gives the new project access to every pool the original owns.

The original’s Scenarios may also map to pools that were shared with it by other projects, not only pools it owns. Those mappings must keep working too, so the new project is also added as a consumer to every pool the original consumed, regardless of how that pool was shared. A pool shared with the original through Specific projects auto-extends to include the new project, so a clone or branch can quietly widen another project’s sharing. The owning project of each such pool keeps full control; the new project simply joins as a consumer that is kept while its Scenarios map to the pool and removable once they stop.

What this does to each pool depends on how it was shared. A pool that was already shared simply gains the new project in its list. A pool that was set to This project switches to Specific projects with the new project added, because private sharing cannot express "this project and its clone." This means a pool you had kept private becomes shared as a result of the clone or branch.

Access flows one way and is fixed at the moment of the clone or branch. The new project receives access to the pools the original owns or consumes at that time. The original project gains nothing in return, and pools the new project creates afterward are its own. From that point on the cloned project is an ordinary project in the sharing list, kept while its Scenarios consume the pool and removable once they stop.

Moving ownership

Ownership of a pool can be transferred to another project through Move Ownership in the pool actions menu.  When it moves, the project that owned it keeps read-only access, so its Scenarios continue to consume the pool, and every other project the pool was shared with is unchanged. The destination project becomes the owner and the only project that can edit the pool, and it is taken off the shared list because it now owns the pool outright. In effect, sharing is rewritten around the new owner without interrupting anyone's consumption. See Change Impact in Data Pools for the full account of what a move changes.

A typical session

You have built a pool of account records in your project and a related project needs the same accounts for its own Scenarios. You open Sharing..., choose Specific projects, and add the related project. It can now map its Scenarios to your pool and will read live values on every run.

Later a third project is spun up and also needs the accounts. You open Sharing... again, and because the data is now clearly reusable across the tenant, you switch to All projects so this and any future project gets access without further setup. The projects already consuming the pool continue unaffected.

If you try to change back to Specific projects or This project while those projects are consuming, ACCELQ will not let you until they have stopped, which protects their Scenarios from breaking.

Troubleshooting