Now that the Salesforce module is almost ready for a 5.x official release in its legacy package (same functionality as the already existing Drupal 4.7 official release), joshk and I, together with others on the Salesforce issue queue, have been making a battle plan for the immediate refactoring of this module to make for greater flexibility and usefulness.
We are channeling this discussion into this group on g.d.o. in the hopes of broadening the base and thereby enriching the discussion.
Our discussion has centered on two main topics:
- How to extend the salesforce module to support alternatives to profile
- Whether or not we should add users as "contacts" rather than "leads"
1. How to extend the salesforce module to support alternatives to profile
The question is, how to persist the salesforce profile in terms of some drupal entity, and not be forced to use the core profile module, as is the case with the legacy module. Perhaps the bio module could be used, or else some combination of usernode / nodeprofile / nodefamily.
Or how to make for flexibility so people can plug in (hook in) their own ideas.
The typical module user will be told "Given your custom salesforce lead/contact enabled form, here is how to translate it into the drupal entity"
2. Whether or not we should add users as "contacts" rather than "leads"
This really depends also on what kind of workflow the module user is implementing, and begs the question of what standard workflow to support off-the-shelf, and how we can implement a hook like method of extending/modifying it.
Make it a decent framework to tweak.
Maybe, on the admin page: fix it up so you can see a list of available forms, enable for lead, enable for contact, disable, ecommerce purchase form, add user form...
That is, be able to specify which forms should be Salesforce enabled, and whether they should be currently enabled for lead, enabled for contact, disabled, etc.
Maybe put two or three standard forms in there out of the box, then make it so someone can add their form, hook it in: where is my form, what are the elements and how do they translate into the salesforce entity object?
That same kind of task is needed if you are going to have other things than the core profile. So this is directly related to the first point.
Josh correctly suggests that the best way would be to define the hook and then use it hook ourselves to implement some predefined forms and workflows. Panels uses this method for defining layouts, views uses it extensively for defining tables and fields, then uses those hooks in the implementation of views itself.
Additional issues
- Apart from flexibility, to make it useful out of the box, have some predefined forms and basic Salesforce workflow supported
- For now, keep using the GPL nusoap library contributed for this module by Ryan Choi, who also wrote the Salesforce class being used by the module. Later on migrate to optional use of the PHP Toolkit (Apex Developer Network login required).
- A related concept would be bringing the Drupal Salesforce module into alignment with the most recent API versions
- Another idea I have proposed and which is under discussion is not to persist user data in Drupal at all, but rather to use the Salesforce database for persistence, even for single sign on purposes. One question that needs further exploration here is how would we avoid costly lookups for every page load (i.e. user info (with some kind of cache method... which is of course, related to all of the above... which module or method to use for cacheing...).
Conclusions
For now, investigate some hook based immediate options (bio module, nodeprofile module) for Drupal side persistence, and provide a method for reusing these hooks to extend flexibility.
And a call for people to participate in this discussion.
This is not an abstract discussion, we are moving forward (3-4 of us) right now to provide functionality for our clients who need this, of course, for yesterday... and for this we need to be getting out a version 2 of the module which overcomes the limitations of the legacy release... so get involved as quick as you can!
Victor Kane
http://awebfactory.com.ar
Comments
Some ideas...
1. How to extend the Salesforce module to support alternatives to profile
I like the idea to extend the salesforce.module to enrich the profile.module. I don't know if the salesforce.module should be an alternative to the profile module but after all testing and developing, the profile.module is not very powerful. The user has to change the source code to make it multilingual. The user has to install other modules in order to display the profile in an individual way. I've had a look at the bio.module and I didn't like it. Why not using nodeprofile. There was a big discussion about using nodeprofiles or not, but I think it is a good idea. Then the user can change the template and everything. But in the end it doesn't matter which module we use to display the profile. The thing is, it should be a module which:
- allows the user to choose which fields should be displayed.
- allows the user to create a custom design via templating.
- allows the user to display the profile in different languages.
- allows all users to maintain their data in an easy and comfortable way.
So what's your objective Victor. Am I getting you right with that: "Or how to make for flexibility so people can plug in (hook in) their own ideas." Do you want to make the salesforce.module flexible enough that the user can integrate any profile solution? That would be great but is it difficult to achieve?
2. Whether or not we should add users as "contacts" rather than "leads"
I think it is a good idea to keep it flexible. In my case I want to have it so that:
- when contact form is used NO lead is created
- when new user is registered NO contact is created
- when new contact is created in Salesforce and contact is marked as self-service portal user --> new user is created in Drupal
That is a good idea. What do you think should be the three standard forms? What kind of functions are included in the salesforce.module? I think we need:
- a function to connect Salesforce with Drupal
- admin area with the following options:
- - provide Salesforce username and password --> immediate check if supplied data is working
- - drop down to choose forms which will affect Salesforce
- extension of profile.module
- - new fields on registration (I like the fields which are available right now)
- - way to view and edit profile
- synchronization (see http://drupal.org/node/190631)
- - create, update or delete user in Drupal --> create, update or delete contact in Salesforce
- - create, update or delete contact in Salesforce --> create, update or delete user in Drupal
- - same functions available for leads?
- - these functions should be enabled/disabled in the admin area
- standard forms
- - registration
- - contact
- - what else do we have?
I really want to make some contribution to the module. As I already mentioned: I'm not a programmer but I can do a lot of testing and other stuff if you want me to.
Salesforce Objects as Nodes
As per discussion started here http://drupal.org/node/192605
My immediate needs center more around the Salesforce Account object and as such I've put a lot of effort into replicating that information in Drupal in a useable and flexible format. I choose to use data replication instead of any sort of salesforce query and object caching method since I believe this leaves us open to the most options in the future.
My specific use case involves creating a browsable directory of organizations (Salesforce Accounts) on a Drupal powered website. The site administrator needs to the ability to restrict access to certain information to registered users only, while making other information available to the general public. Contacts that are associated with a Salesforce Account need to have an equivilant user account on the Drupal site that allows them to update both their profile information and certain portions of their Accounts information from within the Drupal powered website. So that the whole experience is as seamless as possible. As far as the end user is concerned Salesforce may as well not exist.
Personally I think the benefits of replicating the data as nodes in Drupal makes the extra effort of doing so totally worthwhile. Once the Account information is in Drupal as a node site administrators have access to that information in the same way that they would with any other content type in their system.
Here are some of the benefits I see to using the method I've been using so far which involves data replication opposed to always querying salesforce for the information.
Drupal administrators are already familiar with CCK and the way it does things. Using CCK allows the site administrator to tailor the experience of editing account information on a per use basis. They can easily decide what order fields appear in, what they are labeled as, and through use of other modules who has access to edit what fields. All without ever having to write any code.
Once the data exists in Drupal as nodes we can access it using the Views module. This would allow site administrators to tailor the different ways of getting at the Account information to their needs. Things like, "show me all accounts in Minnesota" would be as easy as creating that view. Again, something that I think would be pretty hard to replicate using an object caching method.
Drupal already has an extensive set of modules that allow administrators to customize their interaction with the node system. The ability to index/search, access control, comments, event notification, etc. Providing the ability to leverage existing Drupal modules and services on the new data would make this module much much more flexible than if we were to try and control it all ourselves.
Changes to your Salesforce data model can be easily replicated in Drupal without the need to write any code. Drupal will be aware of all your custom Salesforce fields and have the ability to handle them right from the get go without you having to edit the $form array of your module to be able to edit them, or edit your theme to be able to display them.
What happens if you can't establish a connection to the Salesforce API?
My uses for this are pretty specific though, and go beyond just users, leads, and contacts which is where the current module seems to be focused. Though I think the same method could be carried over to user profiles without much hassle. I think there is a lot of benefit to be had from treating a users profile as a node as opposed to using profile.module or something similar. Again, coming back to that ability to make use of all the existing modules and services that work on the node object.
Just my two cents.
I totally agree with you!
I agree with eojthebrave. I'm for synchronizing all needed Salesforce data to a locally accessible Drupal table(s), rather than trying to maintain a constant connection to Salesforce.com.
In addition to all the reasons eojthebrave mentioned for having this data available as nodes, there's one more. Imagine a group of marketing goons that uses their single website to manage multiple vendor accounts, each with it's own localized userbase needs. Why couldn't Organic Groups play along with CCK and Salesforce.mod to create a complex series of relationships between certain users(or customers) and their data, but not others? Then the site owner and site moderators would have access to all the data from all those O.G. groups, should they so desire, and all without some extremely painful patching of the Salesforce module.
Now that's a value-added experience without any really hard bits of coding. Shall we do it? Let's make Salesforce 2.0 rely on Drupal nodes that are nothing more than some additional CCK fields attached to basic nodes. why not, I say?!
Senpai (my d.o account)
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
Regarding point #1 above:
I think that by pulling in all applicable Salesforce data and storing it locally as a node, we might be able to accomplish this goal far easier than by treating these three modules, and any others that might come along, as their own entities. True, Profile.mod is not a node type, and thus might require more work at first, but it's not far-fetched by any means.
Josh_k had a great idea that would help to solidify this approach. He said that by using a system of .inc files to display the applicable $forms for creating and editing nodes, any module would be able to utilize the power of Saleforce.module to get things done. The Salesforce.mod itself would then not care which "user profile" module was in use on a site, nor would it even notice if someone were to switch their user profile system from, say, Bio to NodeProfile or back again. I really like this approach.
Senpai (my d.o account)
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
I really like the idea of
I really like the idea of storing profile information as nodes, and through the hook_user() hook it would be trivial to append the information to the $user object when it is loaded, or to display relevant information on their "My Account" or any other Profile page.
You could probably also use hook_form_alter() to inject the relevant fields from your profile_node into the user account creation/registration process, and then process them using drupal_execute() to insert/update the node from the hook_user('register/insert/update') call.
Do you guys think it makes sense to separate handling of Salesforce Contact/Lead and Drupal user account related stuff into it's own seperate module. salesforce_user.module or something like that. Then use salesforce.module as more of a lower level module for things like overall configuration and sort of a master of ceremonies, keeper of the sacred $salesforce object. A lot of the other really large modules do this kind of things. CCK, Views, and eCommerce all attempt to separate tasks into their smallest parts and build a "module" for each of those tasks. This keeps things flexible, and means administrators could replace, re-work just the portion of the module that they need and not have to worry about all the other code. Just a thought ...
Let's make child helper modules!
This is the best plan thus far, and its one that Josh_k and VictorKane approve of, I'm sure. I'm keeping this page open, and am going to post a follow-up with some detailed outlines on which module should be responsible for every action. Once I do that, we can dissect it, and decide how to proceed.
Senpai (my d.o account)
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
Let me know if you need help
Let me know if you need help outlining/mapping things out. I would be happy to contribute my ideas.
I think it is a good idea to
I think it is a good idea to create a modul for each and every function. As eojthebrave said the salesforce.module should be the master which is responsible for the connection to salesforce etc. Then we can easily create new modules for every work case. In order to keep the system slim the admin can decide which module he needs to install. And as eojthebrave said it's easier to maintain and change. Great!
Okay, here is what I
Okay, here is what I envision things looking like in the future.
salesforce.module
Additionally I think this module should be responsible for invoking "synchronization" during a cron run. When cron is run the module could invoke a hook that allows each individual module to report on things that it knows about that need updating. Those "updates" would then get inserted into a log table. Then, this module would query that log table for X number of tasks to perform, and invoke the appropriate callback function for the module responsible for that task. This would allow us to have greater control over the tasks that are being performed during a cron run and help avoid issues like timing out.
salesforce_contact.module
salesforce_lead.module
salesforce_account.module
includes/nusoap.php
includes/salesforce.php
includes/salesforce_api.inc
includes/salesforce_sync_api.inc
This would also hopefully make it fairly trivial to add new salesforce_*.module modules to handle things like Cases, Contracts, etc via the functionality in salesforce_sync_api.inc
I'm sure there is more, but this is a good start.
JitterBit
Just for s#!ts and Giggles... Two Months ago when i was speculating on how to integrate various ERPs i came across an open source solution called JitterBit... http://www.jitterbit.com/ it seems like a vary useful tool to help out in any integration/ data sharing. Works on various levels including a DB to DB level so can get around some of the limitation of APIs. It works by creating "jitterpacks"
that map various fields from one DB to another.
They have a Salesforce project already started... http://salesforce.jitterbit.com/
Just another thought out there???
My plan was originally to use Drupal as a front end with social network/community features... and use salesforce for the backend account/lead/opportunity management.
I am intrigued on how this plays out.
Re: JitterBit
Interesting idea to use Jitterbit, makes me think of the discussion about the a CRM "broker" at http://groups.drupal.org/node/3622. Would Jitterbit need a Drupal integration module?
Jitterbit uses a modified Mozilla Public License. I don't know much about licenses, but you might want to check if it's compatible with GPL: http://www.jitterbit.com/Product/licensefaq.php
How can we help things move forward?
Agaric Design has a project coming up that will feature Salesforce integration. We have therefore some money / time to spend on this. The client's ideal scenario would be able to make variations of information-gathering forms or surveys for landing pages in Salesforce and have these forms available as landing pages within a Drupal site.
Personally, we would very much like to see things refactored to have as much code shared between integrating Salesforce and integrating CiviCRM, so that CiviCRM could potentially be a Salesforce replacement for a Drupal site with the least possible trauma. That said, we're being paid to do Salesforce integration. Whatever we do, we want to help make the most useful solution for everyone using Drupal and Salesforce (and perhaps CiviCRM too).
benjamin, Agaric Design Collective
benjamin, agaric
I'm still interested in
I'm still interested in refactoring things as per my outline above. Very open to suggestions as to how we can make it play nicely with CiviCRM, though I have no prior knowledge of CiviCRM and how it works.
Synchronization with Salesforce
It seems that Drupal will sync with Salesforce when cron runs. Would it be difficult to include a 'Force Sync' menu item under Admin -> Content Management -> Salesforce? This seems like a minor point, but I imagine that it would get heavy use in an implementation. Is the code to sync Salesforce and the local Drupal records dependent on cron, or could it be called without the overhead of a full cron run?
I don't see why we
I don't see why we couldn't call it manually. The only issue I can think of would be if you're trying to update a LOT of records it might time out. Though that should be easy enough to alleviate, just use the same "method" for updating that is used by cron, and allow the user to click the "update" button as many times as needed until everything is updated.
Has anyone started a Salesforce 2.x branch? Used the latest API?
I need to add my enhancements for a Drupal 5 site, so I would start 2.x work for Drupal 5. Those enhancements as outlined above would chiefly be a way of mapping CCK fields to Salesforce fields, or for now dumping them all in the notes/description field for leads. I'd also like to be able to set the lead source from the module to reflect various landing pages our client needs.
That brings me to the API question: The current Salesforce API is version 12 and the module uses version 6 right now. Anyone done any work or thinking on that?
I think I will start adding 2.x-ish features to the 5.x-1.x module, trying to make a submodule for CCK fields that uses a hook to communicate back to salesforce core. Whatever I do I'll update on my mucking around here.
benjamin, Agaric Design Collective
benjamin, agaric
Note that I don't see the need to mirror leads as Drupal users
For my client's workflow, and this seems to be different from the favored approach in this thread. Thoughts?
benjamin, Agaric Design Collective
benjamin, agaric
Custom contact forms and Salesforce: CCK, Webform, or new?
Thinking more about how to implement custom contact forms that map Drupal FormAPI fields to Salesforce Lead/Contact fields, I'm not so sure CCK is necessarily the best way to go. How would the mapping actually be done and what would we gain, especially for use cases where the data is expected to live on Salesforce.com only and not on Drupal. Does anyone think Webform would be better, or have another form-building module to recommend? How about a module made specifically for building Salesforce-mapping forms?
Here is our usecase for one form, but keep in mind that a number of similar, but ideally administrator-defined forms is desired:
http://agaricdesign.com/note/drupal-salesforceintegrated-contact-form-sp...
Thanks for any thoughts,
benjamin, Agaric Design Collective
benjamin, agaric
Best approach will be to do any mapping to Salesforce forms last
If we are to do any mapping its probably best to do it after all the forms have been created-- essentially when modules have handed things over to form_alter. Then we're simply mapping instances of Drupal form types to Salesforce fields.
Not sure exactly how to get this info for a particular form but it can't be hard given the form ID.
benjamin, Agaric Design Collective
benjamin, agaric
Saleforce integration project
Ive started working on a new a Salesforce / Drupal integration project and am looking to touch base with people in this group to see what stage development of a Drupal module(s) have got to.
Having read through the various posts it looks like the "Salesforce Webform Web-2-Lead Integration" (http://drupal.org/project/salesforcewebform) seems to be the latest development but I know there is also the "Salesforce" module for basic integration (http://drupal.org/project/salesforce) so im going to be testing these out but if anyone has got any other useful information then please let me know. The site im going to be working on is using Drupal 6 so ill be looking to upgrade any existing modules that work well up to Drupal 6 so ill post back any issues or developments I make.
What about Salesforce Sites ?
Any salesforce module for Drupal should be able to take advantage of Salesforce Sites. In case you are not aware of this, it is a new feature in Salesforce which allows access to Salesforce data/objects without the need for an API. It is documented at http://developer.force.com/sites
Using Sites will mean that there will be no need to have any synchronisation code for some use cases. Especially when using forms to update Salesforce data in a Drupal website.
@TimAlsop: How?
Tim:
How do you propose taking advantage of SalesForce Sites (SF Sites)?
As far as i can tell, the SF Sites is designed as a replacement for Drupal, not a partner.
Their FAQ clearly states that neither API nor integration points are available for CMS.
Has anyone used Sites? Can it be iframed for a drupal integration?
thoughts?
Drupal and Salesforce integration idea
Hi,
Very interested in associate drupal to Slaesforce I have a special need that could interest the community. I saw the module associated to Webform but in my idea I'd like to go with another idea. Today I'm replacing a Dot Net Nuke web site by Drupal. We had a lead generation by form. I'd like for now to give opportunity to visitors of our web site to register and download what they want without passing by a form request. But in this idea Drupal should be able to send informations to drupal every time visitors download a document. Do you think its something possible or is it a dream :)
Don't know if its the right place to post that so sorry if not.
Many Thanks
François