Dear friends, colleagues,
today I was struck with something I just couldn't get my head around.
My client is using a classic Power Virtual Agent topic that collects some data from the customer before transferring the chat to an agent. One of the questions is about an 'EAN code', where the user is supposed to enter his EAN-18 code (yes, 18 characters long).
The variable is defined as a Number, requested and for testing purposes, directly put out to the chat again. So, there is nog intelligence in between input and output.
Yet, as the screenshot shows, number 123456789123456788 is directly scrambled to 123456789123456992. (sorry for the dutch version of the bot, I hope you'll get the big picture)
What? Why? How? Any idea?
The variable was setup as a number because customers tend to enter their life stories, ending with the EAN-code. The number functionality extracts the data we're looking for.
When changing it to a string, the scrambling of the number does not take place. It seems as if PVA has trouble coping with numbers this size.
Any idea what I'm overlooking here?
Thanks for thinking along.
Best regards,
Jeroen
Hi @jonckhje,
It just validates the input and checks if that input matches your regex. If it doesn't it will the ask the question again. If it does, it will return the whole inputted value in the Message action (since we are saving the entire user response in a variable).
Below are a couple of tests to demonstrate.
That's an amazing approach, thanks for your extensive walkthrough!
One more question (I'm sorry, risking to be too greedy). With this approach, user can input everything he wants, as long as there is a 18 character long number in it, right?
Now, the input could also be an EAN 13, for example (that I can manage in regex of course), but also something like "I don't know, it might be 123456789123456789 but can also be my brothers ean 1234567891234".
Using the build-in number entity, pva will extract both numbers and present them as a choice. Could we still do this using your approach?
Hi @jonckhje,
Yes, it seems to be related to the Number entity. I can reproduce your issue.
As a workaround I would suggest to create your own custom entity with a regular expression, https://learn.microsoft.com/en-gb/microsoft-copilot-studio/advanced-entities-slot-filling#regular-expression-regex-entities
You could use this regex in a custom EAN Codes custom entity
(.*)(\d{18})(.*)
Below is a test with that custom entity
Michael E. Gernaey
169
Super User 2025 Season 2
Romain The Low-Code...
150
sandeep_angara
75
Super User 2025 Season 2