I’ve been spending a fair bit of time in the last couple of years learning to code in a new way. It reminds me of a transition I made in coding from having written stand-alone applications for varied computers, to writing code for the web. When I was in college, grad school and early in my academic career (this dates me – from the early 80s to early 90s), I spent a lot of time writing stand-alone applications, mostly in Pascal and C. The shift from that kind of code, to writing for the web was a lesson in protocols, constraints, and different ways of troubleshooting.
The transition from writing free-form web applications, to writing modules for Drupal, or APEX customizations for Salesforce, is another set of lessons in protocols and constraints. First, it’s not enough to understand the syntax and form of the language (this is especially true for APEX – and beware the required test coverage!) One has to understand how the surrounding application works – what APIs or methods one can use, and how. And unlike long standing languages, there aren’t lots of detailed cookbooks and that sort of thing lying around – a lot of it is learning from other folks, as well as just learning by trial and error.
And, in my small forays into learning frameworks like CakePHP, Ruby On Rails, and others, it seems like these days, coding for the web is many lessons in constraints – which is a good thing, I think. Even though it feels like beating my head against a wall, it’s nice to know that I won’t “dump core” and break Salesforce (although I for sure have broken Drupal on occasion!)
Tagged as:
apex,
code,
drupal,
salesforce
Lobo’s comment on my post yesterday prompted me to complete this blog entry that I’ve been ruminating on for a while. I wrote a blog entry a while back on the state of Drupal/Salesforce integration. What I didn’t say is that a number of shops that have done Drupal/SF integration for production sites chose not to use the contributed modules – they built (or are building) their own custom Salesforce/Drupal integration modules.
A few months ago, in preparation for a couple of projects, and a big push into this area for our company, I was faced with a strategic choice – go it alone, and build our own integration module for client projects, or plunge into using and working with the contributed salesforce modules. Truth is, it wasn’t really a choice for me – I’ve got using and contributing back to open source projects in my DNA somehow. Although we certainly could have chosen, like others, to go our own way, we have committed ourselves to using, and contributing to the modules on drupal.org.
What we lose:
- Complete control over development process and direction
- Not having to fix other people’s bugs in order for stuff to work
What we gain:
- Not having to reinvent a number of wheels
- An easier upgrade path
- Build on the work of others
- Collaborate and learn
The work done so far on the modules is really solid – and it’s getting better. There is a great new maintainer, and increasing activity and contributions. There are also a number of other module integrations (like Ubercart, Webform, and FeedAPI) that are moving forward. Integrations with Views and Actions are also moving being considered (it’s instructive to look at the issues queue). This is stuff that would be hard to match, and makes building integrations for different kinds of sites easier.
So beyond just my own personal preference, I think that there is much benefit, both for our clients, and for us as a company, in hitching our wagon to theses contributed modules instead of going it alone.
Tagged as:
CMS,
drupal,
opensource,
salesforce
It’s taken me a while to write this blog post, mostly because I have been working hard at various things (like building a business and building new websites.) This is the last installment in my CRM/CMS integration series, that started almost a year ago (wow!) And I’m skipping Joomla/Salesforce Integration because there isn’t any publicly available documentation or code about the integration that PICnet did with Joomla and Salesforce, called J!Salesforce. [update: see Ryan's comment below.]
So what is the state of Drupal/Salesforce Integration? It’s not as mature as the Plone/Salesforce integration, for sure, but it is coming along nicely. There are several contributed modules:
- salesforce – main module, with API, node, and user integration possibilities. This module provides the basic salesforce API connection (via SOAP), and includes field mapping, and basic import/export
- sf_webform – Makes integration with webforms in Drupal fairly easy. Web-to-lead is quite nice and flexible with this module.
- uc_salesforce – Provides integration with ubercart orders
- parser-salesforce – Integration with FeedAPI – pulling data from salesforce into drupal nodes via FeedAPI (I hope to start maintaining this module)
- sf_import – Import Salesforce objects into Drupal nodes (will be folded into the main salesforce module)
All of these modules are in alpha or beta, although I know for a fact that some of them (or versions of them) are working in production sites. There are a fair number of bugs that need to be fixed before there is a stable release. There are a bunch of outstanding issues that need a lot of work (like caching, for instance). There are two other modules that are related, but don’t use the main salesforce api module – one for ubercart, and one for web-to-lead (called salesforcewebform). That module has a stable release, but only provides the ability to integrate between Webforms and leads, not other objects.
Right now, the salesforce module allows for integration of contact, lead and campaign objects only. so that’s another big area that could use some work.
There is a good screencast done by one of the folks (Jeff Miccolis from Development Seed) who has worked a lot on this project.
I’d say that in a year, we’ll have a good solid module release, providing lots of features for integration between Drupal and Salesforce.com.
Tagged as:
CMS,
CRM,
drupal,
integration,
nptech,
salesforce
I have some exciting news. For the last few months, I have been working on a new collaboration called OpenIssue, which is a growing, diverse, self-reflective and constantly-learning team. We are focused on delivering quality web technology solutions to nonprofit organizations and social enterprises.
As you know, I have built a long-time expertise in open source software and web applications, particularly Content Management Systems (CMS) and online database systems, including CRM. Thomas Groden, my new business partner, has expertise in Software-as-a-Service Constituent Relationship Management Systems (CRM), as well as much more broad expertise in technology infrastructure.
All technology implementors have to choose their tools (unless they run a very large shop) and we have decided to focus on implementation of both Salesforce.com and CiviCRM as CRMs, and Drupal as a CMS. We are keenly interested in building on our expertise to integrate these open platforms in really rich ways, to allow organizations to create great online applications.
I’m excited to be a part of a team – I’ve been a soloist for a while, and it’s nice to build collaborations, and work together with people with shared ideals on larger projects than I’d be able to take on alone. And I’m really excited by the set of technologies we’re working on, and the kinds of applications we’ll be building with these technologies.
And you can follow us on twitter.
Tagged as:
civcrm,
CMS,
Consulting,
convio commonground,
CRM,
drupal,
nptech,
salesforce
Today, I was reading up on what the Plone community has done with integrating their CMS with Salesforce.com. I am thinking that this might be a good model for how we can do it with Drupal, but that’s a subject for another post.
(from Plone/SF Integration group)
There’s a good overview of the integration on the developerforce wiki. There are 5 components to the integration:
- a couple of toolkits that provide the basic back-and-forth between Plone and Salesforce.com (they talk to Python and Zope)
- an auth plug-in that allows for Salesforce.com objects to be Plone users, credential checking, caching of user data, and syncing of data from Salesforce.com and Plone
- an integration of PloneFormGen with Salesforce.com for web-to-lead forms, etc.
- an event management product that connects with Salesforce.com
- A PayPal integration product
This is a pretty robust set of channels for data to move back and forth from Salesforce.com to Plone. There is a Plone/Salesforce.com Integration group, that keeps working on this, and a number of organization, including ONE/Northwest, have invested huge amounts of time and resources to working on this integration.
This is, for sure, one of the most robust open source CMS to CRM integrations out there, and one that seems to be getting pretty close to providing very powerful integration “out-of-the-box” – instead of having to piece things together and do customized code, which is more common than not.
I haven’t gotten my hands on this to try (not being a Plone person, I doubt I will), but folks might want to talk in comments about how straightforward the integration is, given differences in data for different instances of Salesforce.com. I don’t know how much code tweaking is required to really get this going. But in any event, it’s great that it exists, and it’s a great benchmark for CMS/CRM integration.
Tagged as:
CMS,
CRM,
plone,
salesforce
This morning, I looked at both Salesforce.com, with the second nonprofit template, and CiviCRM with a small group of colleagues. All of us implement, or have used, one or both of the systems. But each of us has expertise in only one of the systems.(I’m one of the CiviCRM folks).
It’s pretty interesting to compare them. The nonprofit template has certainly helped to make it easier for nonprofits to do the brain surgery required to use a for-profit sales tool for nonprofit CRM purposes. Salesforce.com is, of course, much more sleek and polished. And the power behind the application is pretty unassailable. And, there is a huge ecosystem of add-ons available for Salesforce.com that doesn’t exist yet for CiviCRM. But there are significant modifications, both in the way nonprofits think about data, as well as the way data is manipulated, that have to take place in order for organizations to use Salesforce.com. CiviCRM is really intuitive for organizations to use out of the box.
Donation pages, and event registration are built in to CiviCRM, but have to be added into Salesforce.com. It’s way easier to create relationships in CiviCRM – you can create any kinds of relationships you want. Can create groups and smart groups easily in CiviCRM. This is harder in Salesforce.com, and smart groups don’t exist in Salesforce.com.
Anyway, there’s lots more, and you’ll be hearing lots more about both of these tools from me in the coming months.
Tagged as:
civicrm,
CRM,
nptech,
salesforce