Genesys Cloud - Developer Community!

Hi everyone!

I'd like to start a discussion from a developer perspective.

When developers receive a new Genesys Cloud project and are ready to start the implementation, what information do you usually miss the most?

For example, in projects involving Architect flows, Data Actions, APIs, routing, queues, scripts, bots, or digital channels, what would make the handoff from business/functional teams to development much clearer?

Some examples I'm curious about:

* Clear business rules
* API documentation and contracts
* Request/response payload examples
* Error and timeout scenarios
* Authentication details
* Environment information
* Queue and routing rules
* Flow diagrams
* Naming standards
* Test scenarios
* Acceptance criteria
* Expected behavior for fallback and exception paths

From your experience, what information should always be provided before development starts?

And what are the most common gaps that delay implementation or create rework later?

From my personal experience, the worst issues normally comes from external APIs.

Most of the time there isn't good documentation (if there is any at all). 
Several times it's also difficult to get examples of requests and payloads like you mentioned.
And when we don't have examples, I normally ask for test data so I can run the API a few times and see how it works in practice... But guess what, there is also no test data that can be provided or no test environment, and we can't run the API in the production environment... etc...

It's hard some times hahaha

Curious to see what others see as the worst issues. Hopefully I'm not the only one that always get APIs without documentation haha

Thanks, @Marcello Jabur !

I completely agree. External APIs are often one of the biggest challenges. Even when documentation exists, it's sometimes outdated or missing important details such as payload examples, authentication requirements, or error responses.

Your point about the lack of test environments is also very true. Having a sandbox or sample data available can make a huge difference during implementation and helps avoid unnecessary delays.

Hello, @Fabíola Freitas.

From my experience, two of the most important things are clear business rules and good API documentation.

Clear business rules help developers understand what needs to happen in each scenario, including exceptions, fallback paths, and expected outcomes. Without that, developers may need to make assumptions, which can create rework later.

API documentation is also very important, especially when the project involves integrations, Data Actions, or external systems. Having clear endpoints, authentication details, request and response examples, error scenarios, and timeout behavior makes the implementation much smoother.

The customer API documentation is fundamental; sometimes, a simple project becomes a huge problem because we lose a lot of time understanding those APIS.

Thank you, @Arthur Pereira Reinoldes !

I really like your point about business rules. I've seen several projects where the technical implementation wasn't the difficult part-the biggest challenge was understanding the expected behavior for every scenario, especially exceptions and fallback paths.

Your comment reinforces how important it is to have both functional and technical documentation working together before development starts.

Hi Fabíola Freitas, 

Adding another point to what was already mentioned, from my experience something that also helps a lot is documentation consistency and naming standards.

When the same queue, flow, script, Data Action, or other Genesys Cloud object has different names across the business document, flow diagram, and Genesys Cloud environment, it can create confusion during implementation.

Having a clear naming standard and an object mapping before development starts helps keep the implementation more consistent, especially when more than one team or developer is involved. It also makes the solution easier to understand, maintain, and support later.

So, besides business rules and API documentation, I would say that consistent naming and clear object references are also very important to avoid rework.

Great point, @Luiz Rosa !

Naming consistency is something that is often underestimated, but it makes a huge difference, especially in larger projects involving multiple developers and environments.

Having a clear naming convention and object mapping from the beginning certainly helps reduce confusion and makes maintenance much easier over time.

Hi Fabíola , Really good points shared by everyone.

The API/documentation topic especially resonates with me as well. In many integration projects, challenges often come from external systems lacking clear documentation, sample payloads, test environments, or defined exception handling.

I also completely agree on naming consistency. Once flows, queues, Data Actions, bots, and environments start scaling across teams, having clear object naming/mapping becomes extremely important for maintainability and troubleshooting later.

One thing that has also helped me recently is using Eraser.io, where you can prompt/generate flowcharts and journey diagrams quickly to visualise APIs, Architect flows, routing, integrations, and exception paths before development starts. It has helped uncover gaps and assumptions much earlier in projects.

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

Thank you for sharing this, @Phaneendra Avatapalli !

I actually wasn't familiar with Eraser.io. At the moment, I use draw.io to design Architect flows and integration diagrams before handing them over to the development team, and it has worked well for documenting the solution.

I'll definitely explore Eraser.io to see how its AI-assisted diagram generation compares. If it can help identify gaps and speed up the design process, it could be a great addition to my workflow.

Thanks for the recommendation!

Hi Fabiola,

Great to hear! draw.io is a solid choice for Architect flows and integration diagrams. Eraser.io's AI-assisted generation is definitely worth exploring alongside it the two can complement each other nicely. Would love to hear your thoughts once you've had a chance to try it out!

Hi @Fabíola Freitas, 

As everyone mentioned as much information as we have less rework we´ll do.

So, clear and updated documentation is very important. APIs doc. Infra architecture. The phone provider. 

Hopefully to help you up.

Regards

Thanks, @Christian Kato !

I completely agree. The more complete and up-to-date the documentation is, the smoother the implementation tends to be.

Your point about infrastructure and telephony providers is also very important. Those details are sometimes overlooked during the handoff but can have a significant impact on the project.