SalesForce integration with MODx?

I just found this thread and thought I should respond, as Susan linked to my wxSalesforce github repo above.

I should point out that wxSalesforce is still very much alpha. Use at your own risk.

Also, as Susan pointed out, it's for a very specific use case - I needed a SOAP server to receive notifications from Salesforce and pass the data to MODX, and from there into Eloqua. For any other use case it would only be useful as an example, and you probably want to disregard any references to wxEloqua.

I would like to eventually expand on this and develop full integrations of Salesforce and Eloqua with MODX designed for general use cases like passing user data back and forth, submitting forms, creating tasks etc - but that's a huge project and I'm not sure when I'll have time for it.

Yeah, I know what you mean by "huge project". We're putting off the full SalesForce user integration (no users in MODx at all, everything "user" managed by SalesForce with snippets to handle everything via the SalesForce APIs) until the Evo site is all moved to Revo and everything else cleaned up.

I've got experience of integrating Salesforce with MODX, I worked a project where we pushed lead information into Salesforce (custom fields et al) - main challenge I found is the frequency at which Salesforce change their API without notice. Maybe it's settled down a bit now.

Feel free to ping me on this, I still have ideas of a Salesforce/Netsuite/CRM agnostic MODX component. Just never really got round to developing on my ideas

Yes, the SalesForce changes have come up even in the little bit of investigating I've done. Well, I'll cross that bridge when I come to it.

no users in MODx at all, everything "user" managed by SalesForce

I would probably maintain people as MODX users too, synchronize with Salesforce to update the information. It would perform faster and allow you to use methods of the MODX user class. That's how Eloqua handles Salesforce integration - it maintains its own contacts table, and synchronizes with Salesforce to keep data updated.

But of course that's a judgment call based on your implementation.

The only purpose MODx users have in this case is to allow viewing of protected pages. All that requires is some settings in the SESSION. Since there are thousands of users, it just seems reasonable to use a snippet to pass user validation off to SalesForce (which has to be done anyway for tracking purposes, so in this case there would be no speed advantage) and set the SESSION values according to the SalesForce API return values.

Yeah, that makes sense.

I know it's been a super long time since the last follow up on this, but I'm looking at a pretty big project where we will need to be able to integrate SalesForce with ModX and I can't find any documentation of anyone having done that successfully, either on ModX or on Salesforce support. I tweeted at Mark Ernst just now, so maybe he'll respond.

Any ideas of where to start? Some necessary items to integrate off the top of my head would be contact forms, user creation/tracking, product info and updating, etc. Any thoughts would help!

As far as I know, nobody has published a full integration with Salesforce for MODX. So this is indeed a big project.

Contact forms would be easy. Salesforce has a web-to-lead feature that allows you to post to Salesforce from an external form, so you could just make the form in MODX and have it post to Salesforce. If you need to get the data into MODX as well, you could process the form with FormIt and re-post to Salesforce using a hook - I have a hook for that here: https://github.com/freejung/Webinex/blob/master/core/components/webinex/elements/snippets/snippet.resubmit.hook.php

The other things you mention will be quite a bit more involved.

You can find lots of information on using the Salesforce SOAP API in PHP in general. So one way to get started would be to get a SOAP client class working in PHP that can pull the data you need out of Salesforce.

Then you'll need somewhere to put the data in MODX. I would store the contact data in the users table. If you have additional data that doesn't fit in existing user fields, you could use extended user fields, or make a custom table linked to the users table. For product info, you may want to write an Extra with custom tables to store the data, or use an existing ecommerce Extra. You could store the products as resources but I wouldn't recommend it unless you have a small number of products, as the performance would be bad with lots of products.

Anyway, once you have a place to put the data and a client that can pull the data, actually getting the data into MODX should be pretty straightforward using the standard XPDO methods to create your MODX objects, set their values and save them.

Sounds like a good use for MIGXdb.

The problem I found with my attempt at SalesForce integration is three-fold: First you need a good understanding of the MODx user management system and any other classes you'll be working with (data in - data out), then you need a good understanding of SalesForce and its APIs and SOAP or REST interfaces(again, data in - data out), then you need a good understanding of the specific use case (what is this supposed to be doing?).

In my situation, I'm just beginning to study Revo in depth so I can't say that I fit the first requirement, in the second place I had never heard of SalesForce before (although I have found that they have excellent tutorials and online classes available for free, as well as a free "sandbox" account), and in the third place there are several totally separate divisions of the business involved, so it is very difficult to determine exactly what they're doing with it.