Skip to content
  • There are no suggestions because the search field is empty.

Understanding Staging vs Production

Enhanced Admin Capabilities allow administrators to make changes to their forms and review criteria without requiring assistance from the RQ team. To support safe testing and deployment, changes are made in a Staging environment before being published to the Live environment.

What is the Staging Environment?

The Staging environment is a testing environment where administrators can:

  • Edit submission forms
  • Edit review forms
  • Add, edit, reorder, and remove questions
  • Add, edit, reorder, and remove review criteria
  • Test submitter and reviewer experiences
  • Verify updates before publishing

Changes made in Staging are not visible to submitters, reviewers, or other users in the Live environment.

What is the Live Environment?

The Live environment is the production environment where submitters, reviewers, and administrators interact with your active program.

Changes made in Staging will not appear in Live until they have been published.

Why Use Staging?

Making changes in Staging helps:

  • Prevent accidental changes to active programs
  • Allow testing before release
  • Reduce submitter and reviewer confusion
  • Ensure forms function as expected
  • Identify issues before publishing

Recommended Workflow

  1. Make changes in Staging.
  2. Test the changes thoroughly.
  3. Verify the submitter experience.
  4. Verify the reviewer experience.
  5. Publish changes to Live.
  6. Confirm the updates appear correctly in Live.

Common Questions

Why can't submitters see my changes? -> Changes made in Staging are only visible in the Staging environment until they are published to Live.

Can I test my changes before publishing? -> Yes. Staging is designed specifically for testing and validation before changes are released.

Should I make changes directly in Live? -> No. All changes should be made and tested in Staging before being published to Live.

Best Practices

  • Always test before publishing.
  • Review both submitter and reviewer experiences.
  • Avoid publishing large changes without testing.
  • Keep a record of major updates.
  • Publish changes during periods of low activity whenever possible.