When given the option, how does one determine whether to work with a script or a flow? Is one format better than the other? What factors should be considered? Let’s explore! Arguments in favor of scripting:
- “I know how to work with text.”
- “I can interpret a script more easily than a flow.”
- “I can create a script much more quickly than I can a flow.”
- “I am supporting an existing system and scripts are already in place.”
Flows can be preferable because:
- “I don’t have to learn the scripting language.”
- “The picture is easier to follow than words.”
- “The flow creates an easy sign-off document for customer acceptance. I don’t have to generate a separate flow chart in a different program.”
- “The system is a new installation and the customer wants to make changes after the system in place.”
Ultimately the decision to use scripts or flows is a subjective decision based on the designer’s preference and the customer’s requirements. At this point there is no compelling reason to choose one or the other from a technical point of view (it has been observed that the flows require more code and as a result they use more server resources than scripts during call-processing, but the difference usually isn’t significant.) Generally, novices to application design gravitate to flows (at least initially), and experienced script writers prefer to stick to scripting.
I urge any person supporting AACC call processing applications to become versed in both text and graphical representations. To the person who prefers flows, it is difficult to make the case to learn the scripting language because the whole point of introducing the flow format is to eliminate that very requirement. However, if you support multiple installations of AACC, the odds are strong that you will eventually encounter scripts. If a person has designs on becoming a well-rounded AACC specialist, scripting should be mastered. Also, some application concepts can only be implemented as text. For example, the EVENT HANDLER must be designed in a custom block (a block that contains text-based script within a flow).
Complaints from experienced application designers include frustration over the extra time that flows take to construct as opposed to text scripts with the same functionality. This argument is valid because inserting, defining, explaining (listing comments), and connecting the blocks is more time-consuming than writing text if you already know how to write the code. It is a challenge to design the icons that represent the blocks because it is difficult to represent an abstract idea in an image-evoking symbol. The details sought by the accomplished analyzer of scripts are not as apparent in the blocks. Thus there can be a degree of disappoint at the lack of intuitiveness in reading a flow.
In view of these protestations, how do we optimize the use of flows? Experienced script writers need to be able to work with flows because they will likely encounter them at some point in their AACC career. Here are four suggestions that will benefit any flow designer:
- SCE and OD provide the ability to convert scripts to flows. Flows can be exported as scripts. A person experienced with scripts and new to flows can create a flow and then export and convert it as a script to verify his work and develop skills in working with flows. One could also write a script and then convert it to a flow to satisfy the AACC implementation that will be supported with graphical call flows. The process of converting a script to a flow takes place in local view. The system does not automatically keep a copy of the text version before converting the application to flow. Be sure to make a copy (save-as or export) of the original text format as a point of reference before the conversion process.
- Post-it or sticky-notes can be added to flows. It is strongly advised that these tools be used with most blocks to facilitate the reading of a flow without requiring a drill-down into the block details. The flow reader can hover the mouse over the note to reveal its contents.
- Flows become easier to create when they are designed in a consistent manner. One can establish a rhythm by following a steady pattern as blocks are inserted into a flow. For example, upon adding a block you would:
- Connect it to the source block
- Open the block and navigate to the first worksheet (lower left tab); assign a meaningful and descriptive name
- Select the next worksheet and specify the details unique to the block
- Add the next block and repeat
- Consider that one of the most common tasks in application design is to test for a condition to determine the most appropriate way to process the contact based on the result of the examination of the condition. In other words, the conditional test is performed first, and the appropriate action is taken second. In the text-based scripting, this is accomplished with the IF-THEN-END IF statement. When designing flows, you will discover that there are two ways to test for a condition: use the logic block or the Transition worksheet within a block. While the Transition worksheet can be used effectively, it can also create awkward results. When the Transition worksheet (within a block other than the logic block) is employed, it is testing the condition for the next block, not the block in which it resides. Working with the Transition worksheet within a block can give the suggestion that the action is going to occur before the conditional test. The logic block facilitates the natural flow of condition testing by distinguishing the conditional test as preceding the action.
With Avaya Aura Contact Center 6, the Contact Router was introduced. All contacts must first pass through the Contact Router. Its job is to identify the contact and pass the contact to the intended primary application. The Contact Router (graphical interface) replaces the Master Script (text interface) of previous releases. The sorting/filtering/traffic-cop function is the same for both views. The Contact Router simplifies the task with its Graphical User Interface. Think of the Contact Router as a specialized, streamlined view of the Master Script. If the routing needs of the supported system align with Avaya’s design intent, then a “best practice” is being followed and the Contact Router is sufficient.
However, other scenarios exist. When the Contact Router is part of the AACC solution, the option to view the Contact Router as a flow is available. The flow version is used if changes need to be made that are not available in the Contact Router. For example, sometimes an announcement is to be played to the caller from the Master Application prior to passing the call to the primary application for reporting purposes. When the flow view is used for updating call-processing design, all subsequent changes must be made in the flow format. Reverting to use of the Contact Router will cause the changes made in the flow to be lost (one is forced by the application to save a copy of the flow before switching back to the Contact Router after changes have been made in the flow format.)
Another alternative is to create a Master Script in the local view. Synchronizing allows the application designer to implement the text-based script in Contact Center view, replacing the Contact Router/flow interfaces. This strategy should only be employed by a person with considerable experience. Multimedia contact processing is not revealed in the Contact Router, but is present, all the same. The flow view shows the multimedia contact handling. If a master script is created as described, one must account for the multimedia contacts if multimedia is part of the AACC solution.
Excerpted and available for download from Global Knowledge: Going with the Flow: How to use Orchestration Designer successfully in support of the Avaya Aura Contact Center
If the AACC system you are supporting was upgraded from a previous release, the master script will be preserved in text format. Following the suggestions in these posts will help you to work more effectively with the Orchestration Designer.