Genesys Cloud - Developer Community!

Hi Piyush,

I reviewed the current CX Cloud Voice documentation together with the Salesforce Voice with Partner Telephony documentation.

The screen pop and Omni-Channel Flow requirements should be treated as two separate capabilities.

For screen pop, what you have implemented is correct. GC_SCREEN_POP is the current CX Cloud attribute used from Architect to open a Salesforce record or page, and SF_URLPop is also supported for migration from the previous Genesys Cloud for Salesforce integration.

For the second requirement, I do not see a documented CX Cloud capability that allows an Architect flow to directly invoke a Salesforce Omni-Channel Flow.

Salesforce does provide an Execute Omni-Channel Flow operation through the Salesforce Voice Telephony Integration API. This is part of the Salesforce Voice with Partner Telephony architecture and requires a Salesforce VoiceCallId or the appropriate telephony-provider call identifier.

The issue is that the current CX Cloud documentation does not document the Salesforce VoiceCallId as an Architect variable or participant attribute returned from Salesforce into the Genesys inbound flow.

The documented synchronization model is primarily in the opposite direction:

Genesys interaction attributes → CX Cloud → Salesforce VoiceCall fields

For example, Genesys supports mapping Conversation.ConversationId, ANI, DNIS, queue information and Participant.{CustomFieldName} values into Salesforce VoiceCall fields.

There is also a useful correlation mechanism on the Salesforce side: the CX Cloud documentation states that VendorCallKey contains the Genesys Cloud ConversationId as its second UUID. This can be useful when Salesforce needs to correlate a VoiceCall record with the original Genesys conversation.

However, I would not use VendorCallKey as a substitute for the call identifier required by the Salesforce Omni-Channel Flow API unless that mapping is explicitly validated for the implementation.

Architect and Genesys ACD remain responsible for the inbound voice routing in the standard CX Cloud Voice architecture. Salesforce Omni-Channel is also used in the CX Cloud agent experience - for example, the agent must be signed into Omni-Channel with a status mapped to Genesys On Queue - but that is different from using a Salesforce Omni-Channel Flow as another routing engine.

So if the requirement is specifically:

Architect → trigger Salesforce Omni-Channel Flow

I would consider that a custom integration requirement rather than an out-of-the-box CX Cloud capability.

Before implementing a custom call from Architect to the Salesforce Telephony Integration API, I would also confirm the intended purpose of the Omni-Channel Flow. If it is being used to make another agent-routing decision after Genesys has already performed Architect/ACD routing, you could effectively introduce two routing engines into the same voice journey.

For the standard CX Cloud Voice design, I would keep routing and orchestration in Genesys Architect/ACD and synchronize the business context required by Salesforce through the supported VoiceCall field mappings.

Hey Gabriel,

Thanks for the detailed explanation!!

To answer your question-

Before implementing a custom call from Architect to the Salesforce Telephony Integration API, I would also confirm the intended purpose of the Omni-Channel Flow. If it is being used to make another agent-routing decision after Genesys has already performed Architect/ACD routing, you could effectively introduce two routing engines into the same voice journey. - per SF team, the omnichannel flow has a lots of capabilities which can enhance the CX, thus they are looking to introduce this and stated this as a requirement.

For the standard CX Cloud Voice design, I would keep routing and orchestration in Genesys Architect/ACD and synchronize the business context required by Salesforce through the supported VoiceCall field mappings. - we also insisted to do this way so that routing and orchestration comes under GC but they are keen to explore the enhanced capabilities offered by omnichannel flow in SF side.

Hi Piyush,

I reviewed the current CX Cloud Voice documentation together with the Salesforce Voice with Partner Telephony documentation.

The screen pop and Omni-Channel Flow requirements should be treated as two separate capabilities.

For screen pop, what you have implemented is correct. GC_SCREEN_POP is the current CX Cloud attribute used from Architect to open a Salesforce record or page, and SF_URLPop is also supported for migration from the previous Genesys Cloud for Salesforce integration.

For the second requirement, I do not see a documented CX Cloud capability that allows an Architect flow to directly invoke a Salesforce Omni-Channel Flow.

