Sandbox to production promote guide

If you're using a Sandbox environment to test care flows & integrations, eventually you'll need to promote them to your Production environment to start enrolling patients in your care flows.

Sandbox vs. production

Our Sandbox & Production environments are completely separate environments. They have their own dedicated user management / authentication provider, data storage, deployments, etc. Additionally, our production environments are available regionally, currently they are available in the EU, UK and US.

The Sandbox environment should only be used for testing & evaluation purposes. No care flows with real patients should be orchestrated on Sandbox environments.

Promotion

Currently you cannot promote care flows from Sandbox to Production yourself. However, the Awell team has internal tooling to easily transfer your flows between environments and we're happy to support you with this. You can request care flow promotion by clicking the button below.

Given that Sandbox and Production are completely separate environments, there is no synchronization between them. If you have promoted a care flow to Production before and have edited that flow in your Sandbox environment, then you'll have to request promotion again.

What will be promoted?

When you request a promotion of your care flow from Sandbox to Production, we'll create a snapshot of the current working version of your flow and move that to your Production tenant as a working version. You'll need to publish your care flow in Production before it is available for patient enrollment.

Please note that your care flow history is not promoted, but only a snapshot of the current state of your flow.

Constants

Constants can be used to save time and safely store data. It are variables with a constant value that are accessible everywhere in your care flow and especially useful for storing API keys, URLs, and anything you find yourself typing multiple times in a care flow.

With the ability to conceal the value of a constant, they are also perfectly suitable for storing sensitive information.

When your care flow gets promoted, constants will be handled as follows:

Promotion should be unidirectional

Promoting care flows should be unidirectional and we advise to only promote from Sandbox to Production. However, we can support you with doing the reverse and transferring a version of your care flow from Production to Sandbox. This should ideally only be done once in this direction, however.

If you are building and validating your care flows in Sandbox, we advise you agree with your team to only make edits to your care flows in the Sandbox environment and to not do any edits to your care flows in Production. When you edit a care flow in Sandbox and promote it to Production, it will overwrite any changes made in Production so these changes will be lost.

Requesting promotion for an already promoted pathway

There are 2 possible scenarios when requesting promotion of a care flow:

1. The care flow doesn't exist yet in the destination environment, i.e. first time promotion
2. The care flow already exists in the destination environment, i.e. the care flow was already promoted before

If the care flow doesn't exist yet in destination environment, it will be created.

If the care flow already exists in the destination environment, we'll just update the working version of the already existing care flow in the destination environment so it represents the working version of the care flow in the source environment.

Identifier systems

Identifier systems are a tenant setting and are not promoted, therefore you must set the systems in all of your environments - make sure name and system are the same. Learn more about identifiers here.

Identifiers

You might have some integrations running on Sandbox that depend on identifiers, eg: pathway definition ids or data point ids. When care flows are promoted to production, these identifiers will remain the same so it doesn't impact any integrations you've already set up.

However, we do recommmend to limit hardcoding identifiers to a minimum. You can find more information on how to do that below.

Pathway definition id

The pathway definition id is a unique identifier for the pathway / care flow you have built in Awell Studio and is primarily used to indicate what care flow you'd like to start for a given patient (see startPathway mutation).

To prevent hardcoding this identifier in your systems, you have the following options:

1. If you're exposing a UI to your users: use the getPublishedPathwayDefinitions query to dynamically load the published pathways in a dropdown (see example story).
2. If you're not exposing a UI to your users: use the getPublishedPathwayDefinitions query and do a search on pathway / care flow name to find the corresponding pathway definition id. This assumes the name of the care flow is identical between environments and does not change. It's probably a good idea to add some logging in case no care flow can be found.

Data point definitions ids

Data points are atomic pieces of data collected in your care flow and every data point has a unique identifier. There are different categories of data points:

1. Baseline data points: data points that are expected when starting the care flow
2. Form data points: data points originating from forms you have created
3. System data points: these are data points that are automatically generated by Awell (eg: activation and completion date of a step)

To prevent hardcoding these identifiers in your systems, you have the following options:

1. Use keys for baseline data points which you can query and find the corresponding id for via the getPublishedPathwayDefinitions query.
2. Configure and use question keys for form data points.