Hi Marciel,
In my experience, if DEV, UAT, and Production must coexist within the same Genesys Cloud organization, Divisions and Roles are necessary, but they're not sufficient on their own. The most successful environments I've worked with use a combination of technical separation, governance, and deployment controls.
My typical approach includes:
1. Use Divisions as the First Layer of Isolation
Create dedicated divisions for:
- Development
- UAT/Test
- Production
Then ensure queues, Architect flows, prompts, integrations, scripts, and other resources are assigned appropriately. Combined with role-based permissions, this greatly reduces the chance of accidental modifications.
2. Adopt a Naming Standard
Consistent naming helps prevent configuration mistakes.
Examples:
-
DEV_Sales_IVR
-
UAT_Sales_IVR
-
PROD_Sales_IVR
-
DEV_CRM_DataAction
-
PROD_CRM_DataAction
When administrators manage hundreds of objects, naming standards become just as important as permissions.
3. Separate Integrations and Data Actions
One of the biggest risks is accidentally pointing a test flow to a production system.
I recommend maintaining:
- Separate credentials
- Separate OAuth clients
- Separate API endpoints
- Separate Data Actions
for each environment whenever possible.
This reduces the risk of test traffic affecting production data.
4. Control Architect Deployment Carefully
A governance process is critical.
I typically recommend:
- Development → UAT validation
- Peer review
- Change approval
- Production deployment
Even a simple checklist can prevent many production incidents.
5. Restrict Production Modification Rights
Not every Architect developer needs production editing permissions.
In larger environments, I prefer:
- Developers build in DEV
- Limited deployment team manages PROD
- Production changes are logged and reviewed
This provides an additional safeguard against accidental changes.
6. Document Flow Dependencies
Many issues occur because a flow depends on:
- Data Actions
- Prompts
- Queues
- User groups
- External systems
Before promoting a solution, verify that all dependency objects exist and are correctly configured in the target environment.
7. Plan for Rollback
Every deployment should include a rollback strategy.
Whether that's using published Architect versions, exported configuration documentation, or a formal change management process, having a recovery plan is essential.
My General Rule
If an organization is large enough to have dedicated DEV and UAT resources, then governance becomes just as important as the technical configuration.
I usually think of it as:
Divisions + Roles + Naming Standards + Environment-Specific Integrations + Controlled Deployment Process = Reliable Environment Separation
While a completely separate Genesys Cloud organization for each environment is often the cleanest approach, that's not always feasible. When multiple environments must coexist in a single org, strong governance and operational discipline become the key factors in preventing development activities from impacting production.
I'd be interested to hear how others handle Architect promotion and Data Action version control in shared environments, as that's often where the biggest challenges arise.
Thanks,