Overview

Who this is for:

• Salesforce Admins talking to Web Developers and their Salesforce Developers to work together the build an integration between Salesforce and the corporate Website. 

Who needs this:

• Every Salesforce Admin. If you have Salesforce, and you have a Website, if there is no form fo integration between them, you are "doing it wrong". Even if it is a simple Web To Lead, you need to know about how to set it up, how it works, and the security implications the way you have chosen to do it. 

Who are the people involved:

• Salesforce Developer
  • Will set up the Web Service to use.
  • Will store Salesforce admin passwords in plain text in dev tools. 
  • Will write the custom code for the web service if there is anything fancy that needs to be done.
• Web Developer
  • Will consume the Web Service.
  • Will write the code in the website to query or add data to Salesforce.
  • May store passwords in plain text on the website.
• Salesforce Admin (You)
  • Will create the user that the API will access.
  • Will define the security that the website user will have.
  • Will set up profiles to use API or not.
  • Will actively look at OAuth connections on a frequent basis to ensure nothing untoward is happening.

Business Cases

Business Cases for integrating Salesforce with Websites:

• Set up events as campaigns in Salesforce and show them on the website
  • No duplication of data
  • Or sync data to website CMS - with duplication of data. 
• Set up products in Salesforce and sync them to your shop
  • One tick in Salesforce and the product is active or not. 
  • Can go through an approval process. 
• Sync member data from Salesforce to Website to control pages accessible on the website. 
• Provide authentication to the members area of the website.
• Auto create a new user on Chatter and email them their chatter credentials when they sign up to your website. 
• Allow members to update their details, after authenticating. 

Notes:

• Wherever possible, don't replicate data in the CMS that is in Salesforce
• Don't store data in the CMS - send it to Salesforce
• Query data from Salesforce as it is needed

Data

Getting data onto the website

• API to Query 
• Public Query
• Sites
  • See Creating Anonymous Apex REST APIs with Force.com for an example

Getting data into Salesforce

• Watch what data you are asking for 
  • Especially under the new NPP's
  • Ensure you have a Privacy policy on the website. 
• Web To Lead
  • No HTTPS
  • 2 simple ways
    • The default form with a simple submit button
      • Org ID is visible when you view source. 
    • cURL
      • See Pushing Leads to Salesforce with PHP
      • Most developers will use this. 
• Web to Case
• Third Party Integrations
  • See Integrations
    • Zapier
    • OneSaaS etc.
  • Limited - usually can only create new records, not update. 
• Third Party Tools
  • Many examples
    • Marketo
    • Exact Target
    • Hubspot
    • Form Assembly
  • I would still do a separate user for these

• Roll Your Own
  
  • Using the Salesforce API.
  • SSL Required
  • Separate user required
  • Watch the Authentication
• Use Sites
  • Set up a separate user for auth
  • See how Payments2Us does it

Authenticated Users

• Use Sites
  • https://developer.salesforce.com/forums/ForumsMain?id=906F000000099rMIAQ
• Sync Member data to Website
  • problematic
  • duplication of data

Security

There are a few ways that Websites can connect to Salesforce. 

• Token
  • Insecure
  • Every time you change passwords, needs to be reset.
  • If they are used on your website, and hard coded, what is the security of your website like? 
• OAuth
  • Not great for anonymous access if possible. 
• For connecting to a website, use a different user
  • Extra cost
  • No cheap way
  • Lock down the Profile
• You will need an SSL Certificate 
  • They are a PITA to get and install. 
  • Web developer needs to set it up. 
  • Not all SSL's are the same. See 
  • Validation requirements http://en.wikipedia.org/wiki/Extended_Validation_Certificate, http://www.thawte.com/resources/getting-started/extended-validation-ssl-faq/

  • Wildcard are more exxy - they can be used across subdomains and are invaluable in commerce.

End Result

• Be careful with the people, apps, and services you share your data with. 
• Know enough to talk to your Salesforce Developer and Web Developer