Properties Tab | OCP® Learning Center

Introduction

In the Properties tab, you can customise and adjust the miniApp behaviour to your liking and decide when and how the call ends depending on the type and number of errors that occurred in the dialog. All the error handling fields have built-in optimized default values, but allow you to fully configure them if needed.

The properties set up here will affect the scope of the entire miniApp.

Each section below includes information about which settings relate to which errors, and you can check the list of all the available resulting errors in the Fail Exit Reason page.

General Attributes

These are General properties for the miniApp and will apply throughout the miniApp, unless a specific property is set for a certain step, for example in the initial prompt.

Adjust the ASR timeout range slider to specify how long the system waits to trigger a noInput event.

Add a Custom NLU tag value in the corresponding text box, used to define a more specific context. Tag Hour for example. Under that tag context, a number input, for example, four, will be marked and understood as the time of the day from the system (four o’clock). So, in general, tags help differentiate and define a more specific meaning from user inputs.

For more information how to create context and corresponding context tags, please read the Adding contexts section in Adding custom data to an NLU model page.

For Date miniApp you can find a predefined list of tags to help you configure the context:

Normal date (default)
Credit card expiration date

You can specify an additional field called Confidence Threshold. The Confidence Threshold is a configurable value that evaluates how certain the platform is about a recognized input. It is used to decide whether a recognized result should be accepted, ignored, or clarified. If the confidence level is equal or below the threshold, a No Interpretation error will be triggered.

Confidence Threshold field can take on values between 40 and 95.

For Intent miniApps: a threshold can be configured in the Properties tab. If the detected Intent confidence is below that threshold, the Intent is ignored.
For Intent Disambiguation: a field named IntentConfidence is available in the condition field selection. When used with a threshold, it can trigger a clarification step if the Intent confidence is below the configured value.
More information in Intent OCP miniApps® | Intent Confidence Threshold
For non-Intent miniApps: confidence thresholds are used to decide whether user input is acceptable. If the confidence does not meet the configured threshold, the input is treated as low-confidence and normal error-handling logic applies.

Example: if a caller says something that is interpreted as a balance inquiry, but the Intent confidence is below the configured threshold, the system can avoid accepting that Intent immediately and instead ask a confirmation-style question such as: “To confirm, you asked for your bank account balance?”

How to use Confidence Threshold

This feature is useful when a flow needs more control over ambiguity. Typical use cases include:

preventing low-confidence Intent matches from driving the wrong journey
adding clarification before continuing with a sensitive action
making behaviour stricter for high-risk or high-importance intents
improving customer experience by asking for confirmation only when confidence is uncertain

Best practice: start with a moderate threshold, test with real utterances, and then tune it based on observed behavior. A threshold that is too low may accept uncertain results; a threshold that is too high may cause too many clarifications.

Error Reactions

Error reactions are randomly thrown, right before a system action, according to their weight. They make the dialog sound more conversational, they are optional and they can be left blank.

To set the error reactions, fill in the Error Reactions Prompts in the corresponding menu.

Additionally, you can choose to disable the final error reaction when the error counter reaches its maximum value. To do so, in the Other Error Settings use the Disable error reaction upon exit toggle button.

Error Handling

Max No Response Errors

Continuous no responses allowed: Counts consecutive No Input events. The counter is reset, if an event other than No Input occurs in the dialog.
Global no responses allowed: Global counter of No Input events (for example, no speech was heard) occurring throughout the dialog.

Related fail_exit_reason errors: MaxContinuousNoInputs, MaxNoInputs, MaxDisambiguations

Max No Interpretation Errors

Continuous no interpretation errors: Counts consecutive No Match or rejection events. The counter will be automatically reset to 0 if another event occurs in the dialog.
Global no interpretation errors: Global counter of No Match events (either due to low confidence or because no interpretation was assigned to the caller’s utterance despite some speech being detected) occurring throughout the dialog.
Max Continuous repeat requests: Counts consecutive requests from the caller to replay the last prompt. The counter resets to 0 when another event occurs in the dialog.
Max repeat requests: Counts the total requests from the caller to replay the last prompt during the discussion.
Max disambiguation attempts allowed: Counts disambiguation steps. The caller can disambiguate only a specific number of times.

Max disambiguation attempts allowed is only applicable for intent miniApps.

Related fail_exit_reason errors: MaxContinuousNoMatches, MaxContinuousLowConfRejections, MaxContinuousSameStateEvents, MaxNoMatches, MaxLowConfRejections, MaxSameStateEvents, repeatRequestsMax, continuousRepeatRequestsMax.

Max Mixed Errors

Continuous mixed errors: Counts consecutive error events (for example, NoInput, NoMatch, LowConfRejection, Same State, WrongInput). The counter will be automatically reset if a non-error event occurs.
Max mixed errors: Counts NoInput, NoMatch, Rejection, Same State, WrongInput throughout the dialog. It is not reset.

Related fail_exit_reason errors: MaxContinuousErrors, MaxGlobalErrors.

Max DTMF Inputs (Intent miniApps only)

Max DTMF inputs: Counts the number of times the caller can press a DTMF key.

Related fail_exit_reason errors: MaxDtmfInputs.

Critical Error

This error is not connected to any particular error counter. If the system identifies a critical error, a predefined prompt can be triggered, and decide whether to end or transfer the call to an agent.

Related fail_exit_reason errors: CriticalError.

Information Not Available (Non-intent miniApps only)

This error is not connected to any particular error counter. It arises when the caller has not provided any information. Here you can set a predefined prompt to be triggered, and decide whether to end or transfer the call to an agent.

Related fail_exit_reason errors: InfoAsked_NotAvailable.

Invalid Inputs (Non-intent miniApps only)

Max invalid inputs: Counts the number of times the caller can provide invalid information throughout the dialog.

Related fail_exit_reason errors: MaxWrongInputs.

Disconfirmations (Non-intent miniApps only)

Max disconfirmations: Counts the number of disconfirmations the caller can make. Only valid when the Confirmation option is on in the Confirmations tab.

Related fail_exit_reason errors: MaxDisconfirmations.