Genesys Cloud - Main

Hi, everyone!

Is it possible to integrate two or more Genesys Cloud orgs? 

We're asking because our company may need to subscribe to two orgs. We're concerned about things like traceability, among other features we might lose.

Tky

Hello, @Bruno Mascitti

It will depend on how you want to integrate the orgs.

If the goal is to share resources, there may be some limitations. However, for management purposes, you can pair orgs to help administer the environment.

For example, your IT team can access and manage another org without needing to consume licenses or resources in the second org.

Could you share more details about what kind of resources you are planning to share?

Hi Arthur,

Due to different licensing requirements and costs, management may decide to implement a second organization.

I’m concerned about traceability and the possibility of duplicated work when managing the solutions internally.

------------------------------
Bruno Mascitti
Telecom Engineer
------------------------------

Hello, @Bruno Mascitti

You may have duplicated work, as objects and flow will belong to only one organization. They could have the same name, but the object ID is unique.

You can automate some tasks, like user management, using SCIM, but some objects you may track in an individual way.

And regarding call transfers between trunks (org1 <-> org2), is there a way to trace them as a single interaction? or they will be two interactions anyway?

Hi Bruno,

Yes, it is possible to operate with multiple Genesys Cloud orgs, but there are important architectural and operational considerations depending on what level of "integration" you expect between them.

Genesys Cloud orgs are logically isolated tenants, so there is no native "multi-org unified platform" behavior where everything automatically shares routing, reporting, users, conversations, or analytics transparently.

What customers usually implement is a combination of:

• API-based integrations

• external identity federation (SSO/IdP)

• centralized data lake/reporting

• event-driven synchronization

• CX-as-Code / Terraform-style governance

• external orchestration layers

The biggest impact areas normally are:

conversation traceability
reporting centralization
routing continuity
user/agent administration
WEM/WFM consistency
cross-org analytics
knowledge synchronization
bot/Architect deployment governance

For example:

• conversations do not natively move across orgs preserving the same interaction lifecycle

• analytics are separated per org

• queues/users/configuration are isolated

• recordings/transcripts remain tenant-specific

• Architect flows are not shared automatically

Because of that, many enterprises create an external operational layer to unify visibility.

A very common production pattern is:

Genesys Org A
Genesys Org B
↓
Event/API integration layer
↓
Central CRM / Data Lake / Observability Platform

Using:

• Notifications API

• Event Bridge

• Data Actions

• Webhooks

• AWS/Azure middleware

• Salesforce/ServiceNow

• Kafka/SQS/Event Bus

This usually becomes the "source of operational truth" across orgs.

Regarding CX-as-Code/Terraform:
yes, this becomes extremely valuable in multi-org environments.

Using CX-as-Code or Terraform providers helps maintain:

• configuration parity

• controlled deployments

• reusable Architect patterns

• version governance

• rollback capability

• environment consistency

especially when managing:

dev / staging / prod orgs
regional orgs
business-unit isolation
M&A scenarios
regulated environments

One important consideration:
multi-org setups solve organizational and isolation requirements well, but they increase operational complexity significantly.

In practice, the biggest challenge is usually not the telephony itself - it is maintaining:

consistent customer context
cross-org reporting
shared AI/knowledge behavior
omnichannel continuity
governance and auditing

So before moving to multiple orgs, I would strongly validate whether the requirement is truly:

multi-org necessity

or instead:

business separation that could still live inside a single org using divisions, roles, queues, permissions, and business-unit governance.

Because once multiple orgs are introduced, many "native unified CX behaviors" become integration problems to solve externally.

For enterprise-scale environments, the most scalable approach we have seen is:

multi-org + event-driven integration + centralized observability/governance layer.