So we've the ubiquitous Pardot challenge of how to approach two distinct Salesforce Contacts using the same email address. As we know Pardot sync's on the last active (or even random) and therefore a Pardot Prospect could be synced with the incorrect Salesforce Contact.
Clearly, utopia would be for Pardot to look at First Name, Last Name and Email Address as a first stop in its logic to help identify the correct Contact. That, however, doesn't even appear to be on the roadmap. Has anyone here used a super-smart and creative way to address this challenge? eg:
Contact 1. Jane Smith using email admin#company.com
Contact 2. John Johnson using email admin#company.com
Jane submits a Pardot form using her name and details, including the email admin#company.com
John has the last activity in Salesforce. The logic therefore sync's Jane's Pardot form submission with John's Salesforce Contact.
... and all of the sudden we're up the proverbial creek!
I suspect, since this issue is so pervasive, someone must have a creative solution. At least I'm hoping :)
Thanks! Ten
An API approach could look something like this:
You would have to have a service sitting somewhere that your form would POST to (not Pardot)
Create a Form Handler that will be used for honestly the vast majority of use cases (by your service)
Use Pardot API to Read Prospects by email
If none found, POST to a Form Handler then do a new Read by email (to get the Prospect ID)
If 1 prospect is found, POST to the Form Handler (Pardot will pick the right one here!)
If more than 1 is found, use Pardot API to update the correct Prospect
Associate the visitor to the Prospect via IDs (if you can capture the Visitor ID as part of the POST request to your service
A slight variation would be to redirect the "form submitter"'s browser to the Form Handler URLs if there isn't already multiple prospects for that email.
I think I prefer the service handling all the Pardot stuff asynchronously, just have the Service validate the form submission and send the visitor on their way as quick as possible, and do the Pardot API stuff when it can. It will depend on your service and how much you want to put into it.
Related
I have a cakePHP community. User are able to signup and login. I like to create a survey using SurveyMonkey.
Therefor I create the survey and make it available to my members using the direct URL. In my member database I have to save the information "did completed the survey = yes/no".
Is there any way to identify the user filling in the survey and write this information into the database?
SurveyMonkey has an API https://developer.surveymonkey.com/ , that let you collect info from your survey (completedf or not).
This is the only way i think, (if it s not include in your website).
I know that you can simply do this with Examinare Survey Tool. What you do first is that you use the API inside Examinare to add a recipient for all the users in the survey base.
Use the PHP Wrapper library in their developer site.
Loop it through and use the https://developer.examinare.com/php-wrapper-library/ and use the example code.
If you let people register with same email more than 1 time then save the ContactID into your database on the recipient.
Then to not create an email invite you use this : markrecipientstosurvey
The surveyID is available inside the Examinare account.
When you done this script part then make it as a cronjob for instance inside the crontab -e
I would run it every 30 minutes or 1 per hour.
Next part you create a page for the survey redirect where you use the function: listsurveysbyuser
to get the survey version and url
(there is a special link for the mobile user that even works for the normal mobile phone NOT only smartphones)
Now you just redirect them to the survey. If you want them to return to your site after then you use the redirect_url parameter that is added to the url or use the redirect inside your account. Ask support about that if you need :) They are fast... Never had to wait more than a couple of minutes.
When the person return then just check if they are marked as complete with the same api call: listsurveysbyuser
Looks much but it is very easy to implement and if you have any problems then just ask the support at support#examinare.com I have asked alot and never had them to say that it can not be done. Really nice!
EDIT:
I see that they just released a tutorial much better than my example:
https://developer.examinare.com/how-to-use-surveys-in-cakephp-with-very-little-development/
One option:
Use unique Custom Variables in the URL that is visited by each member of the community
For example, https://www.surveymonkey.com/s/your_survey?userid=$my_user_id
Note that you can create weblink or email collectors with the API (endpoints: create_flow or create_collector).
Then track the responses using the get_respondent_list or get_responses endpoints of the API.
Note: Please confirm with the Survey Monkey API team that the custom variables can be read via the API.
Another option:
Use the email collector (create_flow) API endpoint and send it to your members' email addresses.
I'd like to create visualforce page that inserts a record into salesforce account object. However, I expect some of the page users won't have salesforce accounts. Can they still access it? If not, what are the alternatives that can be used to visualforce page in this case? (Please don't consider Web to Lead Forms).
Thanks,
Yes, it's possible. Go read about Salesforce Sites. For a start:
http://wiki.developerforce.com/page/Websites
http://wiki.developerforce.com/page/An_Introduction_to_Force.com_Sites
(of course it's also possible to write that page in say Java/.NET/PHP and use integration via SOAP or REST to talk to Salesforce... but these 2 main links will keep the whole solution within SF so no need to need to learn new language, have extra maintenance effort etc)
Sites are VF pages that expose a bit of your company's data without need to log in. You can use them to input data too, just remember that in theory anybody could learn the link and spam you (not too different from web2lead, inbound email handlers etc). You specify security in a way similar to Profiles, the records will have "Created By = {site name} Guest User".
I don't think there's anything out of the box to restrict visibility, they're open to whole world. So if you would want something similar to login IP ranges (so only sales reps from your office's network can enter data) - you might have to write some logic in the controller.
The scenario is that users of web application can purchase digital items. The web application will use Paypal Instant Payment Notification.
The IPN protocol consists of three steps:
PayPal sends your IPN listener a message that notifies you of the event
Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent.
Let's say it's VERIFIED, how could I know who have completed the transaction or purchased the item (user of the web application) if the user used other email address in his/her paypal? I have stored the email address of the user in session but what if he/she have different paypal email? Paypal email is included in IPN message.
For other details, maybe not useful, the application is written in Struts2 in Google-App-Engine.
You'll need a way to correlate the IPN data coming back with the user. Either by asking them to provide their paypal email or using the username/password generation facility in the IPN service. Here is a somewhat inelegant but functional approach:
When the IPN comes in off the wire, persist the paypal generated username/password and payer_id (in perhaps the datastore).
If you can't correlate by email, then when the user comes back to your site request that they enter the username/password generated from paypal's site once (just to correlate).
Lookup the username/password and then correlate their userid from the UserService back to the payerid.
The reason to use IPN is for subscription services as you can get IPN messages when the subscription is terminated, cancelled, or when payments come in (for an account that stopped paying).
The most important thing to think about is how to correlate a user of your site back to the payer_id (or even payer_ids in some cases) that are used to pay for the services they are using.
On another note, I wouldn't use the session to store information for IPN callbacks, those actually can take a LONG time sometimes (say when the x.com conference is on and everyone is hammering paypal).
If you have a running application or a better description of the look & feel, I might be able to come up with a more elegant suggestion. Let me know if this helps at all.
Why don't you use PayPal's express checkout? This way you negotiate server2server a token and then you can check with PayPal the result of that token on user's return.
If users are buying directly from your application it's easier to implement.
And I think it'is more robust than the method you're using (I never heard of it before :D )
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
I a new programmer and trying to implement a facebook type "feed" in my application. Like Whenever a user do some changes in his profile his linked profiles will get to know that in the form of news feed.
But I am stuck on that as I thought whenever any user saves any data (like "News", "Blog", "Event" or any "Comment") just send the id of the respective classes to the linked profiles and they will see it. Since the id is not generated before the object is saved , the problem is how can I send them. I thought of following workarounds but each have some problem.
Whenever a user posts a news .... a Post object will be made and added to User's Post Collection.
But How do the other users will knew about it.....
1) Send them the id .... but when the id is not created how can you send them the id.
2) Send them the post message and when ever they will click them ... the latest post to them from the particular user will be shown.. but if more than 3 messages then which will be shown?? Shown by the post creation Date no post greater than that date is shownn....but he needs to be shown newer posts..
3) Save the post in all followers feed. the data will be much larger then
4) all the followers on login will check all the persons they are following and save their feed after the time stamp? How to implement this as the Post is saved in User's Profile so I would have to check all the following person and then just check the feed and show them on his feed box; I think I would have to use batch Processes. Processing will take much longer.
I am using objectify-appengine to do operations on GAE.
Any help is appreciated
Are you wanting to update the page with posts in real time like on Facebook and Twitter? To achieve this on Google App Engine you can use the Channel API, which works in conjunction with Javascript to listen for new data and update the DOM.
This talk at Google I/O 2009 by Brett Slatkin describes exactly the pattern you should use for this.