Salesforce does provide an Execute Omni-Channel Flow operation through the Salesforce Voice Telephony Integration API. This is part of the Salesforce Voice with Partner Telephony architecture and requires a Salesforce VoiceCallId or the appropriate telephony-provider call identifier.

The issue is that the current CX Cloud documentation does not document the Salesforce VoiceCallId as an Architect variable or participant attribute returned from Salesforce into the Genesys inbound flow.

The documented synchronization model is primarily in the opposite direction:

Genesys interaction attributes → CX Cloud → Salesforce VoiceCall fields

For example, Genesys supports mapping Conversation.ConversationId, ANI, DNIS, queue information and Participant.{CustomFieldName} values into Salesforce VoiceCall fields.

There is also a useful correlation mechanism on the Salesforce side: the CX Cloud documentation states that VendorCallKey contains the Genesys Cloud ConversationId as its second UUID. This can be useful when Salesforce needs to correlate a VoiceCall record with the original Genesys conversation.

However, I would not use VendorCallKey as a substitute for the call identifier required by the Salesforce Omni-Channel Flow API unless that mapping is explicitly validated for the implementation.

Architect and Genesys ACD remain responsible for the inbound voice routing in the standard CX Cloud Voice architecture. Salesforce Omni-Channel is also used in the CX Cloud agent experience - for example, the agent must be signed into Omni-Channel with a status mapped to Genesys On Queue - but that is different from using a Salesforce Omni-Channel Flow as another routing engine.

So if the requirement is specifically:

Architect → trigger Salesforce Omni-Channel Flow

I would consider that a custom integration requirement rather than an out-of-the-box CX Cloud capability.

Before implementing a custom call from Architect to the Salesforce Telephony Integration API, I would also confirm the intended purpose of the Omni-Channel Flow. If it is being used to make another agent-routing decision after Genesys has already performed Architect/ACD routing, you could effectively introduce two routing engines into the same voice journey.

For the standard CX Cloud Voice design, I would keep routing and orchestration in Genesys Architect/ACD and synchronize the business context required by Salesforce through the supported VoiceCall field mappings.

Thanks Piyush, that clarification helps.

In that case, I think the next step is to separate the Salesforce capabilities they want from the actual routing responsibility.

Salesforce Omni-Channel Flow certainly provides useful capabilities around VoiceCall processing, record lookup, screen pops, related records, routing decisions, skills and other Salesforce-side automation.

However, there is an important architectural boundary here.

If Omni-Channel Unified Routing is enabled for voice, Salesforce documents that Omni-Channel becomes the routing engine for those calls. In other words, routing takes place in Salesforce instead of the external telephony/CCaaS platform.

That is fundamentally different from the standard CX Cloud model where Genesys Architect/ACD remains responsible for IVR, queues, skills and agent selection.

So I would break the requirement into two categories.

If the Salesforce team needs capabilities such as:

• Salesforce record lookups

• VoiceCall enrichment

• Case/Contact association

• record updates

• Salesforce automation

• additional business logic

• custom agent experience

then I would keep Genesys as the routing authority and implement those capabilities through Salesforce Flow/Apex/VoiceCall automation rather than introducing a second routing engine.

For example:

Genesys Architect / ACD
→ route the call
→ CX Cloud creates/synchronizes the VoiceCall
→ Salesforce Flow or VoiceCall automation performs the required CRM-side processing

Salesforce supports Flow-based automation around VoiceCall records, so many of the benefits they are looking for may not actually require Omni-Channel Flow to participate in call routing.

On the other hand, if the specific Salesforce capability they require depends on Route Work, Salesforce skills, capacity, direct-to-agent routing, or other Omni-Channel routing functions, then this is no longer just an enhancement to the existing CX Cloud routing model. It becomes an architectural decision about which platform owns routing.

I would avoid designing:

Genesys ACD routing → Salesforce Omni-Channel routing → Agent

because both platforms would be making routing decisions for the same voice interaction.

The cleaner design is to establish one routing authority:

Option 1 - Genesys owns routing

Architect → Genesys ACD → Agent

Salesforce handles CRM automation, VoiceCall processing and agent experience.

Option 2 - Salesforce owns unified routing

