Genesys Casual

How do you organize naming conventions for flows, tasks, and variables in your environment?

I'm always looking for cleaner ways to keep projects maintainable as they grow.

#General

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

Hi Juliano,

For flows, I usually find it helps to keep naming simple, consistent, and easy to search.

A pattern I like is:

Division_Channel_FlowType_Description

For example:

• IT_Voice_Inbound_ServiceDesk
• IT_Voice_Callback_AfterHours
• Student_Messaging_MFA_Reset

For tasks and actions, I prefer clear action-based names such as:

• Initialize Variables
• Check Business Hours
• Route To Queue
• Update Participant Data

I also tend to use custom names/descriptions for almost every task and action within the flow so it is much easier to read, troubleshoot, and maintain later, especially as flows become larger and more complex.

For variables, I try to keep the scope and type clear:

• Flow.customerId
• Task.validatedId
• State.apiResponse
• strCustomerName
• boolIsAfterHours
• intRetryCount

A few practices that help long term:

• avoid abbreviations unless widely understood
• use consistent prefixes for API/data action variables
• name update data/actions clearly based on purpose
• keep naming predictable across all flows
• use descriptions/comments for complex logic
• avoid special characters where possible

Hope this helps.

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

------------------------------
Kaique M oliveira
------------------------------

I also find it useful to ensure that description of configurations objects are completed and in a dev enviroments that object are suffixed by the creators initials.

------------------------------
Paul Stirk
Solutions Architect
------------------------------

Original Message:
Sent: 05-27-2026 09:01
From: Kaique M oliveira
Subject: Naming Conventions

I use the flow type as a naming prefix, for example:

Inbound Call Flow -> INB_IVR_NAME

Common Module -> CM_NAME

Bot Flow -> VB_NAME

Data Actions -> DA_NAME

For variable name, I usually use camelcase

------------------------------
Kaique M oliveira
------------------------------

Hey Juliano. 

I usually follow the same naming pattern for all objects.

Flows

I always use descriptions because it is very important to clearly explain the purpose of the flow and what it is responsible for.

For naming, I like to identify the environment in the flow name:

• Production flow:
  
  • [PRD] HelpDesk_Whatsapp
• Test/Homologation flow:
  
  • HML] HelpDesk_Whatsapp

Tasks

For tasks, I prefer objective names that clearly describe their purpose, such as:

•  Validate Schedule
• Get APP Variables

Variables

For variables, I follow the same logic. Intuitive names make it easier for other developers to understand the flow and also help a lot during troubleshooting.

Examples:

• Flow.name
• Task.phone

For me, the basic rule is simple: the next person who opens the flow should be able to easily understand what was built and why. Clear naming, descriptions, and object organization make maintenance much easier.

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

I follow the same approach as well. Tasks and variables need to be intuitive for everyone, it really helps when someone else has to debug the flow.

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

Original Message:
Sent: 05-27-2026 09:24
From: Arthur Pereira Reinoldes
Subject: Naming Conventions

Hey Juliano. 

I usually follow the same naming pattern for all objects.

Flows

I always use descriptions because it is very important to clearly explain the purpose of the flow and what it is responsible for.

For naming, I like to identify the environment in the flow name:

• Production flow:
  
  • [PRD] HelpDesk_Whatsapp
• Test/Homologation flow:
  
  • HML] HelpDesk_Whatsapp

Tasks

For tasks, I prefer objective names that clearly describe their purpose, such as:

•  Validate Schedule
• Get APP Variables

Variables

For variables, I follow the same logic. Intuitive names make it easier for other developers to understand the flow and also help a lot during troubleshooting.

Examples:

• Flow.name
• Task.phone

For me, the basic rule is simple: the next person who opens the flow should be able to easily understand what was built and why. Clear naming, descriptions, and object organization make maintenance much easier.

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

I agree with you all, one thing I should add is maybe could be useful having this conventions in English just for support proceseses to be essier to explain when needed. 

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