Where records live

One store per environment, one across an application's environments, or one the whole workspace shares — what each costs you, and how to change it.

Every application keeps its records to itself, and inside it every environment keeps its own again. Nothing you do on Test can reach what the live application is running on, because the two are not connected.

That is the default and it is usually right. This page is about the two times it is not.

One store across an application's environments#

Somebody wants the test copy working on the real records rather than on invented ones — to reproduce a customer's problem, or to check a change against something true.

Settings › Data, on the application, and choose One store for every environment.

The Data tab says so afterwards — every environment carries a marker — and the tool for copying records between environments is switched off, because there is nothing to copy between.

A portal and a back office over the same customers are two applications and one set of records. Copying between them would be a synchronisation problem nobody wants to own.

So a store can be a thing in the workspace with a name — Customer data — that applications attach to.

If you already know the second application is coming, the store can be made as you create the first: A new shared store on the Should it share its information? question. That saves creating the application on its own store, moving it afterwards, and leaving behind whatever it wrote in between. An owner's choice, there as everywhere else.

Otherwise:

Data in the main navigation, then New store.
Name it after what is in it — Customer data, not Portal. It will outlive whichever application uses it first.
Choose whether it keeps a store per environment, or one for all of them. The warning above applies to the second just the same.
On each application, Settings › Data, and pick the store.

An application being created is asked the same thing, once a store exists to choose — which saves creating it, letting it write somewhere, and moving it afterwards.

A new store is a name and nothing else. It holds nothing until the first application is pointed at it, and from then on it is offered to the applications that can share it.

Both applications then read and write the same tables. A customer added in one is there in the other, with nothing to synchronise and nothing to go stale.

The store outlives the applications on it. Deleting the portal leaves the customers exactly where they were, and the back office carries on. That is the whole reason a store is its own thing rather than a setting on an application.

What changing it does, and does not#

Nothing is moved. The records an application had are still in the store it had them in. The store you point it at has whatever is already in it — which is usually why you are pointing it there. Use the Data tab to copy anything across.

The preview moves at once. Test and Live move the next time you deploy to them, because a deployment is a frozen thing and that is when it changes.

Nothing is deleted either. The records the application had are still in the store it left, untouched — change the setting back and they are there again. They are simply not what the application is working on in the meantime.

What you will be stopped from doing#

Deleting a store something still uses. The refusal names the applications, because moving them is the next thing to do.
Pointing an application at a store it could not read. Only applications built the same way can share one. You are never asked how yours was built: a new store fits anything, takes its shape from the first application on it, and afterwards only appears on the applications that can share it.

If you are not sure#