Salesforce Omni-Channel Flow → Omni-Channel routing → Agent

with the telephony/CCaaS platform participating according to Salesforce's Partner Telephony/Unified Routing architecture.

For the current CX Cloud implementation, I would stay with Option 1 unless there is a specific Salesforce feature that absolutely requires Omni-Channel Unified Routing.

I would therefore ask the Salesforce team to identify exactly which Omni-Channel Flow capabilities they need. In many cases, those business requirements can be implemented with standard Salesforce Flow and VoiceCall automation while preserving Genesys Architect and ACD as the single routing engine.

That gives you the Salesforce functionality they want without introducing conflicting ownership of routing, agent availability, skills and queue selection.

Hey Gabriel,

Thanks for the detailed explanation!!

To answer your question-

Before implementing a custom call from Architect to the Salesforce Telephony Integration API, I would also confirm the intended purpose of the Omni-Channel Flow. If it is being used to make another agent-routing decision after Genesys has already performed Architect/ACD routing, you could effectively introduce two routing engines into the same voice journey. - per SF team, the omnichannel flow has a lots of capabilities which can enhance the CX, thus they are looking to introduce this and stated this as a requirement.

For the standard CX Cloud Voice design, I would keep routing and orchestration in Genesys Architect/ACD and synchronize the business context required by Salesforce through the supported VoiceCall field mappings. - we also insisted to do this way so that routing and orchestration comes under GC but they are keen to explore the enhanced capabilities offered by omnichannel flow in SF side.

Hi Piyush,

I reviewed the current CX Cloud Voice documentation together with the Salesforce Voice with Partner Telephony documentation.

The screen pop and Omni-Channel Flow requirements should be treated as two separate capabilities.

For screen pop, what you have implemented is correct. GC_SCREEN_POP is the current CX Cloud attribute used from Architect to open a Salesforce record or page, and SF_URLPop is also supported for migration from the previous Genesys Cloud for Salesforce integration.

For the second requirement, I do not see a documented CX Cloud capability that allows an Architect flow to directly invoke a Salesforce Omni-Channel Flow.

Salesforce does provide an Execute Omni-Channel Flow operation through the Salesforce Voice Telephony Integration API. This is part of the Salesforce Voice with Partner Telephony architecture and requires a Salesforce VoiceCallId or the appropriate telephony-provider call identifier.

The issue is that the current CX Cloud documentation does not document the Salesforce VoiceCallId as an Architect variable or participant attribute returned from Salesforce into the Genesys inbound flow.

The documented synchronization model is primarily in the opposite direction:

Genesys interaction attributes → CX Cloud → Salesforce VoiceCall fields

For example, Genesys supports mapping Conversation.ConversationId, ANI, DNIS, queue information and Participant.{CustomFieldName} values into Salesforce VoiceCall fields.

There is also a useful correlation mechanism on the Salesforce side: the CX Cloud documentation states that VendorCallKey contains the Genesys Cloud ConversationId as its second UUID. This can be useful when Salesforce needs to correlate a VoiceCall record with the original Genesys conversation.

However, I would not use VendorCallKey as a substitute for the call identifier required by the Salesforce Omni-Channel Flow API unless that mapping is explicitly validated for the implementation.

Architect and Genesys ACD remain responsible for the inbound voice routing in the standard CX Cloud Voice architecture. Salesforce Omni-Channel is also used in the CX Cloud agent experience - for example, the agent must be signed into Omni-Channel with a status mapped to Genesys On Queue - but that is different from using a Salesforce Omni-Channel Flow as another routing engine.

So if the requirement is specifically:

Architect → trigger Salesforce Omni-Channel Flow

I would consider that a custom integration requirement rather than an out-of-the-box CX Cloud capability.

Before implementing a custom call from Architect to the Salesforce Telephony Integration API, I would also confirm the intended purpose of the Omni-Channel Flow. If it is being used to make another agent-routing decision after Genesys has already performed Architect/ACD routing, you could effectively introduce two routing engines into the same voice journey.

For the standard CX Cloud Voice design, I would keep routing and orchestration in Genesys Architect/ACD and synchronize the business context required by Salesforce through the supported VoiceCall field mappings.