Building A Complex Application

Having covered the basics of Fuse, now it's time to focus on more complex applications. This means, for example, an application that collects caller account data, queries a webservice for authentication, presents the caller with a menu of options, and provides the caller with details about their account.

Collecting Caller Input

Caller input refers to either Speech or Touch-Tone (DTMF) input provided by the caller. Only the modules listed in the Input section of the Modules menu actively listen for caller input.

Variables

It is important to understand that modules automatically create variables in Fuse based on the name of the module. In the screenshot above, the module asks the caller to provide their account ID and Fuse stores the resulting input in a variable named accountID.

Options

  1. Barge-In: Allows the caller interrupt the prompt with input, advancing the call-flow before the prompt finishes. Note: When barge-in is enabled the top line of the text box changes from a solid line to a dashed line.

  2. Enabled Speech Input: By default, this module only allows DTMF tones. Toggling this option enable speech input.

  3. Min / Max Digits: This determines the rules for acceptable input length. For example, if account numbers are 7 digits long, setting both the Min and Max to 7 forces users to enter 7 digits. Any input that contains additional or fewer digits will trigger a 'No Match' error.

  4. Private: This setting controls whether Fuse logs caller interactions with this module. By default, logging is turned on.

  5. Show Custom Errors: This allows users to provide custom No Match/No Input paths for the module. If this option is disabled, then the application uses the default No Match/No Input rules defined on the Settings tab for the application.

Try adjusting each of these settings. Notice that each change causes a small visible change to the module. This is done so users can quickly identify which options are enabled without opening the options menu. For the current sample application, leave all of the module options on their default settings, i.e. barge-in enabled and all other settings disabled.

Error Handling

Input modules have the ability to trigger No Match and No Input errors based on the caller's behavior.

By default, input modules utilize the global settings which play a generic prompt (e.g., “I'm sorry I didn't get that”) and then repeats the current module. If the caller produces three errors, in any combination of No Match or No Input, Fuse's default setting is to then disconnect the call.

For example, the default global settings produce the following behavior for all input modules.

Variables & Branching

When adding a module to the workspace, users will notice that the default title of the module is “varX”, where X is a number. The module title functions as a variable within Fuse. This occurs automatically and Fuse stores the results from that module, under that variable name, for later use.

Fuse automatically globally scopes all variables within an application and variables are accessible from any page. Jumping to a new application creates a new scope with a new set of variables.

WYSIWYG Prompts

  • Acronym

  • Address

  • Currency

  • Date

  • Time

Use Case

Branching

In Fuse, branching, also called jumping, refers to the routing options a module provides. Oftentimes, an end-user's input influences their path through a call-flow, and Fuse allows users to branch, or re-direct, a call based on a dynamic value. Fuse provides users with multiple ways to create branches within an application.

    • This makes it easier for users to manage their Fuse apps because it is easy to break a call-flow into its component parts, place each section on its own page, and then connect the pages using modules. This approach is also useful if an application uses a specific section in multiple places within a call-flow; users can jump to that sections without the need to re-create it in multiple pages.

See the Modules page for more information on these modules and how variables function.

Data Integration

Accessing Return Data

When performing data integration, the values returned to the Fuse application can be accessed as a complex object using Javascript dot notation.

{“id”:1234,“name”:“John Doe”,“status”:{“overdue”:false,“balance”:1234.56}

Users can access these values as result_result.id, rest_result.name, rest_result.status.overdue, and rest_result.status.balance. This provides users with easy, direct access to these Javascript variables.

Debugging

This generates a call log that users can then consult in order to view the full request and its response data. The call log also details the full Javascript object that Fuse created based on the response data.

This lets users see exactly how to access the resulting data structure. It also provides insight as to how to debug any request or response parsing issues in the module.

Last updated