Genesys Cloud - Main

 View Only

Sign Up

  • 1.  Variables Organization

    Posted 07-15-2026 08:33

    Hi all,

    When building large Architect flows, variable management can become difficult.

    How do you organize:

    • Flow variables
    • Task variables
    • Session variables
    • Naming conventions

    Do you have an internal standard that has worked well?


    #ArchitectandDesign

    ------------------------------
    Fausto Brito
    ------------------------------


  • 2.  RE: Variables Organization

    Posted 11 days ago

    Hi Fausto, here's what has worked well for me on large flows:

    Prefix by scope: keep the scope visible in the name, like Flow.customerId, Task.validatedId, State.apiResponse, so you always know where a value lives.

    One casing style: camelCase everywhere, with a short type hint only where it helps (boolIsAfterHours, strCustomerName). Avoid abbreviations unless everyone knows them.

    Declare inputs and outputs first: keep inputs/outputs at the flow level and put temporary variables inside the task that uses them. Fewer shared variables means fewer side effects.

    Name flows the same way: Division_Channel_Type_Description, with an environment tag like [PRD]/[HML] if you test in the same org.

    Document the standard: put a one-page convention in a shared place and review new flows against it.

    The rule I use is that the next person who opens the flow should understand what was built and why without asking you. Curious what others do for session-level data.



    ------------------------------
    Robson
    Coordenador de Infraestrutura
    ------------------------------



  • 3.  RE: Variables Organization
    Best Answer

    Posted 10 days ago

    Hi Fausto,

    In large Architect flows, I've found that variable organization becomes critical not only for readability but also for long-term maintenance.

    Some practices that have worked well for our team:

    1. Keep the scope as small as possible

    • Use Task variables for temporary values that are only needed within a specific process.
    • Use Flow variables only when data must be shared across multiple tasks.
    • Reserve Session variables for information that needs to persist across transferred flows or throughout the customer journey.

    This helps reduce unintended dependencies and makes troubleshooting much easier.

    2. Use functional prefixes

    Instead of only identifying the scope, we also categorize variables by purpose:

    • cust_ → Customer data
    • ivr_ → IVR selections
    • api_ → API requests/responses
    • sys_ → System-generated values
    • tmp_ → Temporary processing variables

    Examples:

    • cust_accountNumber
    • api_orderStatus
    • ivr_selectedLanguage
    • tmp_validationResult

    3. Centralize reusable logic

    When the same variables and logic are used repeatedly, we try to move them into reusable tasks or common modules. This reduces duplicated variables and keeps naming consistent across flows.

    4. Document business-critical variables

    For integrations, customer identifiers, routing decisions, and session attributes, we maintain a lightweight design document describing:

    • Variable name
    • Purpose
    • Data type
    • Source system
    • Expected values

    This becomes extremely valuable when troubleshooting months later.

    5. Periodic cleanup

    During enhancements, we review flows for unused variables, obsolete API responses, and legacy logic. Large Architect flows tend to accumulate technical debt very quickly if nobody performs regular cleanup.

    Our general rule is: if another Architect developer can understand the variable's purpose without opening multiple tasks, the naming convention is doing its job.

    I'd also be interested in hearing how others manage session variables across multi-flow customer journeys and complex integrations.



    ------------------------------
    Cesar
    INDRA COLOMBIA
    ------------------------------



Related Content