Deck_4_US_Non_IVA_Router_Module

Question 1

What is the US Non-IVA Router?

Answer 1

WizeConnect_US_C_Non_IVA_Router — a FLOW MODULE (not a standalone flow) that handles US and Canada Non-IVA call routing. It gets invoked by the US Landing Flow’s module loop | does phone validation | language selection | and queue assignment | then returns control back to the landing flow via EndFlowModuleExecution. 44 blocks total.

Question 2

What makes this a module instead of a flow?

Answer 2

It ends with EndFlowModuleExecution instead of Transfer to Queue or Disconnect. This means it returns control to whatever flow invoked it (the US Landing Flow). It’s like a function that gets called and returns. The UK Non-IVA is a standalone flow that handles everything itself.

Question 3

What is Block 1 of the US Non-IVA Router?

Answer 3

Set Initial Attributes — sets 4 attributes: PathLog (tracking) | RetryPhone = 0 (phone validation retry counter starts at zero) | NoInputRetry (timeout retry counter) | NoMatchRetry (no match retry counter). These counters drive the retry logic later.

Question 4

What is Block 2?

Answer 4

Invoke PromptLambda — calls $.Attributes.PromptLambda to get dynamic prompts for this module. The Lambda returns all the text/SSML prompts the module needs. This is the same pattern used across all Likewize modules — prompts are never hardcoded.

Question 5

What is Block 3?

Answer 5

Set Flow Attributes — takes the Lambda return and sets the prompts as flow-level attributes so the module can reference them. Flow attributes are scoped to the module only | unlike contact attributes which persist on the call.

Question 6

What is Block 4 — the TaskName check?

Answer 6

Compares $.Attributes.TaskName against 3 values: US&C_Non_IVA_Router_Initialize | Non_IVA_Router_ValidatePhone | and DEFAULT (first entry). TaskName determines which PHASE the module is running — it gets called multiple times with different TaskName values as the conversation progresses.

Question 7

Why does the module get called multiple times with different TaskNames?

Answer 7

The module loop pattern: the landing flow calls this module → module does phase 1 | sets Next_Module_Step and TaskName for the next phase → returns to landing flow → landing flow calls NextModuleLambda → Lambda sees the new TaskName and returns this same module again → module runs phase 2 with different logic. It’s a state machine driven by TaskName.

Question 8

What happens on DEFAULT TaskName (first entry)?

Answer 8

Block 5: Invoke FetchUserLambda ($.Attributes.FetchUserLambda) — looks up the caller by their ANI (phone number). Block 6: Set 3 attributes: PhoneNumber | OriginalPhoneNumber | UserANI. Block 7: Set 5 attributes: TaskName | Next_Callback_Module_Step | Next_Module_Step | ChannelUserId | UserANI → EndFlowModuleExecution (return to landing flow with user info loaded).

Question 9

What happens on US&C_Non_IVA_Router_Initialize TaskName?

Answer 9

Set ValidationRegex → Check CommandType. CommandType determines what action to take: -1 (skip to callback) | 24 (collect phone number) | 46 (route by DNIS). These command values come from the PromptLambda return.

Question 10

What happens when CommandType = -1?

Answer 10

Set Next_Callback_Module_Step → EndFlowModuleExecution. This means skip phone collection and go straight to the callback path. The module returns immediately and the landing flow loop picks up the callback module next.

Question 11

What happens when CommandType = 24?

Answer 11

Phone number collection via Lex bot. This is the most complex path in the module — it uses a Lex bot to capture the caller’s phone number | validates it | and has a 3-attempt retry loop.

Question 12

Walk through the CommandType 24 phone collection path.

Answer 12

Lex bot prompts caller to say or enter phone number → Caller provides input → Module captures InsuredDevicePhoneNumber and value from Lex slots → Check ValidInput for InvalidLength or InvalidPattern → If valid: set TaskName + Next_Module_Step + Next_Callback_Module_Step → EndFlowModuleExecution. If invalid: enter retry loop.

Question 13

How does the phone validation retry loop work?

Answer 13

RetryPhone attribute tracks attempts (starts at 0). Retry 0: increment PhoneRetry | check if invalid length or pattern | re-prompt with a yes/no Lex bot to confirm. Retry 1: increment PhoneRetry | re-prompt again. Retry 2: set RetryLoop | update PathLog | play failure message | set Connect_AuthFailed and Connect_AuthSuccess | DISCONNECT. Three strikes and the call ends.

Question 14

What happens when the Lex bot returns FallbackIntent during phone collection?

Answer 14

