Apex Code Development You need to sign in to do that
Don't have an account?
croberts47 Using Force.com Sites to collect outside information
Currently we have account managers who call our customers and collect certain information over the phone.
I would like to be able to send a link to a customer via email that would take them to a form on our public site where they can complete a form and that data would then be associated with an account record in salesforce.com.
is that possible?
Thanks
CR
Hi CR,
This is certainly possible, and sounds like an excellent idea for saving time and for getting more and better information about your customers. First set up Sites if you haven't already, then create a Visualforce Page with fields for customers to enter the requested information. One cool tip/trick off the top of my head would be to code the Page to accept the customer Id as a parameter in the URL (e.g. instead of http://mypage.force.com/, something like http://mypage.force.com?AccountId=00100000eh7KsB2). This way, the Page will know who is visiting and can personalize itself with something like "Welcome <Insert Account Name>. Please help us to serve you better by completing the following information." This technique will also allow the Page to know which Account/Lead/Contact record to update with the new information. Also recommend adding some sort of "Email Last Sent" field to the Account/Lead/Contact so that your Users don't inadvertently send multiple emails to the same customer in rapid succession.
Enjoy!
- Marc
All Answers
Hi,
Yes it is possible. Just configure your site, crate vf page and add it to site.
Hi CR,
This is certainly possible, and sounds like an excellent idea for saving time and for getting more and better information about your customers. First set up Sites if you haven't already, then create a Visualforce Page with fields for customers to enter the requested information. One cool tip/trick off the top of my head would be to code the Page to accept the customer Id as a parameter in the URL (e.g. instead of http://mypage.force.com/, something like http://mypage.force.com?AccountId=00100000eh7KsB2). This way, the Page will know who is visiting and can personalize itself with something like "Welcome <Insert Account Name>. Please help us to serve you better by completing the following information." This technique will also allow the Page to know which Account/Lead/Contact record to update with the new information. Also recommend adding some sort of "Email Last Sent" field to the Account/Lead/Contact so that your Users don't inadvertently send multiple emails to the same customer in rapid succession.
Enjoy!
- Marc
Marc,
Thats exactly what we are wanting to do. Thank you for the reply. I have a follow on question. In your opinion, does putting the AccountID in the url like that pose a security risk? Is there anyway to make it more secure?
Thanks
CR
Hi CR,
I would say that the security risk is minimal. As an example, if I am a Customer Portal or Partner Portal user logged in to a company's Salesforce.com Portal, I can see Record Id information in the URL (e.g. http://mysite.force.com/ShowPartnerOpportunity?OppId=006000003jHs89n). Even with the Id, someone still needs a username and password (and Access Code) to see the information. However, depending on your industry or your business' unique needs, you may want to use something other than Id. One idea would be to have an Auto Number field on the Account that generates a unique identifier for each Account but in a format other than a Salesforce.com ID (e.g. "Cust-{0000000}", thus generating values such as "Cust8765346"). The aforementioned link in the Email Template would then merge this into the URL such as http://mysite.force.com/AccountProfile?CustCode=Cust8765346. The Controller Class behind the Visualforce Page can then look in Salesforce.com for the matching record and conduct the personalization/update accordingly.
- Marc
Interesting. I apologize for all of the follow on questions but you are allowing me to think through this a bit more than I originally did. Do the people that I send the link to have to have user accounts/ portal licenses in order for this to work? Or can this go out to any non salesforce.com user?
Thanks again,
CR
No apologies necessary! Happy to be of help.
It depends on your company's specific business use-cases, but from a technical standpoint they do not necessarily need user accounts or dedicated portal licenses. Certain licenses allow you have x number of Sites visitors per month - these do not need to be dedicated licenses (e.g. each customer does not have to sign in to anything to complete your form). However, some of these license types do not allow write Access to Accounts/Contacts, so you would need to build the form in a Custom Object and have Apex write from that object to the record the customer is updating. Several moving parts here and several considerations from a Best Practices standpoint, but the bottom line is that it is not an absolute necessity for these customers to have dedicated logins.
I see. With regard to extending read/write functionality to outside users/customers, is using the portal license the best practice? I am sure there are some additional costs involved. The costs for the functionality would have to work for us financially so I will do some research on that.
Also, are you available for paid consulting project work?
Thanks
CR
Hi CR,
There are a few license types, and the best practices vary by use case. Portal Users may be best (this refers to the Authenticated Website license) - also worth evaluating Overage Authenticated Website licenses. Please note that the documentation lists Authenticated Webite licenses as allowing Users to log in to access customer support information - these licenses also allow access to custom objects such as the Profile form described above.
My company Cadalys is available for consulting, and we've done a lot of work with these types of portals (Fortune 100 retailer, security software company, large high-tech company, Marketo, etc...) www.cadalys.com. I will send my direct contact information separately.
Thanks,
Marc