I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss! 

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

I'm interested in the community's views on this as well.

One thing that can be a particular challenge is evaluation the impact of global settings, which is impossible to do with zero production impact risk without multiple ORGs!

I feel that both options are equally problematic. The Division approach seems to be the most cost effective, but I see a lot of cases where Production / Development components "bleed" into each other, thus risking Production whilst development is in progress. (I most often see Development entities, such as Tables or Scripts, referenced from Production Flows and Queues. I also have seen some horrific scenarios where multiple flows interact (Common Modules, In-Queue Flows, Flow transfers etc.) where the amount of editing post-development (and testing!) to align almost invalidates UAT!

And let's not even start on development for / with the API!

I feel that Genesys needs to address this issue. We need access to low-cost "development" ORGs. and the ability to do a complete "lift and shift" between ORGs. (I appreciate the former would incur some AWS cost and the latter is complicated by GUIDs and so on) but as customers become more reliant on Genesys Cloud "just working", it's going to become lass and less acceptable to risk outages whilst performing enhancements.

This is one area in which PureConnect definitely has the advantage! Being Premised-based obviously helps, but....

Just my 10 cents.

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

From my 6 years as a partner and now my time here at Zillow, I've found that there is not a single direction to go on this one -- even between teams/LOB within one org. I do my best to use a separate division, throwaway phone number etc to handle UAT within our primary org because I hate org-hopping from prod to dev to make little tweaks to a test flow for a team BUT then on the other side we have one LOB who does a lot via the API and with global settings that drives us to also have a 2nd org just for this LOB to do Dev/UAT work in and on the backend I eat it by having to export/import flows and tables across orgs and update all the broken references to queues and skills. I have been trying to use the 'Find X' functions in Architect as much as possible so that I can avoid hard-references to items in my flows, making it easier to import across orgs as long as my base objects are named the same.

------------------------------
Brad Murlin
Zillow, Inc.
------------------------------

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Brad,

I feel your pain.

Not only is this annoying and time-consuming, but also opens you up to the possibility of introducing bugs post-testing. I know this is caused by everything being referenced by GUID "behind the scenes", but if Genesys could at least provide an option during import to either auto-resolve based on name, or display all the discrepancies (and offer a suggested auto-resolution based on name) I think we could avoid potentially disastrous outcomes! 

Maybe I need to submit an idea....

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------

Original Message:
Sent: 11-11-2022 17:12
From: Brad Murlin
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

From my 6 years as a partner and now my time here at Zillow, I've found that there is not a single direction to go on this one -- even between teams/LOB within one org. I do my best to use a separate division, throwaway phone number etc to handle UAT within our primary org because I hate org-hopping from prod to dev to make little tweaks to a test flow for a team BUT then on the other side we have one LOB who does a lot via the API and with global settings that drives us to also have a 2nd org just for this LOB to do Dev/UAT work in and on the backend I eat it by having to export/import flows and tables across orgs and update all the broken references to queues and skills. I have been trying to use the 'Find X' functions in Architect as much as possible so that I can avoid hard-references to items in my flows, making it easier to import across orgs as long as my base objects are named the same.

------------------------------
Brad Murlin
Zillow, Inc.

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

For the flow import/export, use Archy.  When creating/updating the flow it resolves all the references by name not ID so it's great for moving between a testing & real org.


https://developer.genesys.cloud/devapps/archy/

The UI can export the flow as yaml, but you need to use archy for the import.

https://help.mypurecloud.com/articles/define-architect-flows-using-yaml/

------------------------------
Melissa Bailey
Genesys - Employees
------------------------------

Original Message:
Sent: 11-14-2022 07:46
From: Paul Simpson
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Brad,

I feel your pain.

Not only is this annoying and time-consuming, but also opens you up to the possibility of introducing bugs post-testing. I know this is caused by everything being referenced by GUID "behind the scenes", but if Genesys could at least provide an option during import to either auto-resolve based on name, or display all the discrepancies (and offer a suggested auto-resolution based on name) I think we could avoid potentially disastrous outcomes!

Maybe I need to submit an idea....

------------------------------
Paul Simpson
Eventus Solutions Group

Original Message:
Sent: 11-11-2022 17:12
From: Brad Murlin
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

From my 6 years as a partner and now my time here at Zillow, I've found that there is not a single direction to go on this one -- even between teams/LOB within one org. I do my best to use a separate division, throwaway phone number etc to handle UAT within our primary org because I hate org-hopping from prod to dev to make little tweaks to a test flow for a team BUT then on the other side we have one LOB who does a lot via the API and with global settings that drives us to also have a 2nd org just for this LOB to do Dev/UAT work in and on the backend I eat it by having to export/import flows and tables across orgs and update all the broken references to queues and skills. I have been trying to use the 'Find X' functions in Architect as much as possible so that I can avoid hard-references to items in my flows, making it easier to import across orgs as long as my base objects are named the same.

------------------------------
Brad Murlin
Zillow, Inc.

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Archy helps for flows with queue and user transfers, but what about common modules, data actions, bots and the like?

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Original Message:
Sent: 11-14-2022 11:23
From: Melissa Bailey
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

For the flow import/export, use Archy.  When creating/updating the flow it resolves all the references by name not ID so it's great for moving between a testing & real org.


https://developer.genesys.cloud/devapps/archy/

The UI can export the flow as yaml, but you need to use archy for the import.

https://help.mypurecloud.com/articles/define-architect-flows-using-yaml/

------------------------------
Melissa Bailey
Genesys - Employees

Original Message:
Sent: 11-14-2022 07:46
From: Paul Simpson
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Brad,

I feel your pain.

Not only is this annoying and time-consuming, but also opens you up to the possibility of introducing bugs post-testing. I know this is caused by everything being referenced by GUID "behind the scenes", but if Genesys could at least provide an option during import to either auto-resolve based on name, or display all the discrepancies (and offer a suggested auto-resolution based on name) I think we could avoid potentially disastrous outcomes!

Maybe I need to submit an idea....

------------------------------
Paul Simpson
Eventus Solutions Group

Original Message:
Sent: 11-11-2022 17:12
From: Brad Murlin
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

From my 6 years as a partner and now my time here at Zillow, I've found that there is not a single direction to go on this one -- even between teams/LOB within one org. I do my best to use a separate division, throwaway phone number etc to handle UAT within our primary org because I hate org-hopping from prod to dev to make little tweaks to a test flow for a team BUT then on the other side we have one LOB who does a lot via the API and with global settings that drives us to also have a 2nd org just for this LOB to do Dev/UAT work in and on the backend I eat it by having to export/import flows and tables across orgs and update all the broken references to queues and skills. I have been trying to use the 'Find X' functions in Architect as much as possible so that I can avoid hard-references to items in my flows, making it easier to import across orgs as long as my base objects are named the same.

------------------------------
Brad Murlin
Zillow, Inc.

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Archy will also be able to work for Common Modules to import it on to GC, bots i'm not sure, have not tested it.

------------------------------
Ramu P
Global Technology Solutions, LLC
------------------------------

Original Message:
Sent: 11-14-2022 17:51
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Archy helps for flows with queue and user transfers, but what about common modules, data actions, bots and the like?

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 11-14-2022 11:23
From: Melissa Bailey
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

For the flow import/export, use Archy.  When creating/updating the flow it resolves all the references by name not ID so it's great for moving between a testing & real org.


https://developer.genesys.cloud/devapps/archy/

The UI can export the flow as yaml, but you need to use archy for the import.

https://help.mypurecloud.com/articles/define-architect-flows-using-yaml/

------------------------------
Melissa Bailey
Genesys - Employees

Original Message:
Sent: 11-14-2022 07:46
From: Paul Simpson
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Brad,

I feel your pain.

Not only is this annoying and time-consuming, but also opens you up to the possibility of introducing bugs post-testing. I know this is caused by everything being referenced by GUID "behind the scenes", but if Genesys could at least provide an option during import to either auto-resolve based on name, or display all the discrepancies (and offer a suggested auto-resolution based on name) I think we could avoid potentially disastrous outcomes!

Maybe I need to submit an idea....

------------------------------
Paul Simpson
Eventus Solutions Group

Original Message:
Sent: 11-11-2022 17:12
From: Brad Murlin
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

From my 6 years as a partner and now my time here at Zillow, I've found that there is not a single direction to go on this one -- even between teams/LOB within one org. I do my best to use a separate division, throwaway phone number etc to handle UAT within our primary org because I hate org-hopping from prod to dev to make little tweaks to a test flow for a team BUT then on the other side we have one LOB who does a lot via the API and with global settings that drives us to also have a 2nd org just for this LOB to do Dev/UAT work in and on the backend I eat it by having to export/import flows and tables across orgs and update all the broken references to queues and skills. I have been trying to use the 'Find X' functions in Architect as much as possible so that I can avoid hard-references to items in my flows, making it easier to import across orgs as long as my base objects are named the same.

------------------------------
Brad Murlin
Zillow, Inc.

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

I think the concern here is not the ability to export / import these, but whether the references from other flows are properly resolved.

Also, whilst it's great to have a tool, I believe it would be much better if this functionality were incorporated into the standard import.

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------

Original Message:
Sent: 11-15-2022 08:02
From: Ramu P
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Archy will also be able to work for Common Modules to import it on to GC, bots i'm not sure, have not tested it.

------------------------------
Ramu P
Global Technology Solutions, LLC

Original Message:
Sent: 11-14-2022 17:51
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Archy helps for flows with queue and user transfers, but what about common modules, data actions, bots and the like?

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 11-14-2022 11:23
From: Melissa Bailey
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

For the flow import/export, use Archy.  When creating/updating the flow it resolves all the references by name not ID so it's great for moving between a testing & real org.


https://developer.genesys.cloud/devapps/archy/

The UI can export the flow as yaml, but you need to use archy for the import.

https://help.mypurecloud.com/articles/define-architect-flows-using-yaml/

------------------------------
Melissa Bailey
Genesys - Employees

Original Message:
Sent: 11-14-2022 07:46
From: Paul Simpson
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Brad,

I feel your pain.

Not only is this annoying and time-consuming, but also opens you up to the possibility of introducing bugs post-testing. I know this is caused by everything being referenced by GUID "behind the scenes", but if Genesys could at least provide an option during import to either auto-resolve based on name, or display all the discrepancies (and offer a suggested auto-resolution based on name) I think we could avoid potentially disastrous outcomes!

Maybe I need to submit an idea....

------------------------------
Paul Simpson
Eventus Solutions Group

Original Message:
Sent: 11-11-2022 17:12
From: Brad Murlin
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

From my 6 years as a partner and now my time here at Zillow, I've found that there is not a single direction to go on this one -- even between teams/LOB within one org. I do my best to use a separate division, throwaway phone number etc to handle UAT within our primary org because I hate org-hopping from prod to dev to make little tweaks to a test flow for a team BUT then on the other side we have one LOB who does a lot via the API and with global settings that drives us to also have a 2nd org just for this LOB to do Dev/UAT work in and on the backend I eat it by having to export/import flows and tables across orgs and update all the broken references to queues and skills. I have been trying to use the 'Find X' functions in Architect as much as possible so that I can avoid hard-references to items in my flows, making it easier to import across orgs as long as my base objects are named the same.

------------------------------
Brad Murlin
Zillow, Inc.

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Another question related to this.  How far has CX as Code come and how far is it from being the tool we need for synching or escalating between ORGs?  I know last I looked, it would only handle about 60% of the sync and was lacking in escalation between Dev and UAT/Production.   Who has experience with that and how it compares with the Division approach?

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Robert, 

With the developments Genesys has made in the last year since you sparked this conversation, I'm interested to know -- how have your views/experiences changed on this topic in the last year?

------------------------------
Zach Dudek
Genesys
------------------------------

Original Message:
Sent: 11-16-2022 22:23
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

Another question related to this.  How far has CX as Code come and how far is it from being the tool we need for synching or escalating between ORGs?  I know last I looked, it would only handle about 60% of the sync and was lacking in escalation between Dev and UAT/Production.   Who has experience with that and how it compares with the Division approach?

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 11-11-2022 10:04
From: Robert Wakefield-Carl
Subject: To Division or not to Division - what is the correct way to handle Dev/UAT/Prod

I have been pondering this for many moons and would like to elicit input from the community to try and discover a common consensus on when to use separate ORGs and when to use Divisions when a customer needs to have a development system.  The usual case is they want a sandbox for development, a place to test UAT, and limited access to production.  Of course, we all know the hassles of different ORGs (and costs) and CX as Code is just not quite there, especially if you don't have a team that manages your Terraform.  We usually suggest Divisions for this unless they want to test beta code outside of production.  So, let's discuss!

What do you recommend from your experience of how to deal with the need for DEV, UAT, and PROD environments in Genesys Cloud CX?
#Implementation
#PlatformAdministration
#SystemAdministration

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------