Trying to dev a Web2Activity - Need direction

Question

I am a web dev with novice experience implementing API integrations. I have a php based website that currently has multiple web2lead forms spread across the site.

There are few instances where I have a custom web2lead implementation that really should be web2activity. The user is logged into an account on our website (which upon initial creation created a lead record in SF). So there is an email address that is the same on both the website and as a Contact in SF.

I have tested out: http://developer.force.com/cookbook/recipe/interact-with-the-forcecom-rest-api-from-php and got it up and running fine, but this requires that the user "auth" to SF which wouldn't work as our users don't have any visibility to SF.

In the past, with other apis, I have implemented a flow like: using Curl, call a url and pass a pub+secret keys and the API would respond with a token that would be used to pass data. Is this possible in any way with SF?

I have been doing some digging and I think the issue I am trying to get past is: https://developer.salesforce.com/docs/atlas.en-us.salesforce1api.meta/salesforce1api/quickstart_oauth.htm

The docs note: "In your client application, redirect the user to the appropriate Salesforce authorization endpoint. On successful user login,Salesforce will call your redirect URI with an authorization code. You use the authorization code in the next step to get the access token."

the problem is that, like I said above, the web user doesn't have any visibility to SF.

I am having a hard time deciphering the right direction. There is such a large API/framework with SF.

Any direction would be really helpful.

Answer 1

You have a number of options available to handle what you're trying to accomplish. One is to utilize Inbound Force.com SOAP or REST APIs services to process the incoming forms from your site. But, as you're aware, those options, particularly the REST option will require an OAUTH token. You could use a dedicated Salesforce User ID to provide that if needed; not the best use of a license. You could also use the Ajax Toolkit to handle the forms as an incoming Ajax request through http. There's also the PHP toolkit, something you may want to look at since you're already using and familiar with PHP. For more on all your options, I recommend you look at Integrating with the Force.com Platform.

With all that having been said, I think the simplest solution for you would be to use your existing Web to Lead. I'd add the additional fields you need for the Event along with a Boolean Is_Event field and if you have several different sources of them that you want to identify, I'd add a field for that too. I'd then create a BeforeInsert trigger on Leads in Salesforce that tests the Is_Event == true. If it is, I'd use the trigger to remove those Leads from the list that's being processed and create the new Events using the data in the additional custom fields provided the Names and Emails addresses are properly returned in your query along with any other criteria you might have for your event.

I'd expect that at least some of the fields you'd need for help with Event creation/processing wouldn't need to be displayed on the form you'd have on your site. All you'd need to do is hide them, but also send their contents with the completed form upon submission. WTL already does this with some of it's fields. There shouldn't be any problem doing it with some additional ones too.

You can create any number of forms in Web-To-Lead with a series of processing rules for them. With the new process builder, you may discover a way to do this without a trigger, but I can't think of one which doesn't create a lead. That's why I recommend a trigger. This would seem to me to be the fastest way to get this up and running while also having the lowest API compared to the alternatives. If I'm not mistaken, I don't think you'd be consuming any Web services API usage as that should be "free" as part of Web to Lead functionality. Instead, all you'd be consuming is your trigger overhead.