Block Limit on Scenario

1

Is it possible to raise the block limit for scenarios? I’m getting the attached error.

image
image906×312 7.98 KB

2

What kind of scenario are you running that would require 500 blocks? I would hate to be the admin in charge of maintaning that.

Even if there was a way to raise that limit, for your own sanity sake, start splitting up that scenario into multiple scenarios. I call them multitiered because you select 1 of 8 options, then you drop to another menu that has 8 options and you select 1 and so on…

I divided them out based on department or comminality. Then for each team everyone had their own route to agent block. So IT goes into the one scenario as a find agent, HR etc…

We do integrations with a questionable API at best…so you can break that out too.

3

If you are not able to break the scenario out into multiple scenarios, I would recommend recycling more of the code you already have. I have found, when reviewing other clients code, that there are many similar flow objects that can be broken out into their very own sub-section and to can use a “Go To” object instead of a series of log objects, and a few set variable objects, then finally an exit object. The “Go To” would replace the multitude of the redundant objects and just point you to one end of call section at the bottom of your flow. Use comment objects to encapsulate a start and end of the segment of the scenario. I have often performed this to keep code portable between environments.

There are pros and cons to breaking the scenario out into multiple scenarios. You have to make the decision that is best for you.

Pro:

  • Code is easier to view and follow if you aren’t familiar with the build.
  • Scenario can be easier to manage making edits.
  • No worries about scenario block limits.

Con:

  • Code isn’t as portable. It can be more frustrating move from one tenant to another. In the cases where multiple Bright Pattern tenants are at play (staging tenant versus a production tenant, multi-country hosting, etc.)
  • Real-time metrics counter for “IN inIVR” will loose track of the number of people in the IVR. Once you leave the first scenario and start the second the counter drops that interaction. I have a PER open about this with BP.
  • Viewing an interaction scenario steps in the Interaction Records becomes multiple pages as opposed to one.
  • There is the potential of deploying a version of a scenario that invokes other scenarios that invoke the starting scenario, causing an infinite loop in the scenario engine. (At the start of an interaction, the scenario engine invokes all the connected possible scenarios even if the caller does not traverse them. A loop can cause the engine to just keep invoking them until your application crashes.)