Overview
CX Platform gives you two environments to work in — Production (Prod) and Test. They look almost identical, but they play very different roles. Prod is where your real users, real data, and live communications sit. Test is your safe space to try things out, break things, and learn how a setting behaves before it goes anywhere near a real recipient.
Keeping the two separate means you can confidently configure, integrate, and refine your Auth module setup without worrying about disrupting live operations. It's also how you stay on the right side of audit and compliance — Prod stays clean, Test takes the bumps.
This guide walks through the key differences between the two environments and the habits that'll keep your work safe and repeatable.
Quick way to check where you are
Not sure which environment you're in? Take a quick look at the URL — it'll tell you straight away whether you're working in Prod or Test.
Purpose and audience
The two environments exist for very different reasons, and knowing which one you're in shapes how you should approach any change.
Prod is the live environment. It's used by all real users, handles live authentication, and runs your active tenants. Every security, compliance, and audit control is fully enforced here, so any change you make has real consequences for real people.
Test is your development, integration, and UAT space. It's where administrators try out features, work through user management, test authentication behaviours, and rehearse module integration — all without touching live data or live users.
Data and tenants
What lives inside each environment is also very different, and that's by design.
In Prod, you'll only ever find real, authorised tenant data and active modules. Anything you change here updates instantly for end users, so there's no margin for "let me just try this and see".
In Test, you've got room to play. Sample tenants, test users, and simulated modules are all fair game, and none of it touches production. If something gets messy, you can reset or reload the data and start again.
Configuration and integration
The integrations behind each environment point to different places, which is what makes Test genuinely safe to experiment in.
Prod connects to production APIs, identity providers, SMS and email services, and single sign-on (SSO) endpoints. Security tokens, secrets, and admin actions in Prod are treated as final — once you've saved, it's live.
Test points to sandbox or test endpoints instead. You'll use test credentials, keys, and settings to validate login flows, SSO, and federated identity setups before anything gets promoted to Prod.
Side-by-side comparison
If you'd rather see it all in one place, here's the same information laid out as a quick reference.
Best practices
A few simple habits will save you a lot of headaches, especially when you're working on authentication or integration changes.
- Always validate configuration changes in Test before applying them to Prod. If something behaves unexpectedly, you'd rather find out in Test.
- Use unique test users, sample tenants, and dummy data when working in Test — it keeps your testing safe, repeatable, and easy to clean up.
- Check the URL before making any change, so you're certain whether you're in Test or Prod.
A quick word of caution
Changes made in Prod take effect immediately for real users. If you're unsure how a setting will behave, rehearse it in Test first — every time.
What's next
Now that you know how the two environments differ, you're set up to test confidently in one and deploy safely in the other. When you're ready, head into Test to trial your Auth module configuration, then promote it to Prod once you're happy with how it behaves.