Check RetryLoop against 2. If already at 2 retries → disconnect. Otherwise → loop back for another attempt. FallbackIntent means Lex couldn’t understand the input at all — not even enough to validate length or pattern.

Question 15

What happens when CommandType = 46?

Answer 15

Route by DNIS — calls USConfigurationByDNIS Lambda (bdp-wizeconnect-lambda-USConfigurationByDNIS-prod-01-v2) → Sets 11 attributes: AccountId | AccountName | Region | DirectToQueueArn | DirectToQueueName | and more → Checks ExperienceType.

Question 16

What 11 attributes come from USConfigurationByDNIS?

Answer 16

AccountId | AccountName | Region | DirectToQueueArn | DirectToQueueName | ExperienceType | NonIvaCategory | Language | Culture | plus 2 more. These tell the module who the client is and how to route.

Question 17

What happens after USConfigurationByDNIS when ExperienceType = IVA?

Answer 17

Set AccountId → Set Next_Module_Step and PathLog → EndFlowModuleExecution. The module returns to the landing flow which will then route the call into the IVA module loop instead. The call initially came in as Non-IVA but the DNIS lookup says it should actually be IVA.

Question 18

What happens after USConfigurationByDNIS when ExperienceType is NOT IVA?

Answer 18

Check NonIvaCategory. IF LanguageSelection → check Language attribute and assign queue. DEFAULT → assign queue directly. Either way | the module sets Queue and QueueName attributes for downstream use.

Question 19

How does language-based queue assignment work?

Answer 19

Compares $.Attributes.Language against 4 options: en-US | en-CA | es-US | fr-CA. Each language maps to a different queue and queue name. After setting Queue and QueueName | the module returns to the landing flow which handles the actual transfer.

Question 20

What happens on Non_IVA_Router_ValidatePhone TaskName?

Answer 20

Second phase of the module. Check CommandType: -1 (skip) | 150 (unknown path) | 46 (route by DNIS again — calls USConfigurationByDNIS | sets 11 attrs | checks ExperienceType). If IVA → set PhoneNumber | UserANI | TaskName | AccountId. This phase re-validates after phone collection.

Question 21

What is the key difference between CommandType 46 in Initialize vs ValidatePhone?

Answer 21

In Initialize: if ExperienceType = IVA it sets Next_Module_Step and PathLog then returns (routing decision only). In ValidatePhone: if ExperienceType = IVA it sets PhoneNumber | UserANI | TaskName | and AccountId (carries the validated phone data forward into the IVA path).

Question 22

What are all the ways the US Non-IVA Router can terminate?

Answer 22

1) EndFlowModuleExecution — the normal exit. Returns to landing flow. Happens at the end of DEFAULT | CommandType -1 | successful phone validation | and queue assignment. 2) DisconnectParticipant — only on retry failure (3 failed phone attempts). This is the only module path that kills the call.

Question 23

Does the US Non-IVA Router set any event hooks?

Answer 23

No. Zero event hooks. It only sets contact attributes (phone number | account info | queue | language) and returns to the landing flow. Event hooks like AgentHold | CustomerQueue | DefaultAgentUI | and DisconnectAgentUI are handled by other modules further downstream in the loop.

Question 24

Does the US Non-IVA Router transfer to a queue?

Answer 24

No. It sets Queue and QueueName as attributes but does NOT transfer. The actual Transfer to Queue happens in a different module downstream. This is the key architectural difference from the UK Non-IVA flow which handles the transfer itself.

Question 25

What is the complete flow for a typical Non-IVA US call through this module?

Answer 25

1) Landing flow invokes module with DEFAULT TaskName → module fetches user by ANI | sets phone/user attrs | returns. 2) Landing flow re-invokes with Initialize TaskName → module gets CommandType 24 | collects phone via Lex | validates | returns. 3) Landing flow re-invokes with ValidatePhone TaskName → module routes by DNIS | sets queue | returns. 4) Landing flow continues loop with other modules that handle hooks and transfer.

Question 26

What are the Lex bots used in this module?

Answer 26

Two Lex bot interactions: 1) Phone number collection bot — captures the caller's insured device phone number via voice or DTMF. 2) Yes/No confirmation bot — used during retry to confirm the number with the caller. Both are referenced dynamically from attributes set by the landing flow.

Question 27

How does this module compare to the UK Non-IVA flow?

Answer 27

US module: 44 blocks | returns to landing flow | handles phone validation + language + queue assignment | no event hooks | no transfer. UK flow: 58 blocks | standalone | handles config + recording + HOO + GDPR + holidays + hooks + disposition + transfer + disconnect. UK does everything | US does one piece.