Genesys Cloud - Main

 View Only

Sign Up

Back to discussions
Expand all | Collapse all

Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

  • 1.  Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 2 days ago
    Hi everyone!
     
    I would like to ask for your support on Genesys Cloud Idea CERTNG-I-1980 from @Brad Shoptaw.
     
    High-size flows are usually complex and have more than 350 variables. It would be very good if Genesys raised the limit a bit more, to make data tracking and troubleshooting easier.
     
    According to Genesys, currently, there are no plans to implement this in the near term, but if this feature would help your organization, please consider voting and commenting on the idea so that they can consider it more briefly.
     
    Thank you!
     

    #ArchitectandDesign

    ------------------------------
    ---------------------
    Edgar Dreger
    Senior Genesys Analyst
    ---------------------
    ------------------------------


  • 2.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 2 days ago

    Hello Edgar,

    Thank you for sharing. While I don't personally have any call flows with 350 variables in my test org, I would love to hear about this limit from others in the community.



    ------------------------------
    Jason Kleitz
    Online Community Manager/Moderator
    ------------------------------

    Original Message


  • 3.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 2 days ago

    Hello Edgar, 

    This is a great discussion point... I am curious, what type of flow would have more than 350 variables?

    I am more towards "expert" system that interact with one another other than 1 size-fits-all flow. So I am curious to hear more about this.

    Thanks for starting this thread. 



    ------------------------------
    Rodrigo Romao
    NALA Team Lead - Genesys - Employees
    ------------------------------

    Original Message


  • 4.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 2 days ago

    Hello, @Edgar Dreger!

    Voted! We have some customers with very large flows that usually take a lot of time for troubleshooting when they have some issues.

    It would be great if Genesys increases this size.



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

    Original Message


  • 5.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 2 days ago

    @Arthur Pereira Reinoldes thank you!!



    ------------------------------
    ---------------------
    Edgar Dreger
    Senior Genesys Analyst
    ---------------------
    ------------------------------

    Original Message


  • 6.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 2 days ago

    Hi @Rodrigo Soares and @Jason Kleitz!!

    Thank you for your replies!!

    Our client is from the banking segment and has approved a flow with many self-services, where the customer can consult the information of their contract, renegotiate, consult the installment of the contract knowing in advance the amount of the installment they will pay in URA itself, and you can still choose the payment method, the date on which you want to pay, as well as specific scenarios of contracts in surplus and loss. 😅

    I understand your curiosity, and maybe it's a scenario "outside the curve", but it's our current reality and would have made troubleshooting easier, despite the good mapping of participant data that we did.

    Best Regards!!



    ------------------------------
    ---------------------
    Edgar Dreger
    Senior Genesys Analyst
    ---------------------
    ------------------------------

    Original Message


  • 7.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted yesterday
    Edited by Brian Jones yesterday

    I upvoted this as well given we have flows that exceed the Flow Execution All limit (they're only at 65% flow size with just over 200 variables, which we could reduce by 70 if we switched out Task variables for Flow variables). Although we do some flow to flow transfers, the primary reason we don't do significantly more flow to flow transfers is because it's a pain to pass variables from one flow to another flow in an effort to maintain continuity & context. The minute you forget to Set and Get a Participant Attribute is the minute your flow breaks. 

    Also, although the suggestion of using Common Modules is novel, those Common Modules still contribute to the main flow size when executing as well as still eat into the variable limit. Not to mention once you update a Common Module, you have to republish each one of your flows that use said Common Module (see this thread and this thread).



    ------------------------------
    Brian T. Jones | Ascension | Senior Specialist - Technology | Colossians 3:23-24
    ------------------------------

    Original Message


  • 8.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted yesterday
    Voted.
    I've had problems with a very large flow that exceeded the limit; it's not impossible, it can happen.
     
    Increasing that limit would help a lot.


    ------------------------------
    Kaio Oliveira
    GCP - GCQM - GCS - GCA - GCD - GCO - GPE & GPR - GCWM

    PS.: I apologize if there are any mistakes in my English; my primary language is Portuguese-Br.
    ------------------------------

    Original Message


  • 9.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted yesterday

    Like @Brian Jones said, highly leveraging Common Modules will get you to the limit very quickly.  And unfortunately, it's not the consumption of the variables that count, but merely the declaration of the variables, whether it is referenced or not.  As a consultant, I sometimes have no control over the data/variable scheme and the only workaround that doesn't force the Customer to compromise scalability, is to replace Data Action/Data Table output variables with raw JSON responses, then update all of the expression logic to access the data via the JSON path.  Functional, but time consuming and difficult for a Customer to maintain.  Building a solution that meets Customer requirements is of tantamount importance but, with Genesys being kind enough to provide so many possible ways to do that, consideration needs to be given to the level of complexity that the Customer is able to take responsibility for.  Workarounds for the Flow Variable limit such as converting Variables to JSON results "feels" irresponsible.  The limit should be AT LEAST DOUBLED or, alternatively Architect should enforce the limit on EACH FLOW INDEPENDENTLY.



    ------------------------------
    Jason Rottero
    Wildcard Technology, Inc.
    jason.rottero@wildcardtech.co
    ------------------------------

    Original Message


  • 10.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 15 hours ago

    It's a real problem for us and I wish it was raised. The "base" level of execution history is better than nothing, but so frequently the state or value of a variable is what causes the flow to diverge or fail. Not being able to see those as the call develops is so, so painful when trying to troubleshoot anything.

    It means we end up populating tons of garbage variables into Participant Data just for the sake of debugging or troubleshooting later which, as well as being time-consuming, is a poor CX/UX.



    ------------------------------
    James Dunn
    Telecoms Specialist
    ------------------------------

    Original Message


  • 11.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 10 hours ago
    Hi Edgar,
    Voted!
     
    Increasing the flow variable limit would be very helpful for organizations working with large and complex Genesys Cloud flows.


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

    Original Message


  • 12.  RE: Idea CERTNG-I-1980: Increase Flow Execution Variable Limit

    Posted 10 hours ago

    I have been monitoring this ideas entry for over a year now as we got hit hard by the lack of execution history. In one of our flows, we have ~250 potential destinations the call path can take between automations, offloads and regionally based queues. When Execution history was first released, it was awesome to no longer have to leave breadcrumbs of Set Participant Data that we would then have to refer back to the call details to see what values were returned.

    Then our largest call flow lost exec history, and it felt like Genesys removed a tool from us with no regard for customers using the tool. We even got as far as being approved to have our exec history upped to 500 but system stability could not be guaranteed so we ultimately declined the upgrade as it would have really been a downgrade on stability. There is also the incredibly frustrating thing of never knowing when your flow is going to cross that magical limit with no visible on-screen counter.

    Reply from our Genesys Customer Success Director while going through this initially in Feb 2025:

    This is great news That we were able to get approval to increase your limits to 500 since I was told this was not approved initially.  I do know there is no flexibility at this time to go above 500 because of concerns on platform stability that we found around these limits.  We are being very cautious and testing actively before going to any higher number.  I understand this is frustrating but the team has prioritized this but has no ETA.

    I will conclude with I wish I had the energy to truly express how infuriating it is trying to design a call flow without exec history, let alone trying to troubleshoot a system outage issue.

    -brad



    ------------------------------
    Brad Carroll
    Auto Club Group
    ------------------------------

    Original Message


Related Content