Genesys Cloud - Developer Community!

Hi Dev Community,

The path to becoming a developer in Genesys Cloud CX can be a bit challenging for those of us who spent many years working with support and implementation in Genesys Engage.

With the move to Cloud, many professionals were pushed to expand their skill set more toward the development side. In the past, a big part of our daily work involved monitoring servers and applications, checking whether Config Server was in read-only mode, monitoring database health, and dealing with infrastructure-related issues.

A lot of people coming from the support side have strong platform knowledge but less development experience.

In my case, I started working with Genesys Engage 7.5 back in 2014. Over the years I worked heavily with support and implementation, created many IRD flows, did some work in Composer, and more recently I've been exploring Architect and trying to move deeper into the development side of Genesys Cloud.

I'm not sure if there is already a discussion about this, but I would really like to hear your perspective:

What do you think is the best path for making this transition from Engage/support-oriented roles into a more developer-focused role in Genesys Cloud?

I started this transition about a year ago, but I would appreciate advice from people who have already gone through this journey - especially regarding which skills or technologies are truly worth focusing on, and what things I might currently be spending too much time on that are less relevant today.

Looking forward to hearing your experiences and recommendations.

#Architect

------------------------------
Arthur Gomes
Indra Soluciones Tecnologías de la Información, S.L.
------------------------------

Arthur, honestly, many of the strongest Genesys Cloud developers I know came from exactly that Engage/support background.

People sometimes underestimate how valuable deep operational knowledge is. Understanding routing behavior, telephony, interaction lifecycle, queues, reporting, troubleshooting, and real production pain points gives you a huge advantage over developers who only know APIs and code.

The biggest mindset shift is that in Genesys Cloud the platform becomes much more API-driven and event-driven.

So instead of focusing heavily on infrastructure/server management, I would probably prioritize:

• Architect deeply

• APIs/Data Actions

• OAuth/Auth flows

• Webhooks/Triggers/Event-driven integrations

• JSON handling

• basic Node.js or Python

• async integration patterns

• observability/logging

What helped me most was stopping thinking in terms of:
"how do I configure this server/platform feature?"

and starting to think:
"how do systems communicate and orchestrate experiences?"

Because modern Genesys Cloud projects are increasingly integration projects rather than pure contact center configuration projects.

Another important point:
do not underestimate your IRD/Composer experience.

A lot of concepts still translate surprisingly well:

• routing logic

• state handling

• failover thinking

• queue strategy

• business process orchestration

• edge-case management

The tools changed, but the operational reasoning is still extremely valuable.

One area I would strongly recommend investing time in is understanding asynchronous/event-driven architectures. That becomes critical very quickly when working with messaging, bots, AI, CRM integrations, and automation at scale.

I also think many people coming from Engage spend too much time trying to learn "everything frontend/full-stack" immediately.

In reality, being very strong in:
Architect + APIs + integrations + automation
already creates enormous value in the Genesys Cloud ecosystem.

Especially now with AI, Copilot, AVA, orchestration, and digital channels growing fast, the people who combine operational CX knowledge with integration/development skills are becoming extremely valuable.

------------------------------
Gabriel Garcia
NA
------------------------------

Hello, @Arthur Gomes.

As @Gabriel Garcia said, all your knowledge about Genesys Enagage will be really useful.

From my experience, one of the best ways to make this transition is to focus on the parts of Genesys Cloud that connect configuration with development.

For me, the most important topics are Data Actions, Data Tables, Genesys Cloud APIs, and Architect expressions.

Data Actions are very relevant because many customer requirements depend on connecting Genesys Cloud with external systems, such as CRMs, databases, or middleware. So it is important to understand how to configure the endpoint, authentication, request and response mappings, and how to troubleshoot errors.

Data Tables are also useful, especially for simpler scenarios where you need to store and retrieve information directly inside Genesys Cloud without creating a full integration.

I would also recommend learning the Genesys Cloud APIs, even at a basic level, because they help you understand what can be automated or extended beyond the UI.

And for an architect, expressions are essential. A lot of flow logic depends on them, so knowing how to work with variables, strings, dates, booleans, and participant data makes a big difference.

Coming from Engage/support, the platform knowledge is already a strong foundation. The main change is moving from infrastructure troubleshooting to thinking more about integrations, automation, and how to solve business problems using Cloud Cloud.

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

I came from Engage too, so I can definitely relate to this.

For me, one of the hardest parts wasn't really learning tools like Architect or APIs, it was more about adjusting how I looked at the role.

In Engage, a lot of my day-to-day was support, troubleshooting, infrastructure, and just making sure things were stable.
With Cloud, I've found that background still helps a lot, but the focus seems to shift more toward integrations, automation, and building solutions.

One thing I've realized is that the Engage experience still has a lot of value.
Routing logic, troubleshooting, and understanding operational challenges still carry over more than I expected.

For me, one of the bigger changes was spending less time focused only on platform health and more time learning how systems connect, how to automate processes, and how to build things in a different way.

Lately, I've been trying to spend more time on Architect, APIs, and integrations because that seems to be where a lot of the growth is.

I also don't think anyone needs to feel pressured to become a full software developer right away.
From what I've seen, strong operational knowledge combined with automation and integration skills already goes a long way.

For me, it hasn't really felt like starting over, more like gradually adapting what I already knew to a different way of working.

------------------------------
Luiz Rosa
Full stack developer
------------------------------