Move changes between environments

Your organization may have development and test environments as well as production. You build and try out Studio changes, such as forms, workflows, messages and labels, in development or test, and then bring exactly the same changes into production as a package.

You always have one production environment. Enterprise includes one test and one development environment; with other editions, they're add-ons.

Prerequisites#

• The Admin or Designer role.
• The Enterprise edition, or Professional with a development environment. See Plans and features.

Know which environment you're in#

Development and test environments show a coloured band across the top of every page, with the environment's name, for example UAT · Test environment. Production has no band.

Outside production, nobody real is emailed and no real system is called:

• Every email goes to your organization's test address instead. Its subject starts with the environment and whom it was for, for example [uat · for [email protected]].
• Webhooks and workflow calls reach only the test systems your organization agreed with ONEConsult.NET Ltd.

Package your changes#

A package is a release with a name, a description and a version.

1. In the menu, under Extend, select Studio.
2. Under Releases, select New release, enter a Name, such as "Patient intake", and a Description of what it changes and why, and then select Create.
3. Under Add a change, add the changes that belong together, and then select Add.
4. Select Export package. Your browser saves a file named after the package and its version, for example patient-intake-v1.platformone.

The version is a whole number that goes up by itself: each time you export the package with changed content, it gets the next version. Exporting it again without changes keeps its version. The package's page shows Where it has been: each version, the environment and who exported it.

Send a package to another environment#

Packages move in a set order:

If your organization has no test environment, development promotes straight to production.

1. On the package's page, under Other environments, choose where to send it in Send to, for example Promote to uat (test).
2. Select Send. Changed content gets the next version first.

The package arrives in the other environment with its name, version and history, submitted for review. There, open it from Releases and select Approve release to approve all its changes in one decision, and then publish it as usual.

Production takes only what passed test: a test environment can promote a package only after publishing it, and production refuses a version that wasn't published in test.

When the same thing was changed in both places#

If the receiving environment was changed since it last received the package, changes to different things are kept side by side. If both changed the same thing, for example the same word, nothing is received yet. Instead, a list shows each clash: what the setting is, the receiving environment's change, and the package's change. For each one, choose:

• Keep the receiving environment's change, so the setting stays as it is there.
• Use the package's change, so the package replaces it.

You can also select Use the package's change for all or Keep all of the environment's changes. When every clash is decided, select Send with these choices. The package arrives with your choices applied, and its notes list which changes it replaced and which it kept. Select Cancel to send nothing and leave the other environment as it is.

The same choices are offered when you import a package file.

Values that differ in each environment#

A workflow that calls another system, or tells someone, often needs a different address in each environment. Use an environment value, such as {env.crm-address}: a package carries the name, and each environment uses its own value. When a release needs a value the receiving environment doesn't have yet, it waits there as drafts until an administrator sets it. See Set environment values.

Send a package as a file#

You can also select Export package to save the package as a file, for example patient-intake-v1.platformone, and select Import on the Studio page of the other environment. The same order applies. A package is signed when it's exported: if it was changed after that, or comes from another organization's environments, it can't be imported.

Only the environment where a package was created gives it new versions. To change a package you received, put the changes in a package of your own.

Refresh an environment#

To bring a development or test environment up to date with what is live in production or test:

1. In the environment to refresh, under Extend, select Studio.
2. Under Environments, choose the environment in Refresh from, and then select Refresh.
3. Everything live there arrives as a release named, for example, Refresh from prod. Approve and publish it to replace what is live here.

Production is never refreshed from another environment. Finish or discard changes in progress first: a refresh doesn't replace an unfinished draft.

Take changes in production only from test#

An administrator can turn on Take changes only from test under Environments in production's Studio. Then nobody designs in production directly. For an urgent fix, an administrator selects Emergency change on the item; it is reviewed and published as usual, and stays flagged Emergency change so you remember to make it in development too.

See where live changes came from#

On the Studio page, each item shows where its live version came from, for example From Patient intake v4 · uat. If it was changed directly in this environment after that, it shows Changed here since Patient intake v4, so you can bring the change back to development.

Next steps#

• Review and publish changes
• How Studio works