Stages
Patient Journey Intelligence separates work into three stages: Demo, Playground, and Production. Each stage is its own operational context, with its own data, jobs, and configuration. Demo is an open sandbox. Playground and Production hold real or near-real clinical data, and a user enters them only after an administrator adds them to the stage.
Who can enter each stage
| Stage | Who can enter | What it holds |
|---|---|---|
| Demo | Any signed-in user | Synthetic data for onboarding and evaluation |
| Playground | Users an administrator has listed on the stage | Real or near-real clinical data used for testing |
| Production | Users an administrator has listed on the stage | Live clinical data and production jobs |
Signing in is not enough to enter Playground or Production. A user without stage membership who tries to switch sees an error telling them to contact an administrator, and they can browse no data and start no jobs on that stage until access is granted.
Demo stays open to every signed-in user. It is where onboarding, feature exploration, and configuration testing belong, because nothing there touches real patient data.
Why membership is explicit
Every signed-in user could previously switch into Production or Playground, which meant a user granted a Demo role could leave Demo and work on real clinical data. Explicit membership closes that gap. The stage boundary now enforces the same access intent as the role assignment, and an access review of Production answers a single question: who is on the membership list.
Managing stage membership
Administrators add and remove users in two places:
From the stage
Navigate to the stage and open its membership list. Add or remove individual users there. This is the path to use when granting access to a group at once, for example adding six abstractors to Production at the start of a registry project.
From the user
When editing a user's profile in User Management, a Stage Access section lists the private stages that user belongs to. Add or remove stages for that user in the same edit form. This is the path to use during onboarding and offboarding, when one person's full access needs to be set or revoked in one place.
Both paths take effect immediately. A user added to Production switches to it on their next page navigation, with no need to sign out and back in. A user removed from a stage loses access the next time the platform checks their permissions, typically on the next page load or API call.
Existing users keep their access
Users who had already worked in Playground or Production before this change keep their access automatically. Existing access is recognized from a saved stage preference for that stage, ownership of jobs or resources on that stage, or recorded activity on that stage after the upgrade. System administrators keep access to every stage regardless of the membership list.
Stage visibility
A user who is not a member of Playground or Production does not see those stages in the stage switcher. Only the stages they can enter appear, so the interface never offers an option that would fail on selection.
Frequently asked questions
They see an error stating that they do not have access to that stage and should contact an administrator. No data is visible and no jobs can be started. In practice the situation is rare, because the stage switcher lists only the stages the user is a member of.
No. Removing stage membership revokes access and leaves the cohorts, jobs, datasets, and other work that user created on the stage untouched. Other users with the appropriate permissions continue to see it.
Yes. System administrators keep access to every stage regardless of the membership list. Explicit membership applies to non-administrator users.
They keep their access automatically. A user with a saved stage preference, ownership of resources, or recorded activity on Production or Playground is treated as an existing member, so no administrator has to re-add them after the upgrade.
Either open the Production stage detail page and add the user to its membership list, or go to User Management, find the user, and edit their Stage Access section. Both paths take effect immediately.
Immediately. An added user reaches the stage on their next page navigation without signing out. A removed user loses access the next time the platform checks permissions, which is typically the next page load or API call.