I'm building a Dialogflow application which heavily depends on the location given by the user which may/may not be the current location of the user. So, I want to ignore the current location and go with location spelt by the user.
At the moment, I'm listing all the locations in one city, Dialogflow agent picks it up and determines the sub-domain area.
"location": {
"subadmin-area": "Chicago"
}
However,it'll be difficult to add each location as we expand the service to new areas.
Is there anyway for the agent to self learn the locations on a given area?
It won’t self-learn this. What I would do is find a database or some other locations dataset and write a script that uses the Dialogflow API to programmatically generate entities with location names.
Or better yet, use the system-provided entities that Google has already created. See the Geography section at https://dialogflow.com/docs/reference/system-entities
Related
when a new client is added I want to verify if the newly added client's details are correct.
For example,
Create a new client, after creation search his name and check if the details are correct or not.
Should I include them both in the same feature, or should I create a different feature for both adding and searching clients
Feature: Creating a new Client
The user is
Able to add a new Client
Scenario: Valid client entry.The client has a username,address
Given User is on the client page
When When he clicks on the add new client
Then He should see a pop up
Then He will enter the client name,address,title,phone no and email
And Click on the save button
Feature: Search for our newly added user
The user will be able to search a client
Scenario: Search for our newly added client
Given User is on the client page
When He click on the client search
And Types the user name
Then He should be able to match the first result
When He clicks on the first matched result
Then It will take him to a page with users details
It would be better to keep them separate. The strategy that worked best for me in many projects are, you should map each feature to the requirement (i.e. the high level user story or the requirement that is given to you from which you derive BDD scenarios and steps). Keeping each high level requirements in a separate feature files increases readability and maintainability.
In this case, looks like "Creating a new client" and "Search for our newly added client" are two different requirements/user stories, it is better to manage them separately, as the scenarios in each of these cases would vary. For an example, "Creating a new client" might have following scenarios:
Scenario 1: Create a valid client entry.The client has a username,address
Scenario 2: Creating a valid client entry failed due to missing information
Scenario 3: Creating a valid client entry failed due to client already exists
And for "Search for our newly added client" you would have other scenarios like:
Scenario 1: Search for a newly added user using username and search result should show the user details
Scenario 2: Search for a user using username who is not in the database and empty search result should be shown
Scenario 3: Search for a newly added user using address details and search result should show the user details
Scenario 4: Search for a user using username using address details who is not in the database and empty search result should be shown
As you can see, each feature is now nicely segregated and have their own related scenarios. As the project grows these scenarios are likely to grow and it would be easier to manage by keeping each high level requirements in a separate feature file.
Also another practice that really worked well for me is to prefix the Jira ticket(or whichever tool you use to manage your user stories) to the feature file as it would be easy to search and manage. For an example, your feature should be like "TI1001 - Creating a new Client" and "TI1002 - Search for our newly added user"
There are lots of ways to do this
features
clients
add_new_client
search_for_clients
I'd favour this one if clients are a really significant part of the
project
features
client_add
client_search
but this one would work.
The important thing is to try and be consistent.
As for your scenarios try and make them simpler e.g.
Feature: Add new clients
Background:
Given I am allowed to add clients
Scenario: Add a client
Given there are no clients
When I add a client
Then there should be a client
You want your happy path scenarios to be this simple, so you can expand on them with sad paths. e.g.
Scenario: Add a new client without an address
Given there are no clients
When I add a client with no address
Then I should see that a client cannot be added without an address
As far as searching goes things can get quite complex so again start simple
Feature: Search for clients
Scenario: Search for client Fred
Given there is a client Fred
When I search clients for Fred
Then I should see client Fred
Scenario: Search for client Fred when Fred does not exist
Given there is a client Sue
And there is not a client Fred
When I search for Fred
Then I should see a not found result
Scenario: Search for clients by postcode
Scenario: ...
With searching you need to be careful not to spend all your time testing your search engine (it should already be well tested.
These sort of features and scenarios are declarative, rather than imperative. They state WHAT they are doing and WHY, but avoid describing HOW anything is done. Cuking is much more effective with a declarative approach.
I am currently working on a dialogflow app for my company. I need to get our app to be able to take any name given by the user and match it to the database.
We manufacture CNC machines and we are attempting to create an application that allows the user to obtain information about their machine using their phone or google home. We have a website that allows them to give their machine a name. This name could be anything. It could be "Zodiac", or it could be "ZMachine #123". This name is stored in the database and is used to reference the machine from the dialogflow app. However, when google parses the voice input, and I get that entity in the fulfilment, I end up with "z machine number 123" or something like that, which I cannot match to the database directly. This is especially true for names that are not standard English words or names, such as a company name or something like that.
I was wondering if anyone had any resources that could point me in the right direction? I noticed that when you name smart devices in google, you can name them anything you like and it still gets it right. What are they doing in the background that allows this to take place?
I am trying to wrap my head around using Dialogflow for developing and integrating an SMS chatbot with our custom CRM. The creation of an Intent is pretty powerful and straight forward. However, I am trying to understand best practices for something. If I have an intent used to return the price of a service at a certain location, I can model that very easily within dialog flow. However, when an SMS message comes in, it will be from a new customer or a known existing customer for a certain location. For existing customers, we already know the location and therefore don't want them to have to specify the location value in the intent. Prior to sending the inbound SMS message to the client API to match the intent, how can I pre-set the "location" parameter value in the intent so it does exists even if that inbound SMS message did not include it? For example a known customer in Dallas would just have to say "how much is a xxx" instead of "how much is a xxx in Dallas".
Can you use the API to set a parameter value prior to calling the API to try and match the intent? If so, how do you get do that without a session ID? The reason the "location" is needed is because when we get to the fulfillment, the prices for the same service are different based on the location so I will need to be known but we don't want to make existing customers say the location.
Maybe another option is to have a Location intent with an event that we can trigger through the API. this would have an output context on it called location and fulfillment that sets the parameter value. But even then I struggle with understanding how to pass in values like location, phone number, etc into dialogflow from the calling application so dialogflow has those parameter values to use in fulfillment.
Reading documentation, watching videos and starting to test client API v2
This is certainly possible. What you would want to do is use the Dialogflow API for this. Here you can find the languages for which Google has created client libraries: https://cloud.google.com/dialogflow/docs/reference/libraries/overview
As soon as you have any 'if' in your code you should use the fulfillment: https://dialogflow.com/docs/fulfillment
How I would handle this:
Client sends SMS
You check in your back-end if this user is known. If known -> don't ask location, else you ask the location
Match the user query against the Dialogflow client library
Dialogflow will return the intent if (any) is matched
You should define and implement any logic before calling the Dialogflow library.
We have an application in which we will be collecting addresses from users. In the current implementation, we are using a live agent to do this. Some users, when prompted for a final billing address, will say things like "Just use my billing address" or "same as my current address". THe new implementation will be a chatbot to try and fulfill some of these requests before they get to an agent.
We do have this information available via API lookup, I am asking more from a design perspective how to let our handler app (usually an AWS lambda) know that we need to do the lookup before we prompt to confirm fulfillment.
A few things I thought of:
Train the NLP to detect strings "current address" and "billing address" as Address entities
Create a new intent for utterances like these and handle them separately
Create a new entity type in the current intent (eg, not postalAddress) for utterances like these and handle them as part of the same fulfillment
Simply re-prompting the user, or asking them to state what their address is
I am just looking for the most pragmatic approach here, as this problem is different from most others we've solved.
I had a similar use case, and after investigation found that option 3 is the easiest way to handle this.
You can add a validation hook that fires when the new slot is populated. This hook can populate the value of the postalAddress slot with the associated address. This way you can keep the postalAddress slot as a required slot, without having the user manually state the address.
You can also have this validation hook fire on the population of postalAddress and add some manual testing for billing and current, but this felt to me like a manual work around for something that should be automated by Lex.
We're using Azure AD for Authentication on a new Azure app. I have a requirement to add a few supplemental pieces of information to the user information.
Normally, I'd like to use an Open Type Extension on each user, something like this:
{
"#odata.type": "microsoft.graph.openTypeExtension",
"extensionName": "org.test.example",
"Region": "HQ",
"Companies": ["1022", "1023", "1145"],
}
But, according to this SO question, adding open type extensions for multiple users is broken and can't currently be used this way.
I tried to use the Responsibilities property, but found out today that I can't use it without a SharePoint license associated with our Azure instance.
So my question is, which User property can I use for this without adding extra licenses? I'm not opposed to putting all the values in one array (that's what we planned to do with Responsibilities), but I'd really like to avoid having to make a round trip to a database to pull this information when each user logs in.
The issue mentioned in How do you create MS Graph open extensions with the same id on multiple users? is fixed and in the process of being deployed. I will update once it is available (mostly mid next week).