Page Comparison

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. 

...

• 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:

...

• 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 AAkonsult PaymentsPayments2Us 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