Genesys Casual

For orchestration projects, do you rely more on Data Actions/API integrations or native Architect logic?

I'm curious how different teams balance external integrations versus keeping everything inside Genesys Cloud.

Thank you in advance.

#General

------------------------------
Juliano Fernandes Mendes Pimentel De Paiva
Genesys Analyst
------------------------------

Hi Juliano,

For us, it is usually a combination of both.

We try to keep as much business logic as possible within Architect because it is easier to maintain, troubleshoot, and hand over to other administrators.

However, when we need to integrate with external systems, perform complex lookups, or orchestrate multiple API calls, we typically use Data Actions (and occasionally Functions when additional processing is required).

A good example is our ITSM integrations, where Architect handles the call flow and decision making, while Data Actions/APIs are used to retrieve and update information in external platforms.

My general preference is to keep the orchestration in Architect and only move logic outside Genesys Cloud when there is a clear requirement that cannot be handled natively.

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

I think too much logic on Architect makes complex the flows for understanding and maintaining. However, you can as well break the complexity in several flows or reusable taks/common modules/bots.

On the other side too much logic in data action could  make slower the APIs and having delays that are going to impact you in limits.

So, I would keep data actions clean just for what they were intended: data exchange, but this is my personal point of view. 

------------------------------
Miguel Lopez
Solutions Consultant
------------------------------

Hello, Juliano!

For me, it really depends on the use case.

Whenever Genesys Cloud has a native feature that can solve the requirement, I prefer to keep the logic inside Architect. Native functions are usually easier to maintain, easier to troubleshoot, and reduce the number of possible failure points. It also makes the flow more readable for the next person who needs to support it.

I usually rely on Data Actions or API integrations when the flow needs something that Genesys Cloud does not have natively, such as checking customer data in an external system, validating business rules, creating records, updating tickets, or retrieving dynamic information.

The key point is balance. If the requirement can be solved natively, keep it native. If the process depends on external data or business logic, then Data Actions and APIs become very powerful. But I try to avoid unnecessary integrations, because every external call adds complexity, latency, and another place where something can fail.

------------------------------
Arthur Pereira Reinoldes
------------------------------

------------------------------
Elisson Fernandes
------------------------------