Genesys Cloud - Developer Community!

Unexpected Behavior with Phone Number Slot Formatting in Genesys Dialogue Engine Bots

We've run into an unusual behavior with the Genesys Dialogue Engine bots and wanted to check if others have seen the same.

We created a numeric slot (builtin) and tagged it in an intent designed to collect phone numbers. For example, the utterance: "My phone number is 1234567890."

When the bot uses Ask for Intent to collect the phone number, the response is automatically formatted as 123-456-7890. During confirmation, the bot only asks about the last four digits, which isn't ideal.

Interestingly, this doesn't happen with other numeric slots. For instance, when we use a 10‑digit numeric slot for account numbers, the formatting issue doesn't occur. It seems to be specific to slots tagged as phone numbers.

As a workaround, we're currently using the Ask Slot block for phone numbers, which avoids the formatting problem. But we'd like to know:

• Is this a known issue with phone number numeric built-in slots?
• Should we expect similar behavior with other 10‑digit numeric slots in the future?

Any insights or confirmation from the community would be really helpful

#Architect

------------------------------
Vinaya Mente
------------------------------

Hello Vinaya, 

The builtin Numeric Slot will accept any numeric input, so depending on how your user is entering this information, the system may accept fewer digits as valid inputs. To prevent that, I would recommend you using regex, if possible, like /b/d{10}/b or /b/d{3} /d{3} /d{4}/b. This would guarantee the 10 digits are captured. 

https://help.genesys.cloud/articles/use-custom-regular-expression-slot-types-in-a-bot-flow/

Regards,

Thanks for the suggestion on using regex - we are already applying regex to enforce the 10‑digit requirement for phone number. What we're trying to understand is why the same built‑in numeric slot behaves differently depending on the tag.

• When the slot is tagged for account numbers (10 digits), the bot accepts and confirms the number exactly as entered, with no formatting.
• When the slot is tagged for phone numbers (10 digits), the bot automatically reformats the input with dashes (e.g., 123‑456‑7890) and only confirms the last four digits.
• The caller speaks both the numbers in the same format (with pauses).

This difference in behavior is what we'd like to clarify. Is the formatting and partial confirmation logic hard‑coded specifically for numeric slots named as phone number? If so, it would be helpful to know whether similar formatting rules exist for other built‑in numeric slot types, so we can be confident that account numbers or other identifiers won't be affected in the future.

Hi Vinaya,

What you're seeing is most likely intentional behavior in the Genesys Cloud Dialogue Engine, specifically for values semantically interpreted as phone numbers.

Even though both cases use numeric input:

• account numbers are treated as generic identifiers
• phone numbers trigger additional telephony/PII handling

That is why you see behaviors such as:

• automatic formatting (123-456-7890)
• partial confirmation (last 4 digits only)

This appears to be tied more to the slot/entity interpretation than to the numeric length itself.

Important distinction

The behavior is not simply:

• "10 digits"

but rather:

• "10 digits recognized as a phone number context"

which activates normalization/privacy-friendly confirmation logic.

About future impact on other numeric slots

Based on current behavior, I would not expect:

• account numbers
• customer IDs
• generic numeric identifiers

to suddenly inherit the same formatting behavior unless they are explicitly interpreted/classified as phone-related entities.

Your workaround

Using:

• Ask Slot
• custom regex slots
• or treating the value as generic numeric text

is probably the safest approach when:

• exact formatting preservation is required
• full digit confirmation is mandatory

especially for authentication or validation scenarios.

My recommendation

If you need:

• deterministic capture
• exact replay/confirmation
• no automatic masking/formatting

I would avoid semantic "phone number" interpretation entirely and instead use:

• custom slot types
• regex-based validation
• or generic numeric/text collection.