Dialogflow ES has an event called 'WELCOME' which makes it possible for the bot to initiate the conversation.
How can I do the same in Dialogflow CX?
There is no entry fulfillment option in the Start Page of Dialogflow CX.
Edit:
Delete the 'Default Welcome Intent' route.
I am unable to perform this. I get the following error.
In 'Default Welcome Intent' change the intent from 'WELCOME' to nothing.
I get the following error. I have set the condition to true. I have also set the page transition to 'onboarding' page.
Please let me know if more screenshots are required.
To accomplish what you're asking, the easiest way would be to:
Open the "Default Start Flow" and select its Start page.
Remove all routes and add a new one.
This new route takes a "custom condition" in the form of true (in the condition pane, click on customize expression and then just type true) and goes to a new page
called "Onboarding" (on the bottom of the route creation page, click on new page and name it Onboarding).
Go to the Onboarding page and add an entry fulfilment "Hello there, how are you doing today?"
in this way every time the default start flow is activated (window is opened) the bot will use that fulfilment.
EDIT:
ok, i tried creating a new agent and i think i solved the problem.
it seems as though we can't erase the default welcome intent, but it doesn't matter.
i created two pages: onboarding and first page. from start i added an always true route to the onboarding page, and i did the same with the onboarding and first page. As you can see from the testing console we only get the expected behaviour for the second transition, look at this:
start page:
onboarding page:
"first" page:
After looking for info on the documentation i think i understood this: from the testing console, google doesn't let you see the actual behaviour of the conversation. If you see the screenshots, when i say "hi" and go the the onboarding page, i get immediately brought to the next page by that "true" transition. Since the same exact sequence is on the start page, the same behaviour should apply there: you only can't see it in the console because "opening the window" in the console is not the same as opening the conversation "in real life".
So, what i suggest you to do is create a new integration or develop a testing environment for the bot, say a website with the messenger integration, a telephony integration or whatever else, and test this onboarding on there. Speaking from personal experience, try with the messenger one maybe: you get a link and you just embed the script in any webpage (works well and easy).
It should work, as in, as soon as you open the conversation, the bot should go the onboarding page and say "hello there!"
So, I'm not sure what your end use-case is, but DFCX (at it's core) isn't exactly designed to initiate an unsolicited message because it's really just a language model with a bunch of features built on top of it.
With that being said, if you want to create a pop-up window for your website chat-widget, you can actually configure this in the integration settings with your embed code. Here's an example:
//The DF Messenger element:
<df-messenger df-cx="true" chat-title="Agent Name" agent-id="<your agent ID>" language-code="en" expand="true"></df-messenger>
//The window load script :
<script src="https://www.gstatic.com/dialogflow-console/fast/messenger-cx/bootstrap.js?v=1"></script><script>
window.addEventListener('dfMessengerLoaded', function (event) {
const dfMessenger = document.querySelector('df-messenger');
const openText = ('<The Text You Want To Display On Page Load>');
dfMessenger.renderCustomText(openText);
});
</script>
Please note this will only work if you have the DF Messenger Integration enabled on your agent. See the docs for integrating DF Messenger here
1.Use the attribute intent inside the df-messenger tag in your UI/HTML page
2.Then create a Custom Event in Dialogflow CX (By clicking on Event handler '+' icon)
3.Check the 'use custom event' checkbox and provide event name and provide a text response in fulfillment section of this custom event.
4.Finally provide this custom event name as value to the attribute intent(mentioned in step 1)
please refer to this document for df-messenger HTML customizations https://cloud.google.com/dialogflow/cx/docs/concept/integration/dialogflow-messenger#html-customize
According to Dialogflow CX documentation, the WELCOME event (although not visible in the Start flow) is also available. As you can see in this link and the picture below.
To invoke this event, you have to use the detectIntent method of a Session client. You'll need to specify the event name in queryInput.event.event of the request used in detectIntent.
Hope this helps!
For 2 days now, my APEX is timing out every 10 minutes or less and it makes me lose my work!
I've tried to clean browser cookies and all...
Timeout is set in application's Shared components, Security Attributes, Session Management section.
"Maximum Session Length" is measured in seconds. If unset, it defaults to 43200 seconds (which is 12 hours) (for Apex 19.1) so ... check what it is currently set to.
I think that what you are facing is that your killing your previous sessions.
Every time you log in on an APEX application, it generates a session for your user (it's the random numbers in your URL)
If you have another browser tab opened and you request another log-in on the application, then another session is generated and if you go back to the other tab and try anything there, you will be asked to log-in again and if you do, the other session that you just logged-in will be killed.
For each application you log-in, is generated a session id that is saved on cookies of your browser. So just make sure that there's no other window or tab opened of that application already on the same session of your browser (although you can use different browser or incognito mode).
Also, pay attention in any favorite links that you made that links an APEX application. The same thing will happen if you are already logged-in and click on the favorite link that has a session on its URL.
This all can be avoided if you configure "Rejoin Sessions" parameter on the APEX installation enviroment: https://docs.oracle.com/cd/E59726_01/doc.50/e39151/adm_wrkspc002.htm#BABJCGAG
I need to book an appointment on a website. These appointments are released sporadically and booked up quickly. To even see available appointment times, you have to login & complete a reCaptcha. If I wanted to write a scraper using Headless Chrome to continually scrape the site and notify me when a new appointment comes up, following the login flow each time would require beating the reCaptcha, which is at least non-zero difficult.
A better approach (I thought) would be to log in once manually, grab my session cookies, and then load them into Headless Chrome before making a request directly to the appointment times page. The server would see my request, see my session cookies, and respond as if the manually-logged in session had been refreshed. This is pretty much as outlined in the answer to this StackOverflow question: how to manage log in session through headless chrome?
But this doesn't work, and I can't figure out why. I get redirected every time straight back to the login page. I've tried on Chrome & Firefox, and with several other login-requiring websites (Facebook, Reddit, etc.).
How can these servers possibly discern between the original client and the one using copied cookies, when the cookies are what the servers use to identify clients in the first place?
Exact steps to reproduce:
Login to site of your choice on Chrome, let's say Facebook.
Export your cookies to your clipboard from the site using the EditThisCookie Extension
Launch an incognito window (to reset your active cookies) and import those session cookies with the same handy extension.
Navigate to the target, past-the-login-form url.
Get redirected.
Get frustrated.
I've seen a similar question asked a few times, but usually it is from people trying to find out which Page is currently accessing their Tab app. (Which you can do by inspecting the signed_request.)
I'm trying to build a UI that will show the user all the Pages that he/she is an Admin of, and then display which of those Pages have my Tab app already installed. I'd like to make a FB graph API call to either a) get the list of Pages that have my Tab app installed or b) get a yes/no answer for whether a particular Page has it installed. Is this possible?
As a fallback, I will make a table in my database to track Page IDs whenever a Page views my Tab (using the aforementioned signed_request) but this won't be as good, because it won't know when someone has uninstalled the Tab from a Page.
To be complete (for future readers): this does not require manage_pages. You can also use the FB app's token. Also see: Check if page tab app is still installed
In the general case, 'no', without keeping track on your side via the signed_request but if you're already obtaining manage_pages access from the user it's pretty trivial to check if a particular app (i.e, yours) is installed on the page
See the page documentation for details, relevant part:
You can test if a specific app is installed on a page profile tab by issuing an
HTTP GET to PAGE_ID/tabs/APP_ID. If the app is installed, this will return the
following fields:
(you'll need the page access token from the user's /accounts connection for that call
We have an ASP.NET application that uses Forms Auth. When users log in, a session ID cookie and a Forms Auth ticket (stored as a cookie) are generated. These are session cookies, not permanent cookies. It is intentional and desirable that when the browser closes, the user is effectively logged out.
Once a user logs in, a new window is popped up using window.open('location here');. The page that is opened is effectively the workspace the user works in throughout the rest of their session. From this page, other pop-ups are also used.
Lately, we've had a number of customers (all using latest versions of IE8) complaining that the when they log in, the initial pop-up takes them back to the log in screen rather than their homepage. Alternately, users can sometimes log in, get to the homepage (which again, is in a new pop up window), and it all seems fine, until any additional pop-ups are created, where it starts redirecting them to the log in screen again.
In attempting to troubleshoot the issue, I've used good old Fiddler. When the problem starts manifesting, I've noticed that the browser is not sending up the ASP.NET session ID session cookie OR the Forms Auth ticket session cookie, even though the response to the log in POST clearly pushes down those cookies.
What's more strange is if I CTRL+N to open a new window from the popped-up window that is missing the session cookies, then manually type in the URL to the home page, those cookies magically appear again. However, subsequent window.open(); calls will continue to be broken, not sending the session cookies and taking the user to the log in screen.
It's important to note that sometimes, for seemingly no good reason, those same users can suddenly log in and work normally for a while, then it goes back to broken.
Now, I've ensured that there are no browser add-ons, plug-ins, toolbars, etc. are running. I've added our site as a trusted site and dropped the security settings to Low, I've modified the Cookie Privacy policy to "accept all" and even disabled automatic policy settings, manually forcing it to accept everything and include session cookies. Nothing appears to affect it.
Also note the web application resides on a single server. There is no load balancing, web gardens, server farms, clusters, etc. The server does reside behind an ISA server, but other than that it's pretty straight forward.
I've been searching around for days and haven't found anything actionable. Heck, sometimes I can't even reproduce it reliably. I have found a few references to people having this same problem, but they seem to be referencing an issue that was allegedly fixed in a beta or RC release (example: IE8 loses cookies when opening a new window after a redirect). These are release versions of IE, with up-to-date patches.
I'm aware that I can try to set permanent cookies instead of session cookies. However, this has drastic security implications for our application.
Update
It seems that the problem automagically goes away when the user is added as a Local Administrator on the machine. Only time will tell if this change permanently (and positively) affects this problem.
Time to bust out ProcMon and see if there is a resource access problem.
Update #2
It seems there are multiple angles to what appears to be a singular problem. I reported long ago that making the user a local administrator seemed to help. And it did, for a number of users. Of course, that's not really a solution, but it did let us hobble along.
Then more users started reporting the issue, and the admin fix was not helping. The users seemed to be mostly Win7, but Vista was also affected. They also seemed to mostly be 64-bit installations.
Setting the TabProcGrowth to 0 or 1 (either worked) as suggested by some members below seems to have largely addressed the issue. So, I'm going to move my accepted answer to the first person that suggested that, as it has had significantly more impact.
This has been an incredibly frustrating issue to attempt to solve, since it is difficult to reproduce and often occurs with users that I do not have direct communication with, or by the time I get to them it doesn't appear to be working. All I can say is something is not right with the session merging feature, but I don't have much data to feed to Microsoft to find a permanent fix.
This is 'new' functionality in IE8!
Checkj out the IE8 blog below to read about it.
http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx
IE8 can use multiple processes for handling an x number of IE windows. When you cross a process space, you loose your cookies (Asp.Net session ID seems to be retained over this process boundry).
I personally think it's broken or a bug. As we know, when browing to the 'same domain target' cookies should be maintained and resent. That IE8 has different processing behavior for security.. Great! that it is behaving badly and 'drops cookies even if going to the same target domain in another window' is just a bug in my view.
You can modify the number of processes IE8 uses through the internet explorer options ehh.. modifying a registry setting!!!!!! (this is what makes it a bug in my view. IE providing a UI to modify these settings would make it 'enterprise level acceptable'.
Regard,
Marvin Smit
There are multiple possibilities behind this -
UAC & Vista (Had to crop up!!). Specifically, look for protected mode behavior.
This could be an actual problem with the Session Merging feature in IE8. More so because opening a new window via the Ctrl+N shortcut causes the cookies to be magically sent in your case.
An issue with an older build of IE (I know you have stated that your customers are using the latest build). You might want to check the details available at Microsoft Connect for bug IDs 408806 and 392032.
We solved this problem by changing the "Set tab process growth" to 0.
Although, we didn't have protected mode turned on and the zone was "Intranet". Evidently this is a problem/bug with Windows 7 64Bit as others have stated.
This page (#4) lead me to the solution: http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/
Near as I can tell, another change to cookies across tabs just went live in this security update from November 12, 2013 that is breaking functionality in our app in all versions of IE. We're doing OpenID auth in a popup window so as to not have to redirect the user away from the page they were browsing when they first clicked the Login link. The session cookie for the login is correctly being sent down in the request in the popup window, but it never gets seen by the main browser window, so the next request to the server doesn't have that session cookie on it like it should, and thus logging in never actually works.
Does anyone have any possible solutions to this?
We had this problem on IE6,7 and 8 .The scenario is parent window(1) opens a modal window(2),modal window has a link to a non-modal window (3). I used to get a different session Id in the 3rd window.
Workaround mentioned here fixed the issue http://support.microsoft.com/kb/831678
Since IE8 we (and our customers) are also experiencing the same issue. We have an asp service for creating forms. This application uses new windows for adding elements or managing user accounts e.g. Randomly (when opening a new window), the application doesn't get the required session id for authentication allong with other 'permanent' cookies. Hence, the session id is a temporary cookie. Most of the time it goes well, but other times the session is broken every time a new window is opened. We have to advise our customers to close all IE windows and start over again.
As a web developer I use IE extensively. Personally, I am not experiencing the above issue. But I think a related one. A few times a day IE totally hangs (does not respond anymore) when opening a new window. When I kill a certain IE process using the task manager, IE starts responding again. But in most cases it's better to start all over with a clean new instance of IE. For this reason I just kill the process with the least ram usage which causes all IE processes to quit.
Microsoft saying these issues/bugs are squashed in the final version does not give me trust of their effort solving the issue still be experienced.
I also found a workable fix for this problem. There seems to be a problem with how IE8 handles opening servlets in another window with a relative path such as /test. It seems to be opening a new session as well as a new window. Our workable fix is that instead of opening a new window with a relative path, we just used a jsp page. So when we navigate to a URL, we do not navigate to /test anymore.We navigate to a specific file. In the jsp file, we forward the request to the relative path. This seems to work, which is kind of awkward, since the only difference is that we are placing a specific file in between.
I hope this helps.
I know this problem since IE 5, so I only use session's variables in modal pop-up windows...
When I open a non-modal pop-up window, I replace all session's variables with ASP.NET cache and new object collections...
But it's very tiresome!
Other browsers (i.e. Firefox) don't have this problem...
I believe this is actually a bug in IE; I have reported it here to see what feedback I get: http://social.msdn.microsoft.com/Forums/en-US/83bb3b91-1c1f-4d51-9281-9bc5f51d3640/log-in-fails-cookie-is-not-sent-to-originating-tab?forum=iewebdevelopment
I have a similar, though not identical problem. We load a webpage that opens a popup with window.open() into an IE browser control. On machines that have either IE6 and IE8, the popup window is always assigned a new SessionID by ASP when launched from the control. However, when launched from a normal browser (IE or Firefox), the popup window gets the existing SessionID.
I can see when launching from the control that a new iexplore.exe process is spawned; thus the session loss behavior makes sense given what has been mentioned about in-memory cookies not being carried over to the new process.
I'm still trying to figure out a workaround myself ...
Update
Figured out a workable fix! It is possible to subclass SessionIDManager and specify that this class should be used instead of the default (<sessionState sessionIDManagerType="..."> in Web.config). The subclass can look for a query parameter containing the existing session id in an override of CreateSessionID(), and return it if found. This essentially allows a page to request being "merged" into an existing session it has knowledge of.
The call to window.open() then simply needs that query parameter specified in its URL.
Haw-Bin
Had a similar problem with PHP5 and IE8. When opening one certain popup window in Javascript with window.open, IE8 lost the session cookie and forced the user to login agan.
Meanwhile, other popup windows worked OK.
The culprit turned out to be an image tag. The template system generates image src = values dynamically and a missing image resulted in an image tag with an empty src clause (
I supect this has something to do with IE interpreting the empty src-tag as an insecure URL and isolating the session in the popup without informing the user.
I was running into a similar issue with using session variables to pass values to a pop-up window. I just ended up writing the values to a persistent cookie and then reading the cookie in the popup window. This may not work with the issue you were having with forms authentication, but if are just using session variables to pass some values to a window in IE8, persistent cookies seems to have worked for me.
edit: see also this thread
You Can Also Use the LocalStoprage method to reset the value in parent window.
localStorage("Key")="Value";//Javascript