Posts tagged as:

salesforce

Real Social CRM

by Pearlbear on May 24, 2011

So I do have social media ennui, but I am also somewhat of a data geek, and cool ways of moving social media data into one’s nonprofit data workflow is pretty important in my most humble opinion. This post on Social CRM is not going to contain one buzz phrase. It’s going to talk about one particular, interesting example of how to move social media data into a real live CRM -the one you might even be using now – Salesforce.

This example uses an app from the Salesforce AppExchange, called “Salesforce for Facebook and Twitter.” To make things just a tad confusing, this is also called “Salesforce for Social Media” and “Salesforce for Twitter.”

There are likely many more options, but this is one I’ve seen that is pretty cool, although it has its weak spots. It definitely is geared more toward the “Service Cloud” than the “Sales Cloud.”

You can set up multiple twitter and facebook accounts, and each facebook account can have access to multiple pages. It’s all done via OAuth, which is cool. Once you set up the accounts, you can then grab conversations:

You can filter and sort, just like records in any other SF object. You can choose whether or not to send Twitter or Facebook identities to Leads, Contacts, or Person Accounts. You can choose to create cases from tweets or FB posts as well.

You can tweet or post to facebook directly from Salesforce:

And it works:

You can schedule tweets and facebook posts as well.

There is a lot more you can do – it’s a pretty cool tool. The one thing I can’t seem to find – and I don’t know whether this is in development, or they won’t ever do it – is import your social graph into salesforce – your facebook fans or your twitter followers. I’m not sure why this is, exactly. It seems a big gap to me. But then, it is the folks who engage with you who you definitely want to make sure to keep track of.

Anyway, if you are a user of either Salesforce, the Nonprofit Starter Pack, or Convio Common Ground, this is definitely a tool to know about.

Tagged as: , , , , ,

{ 2 comments }

Drupal/Salesforce Integration

by Pearlbear on March 23, 2011

A bit over a year ago, I wrote a post about the status of Drupal/Salesforce Integration. I figured it was time to do an update.

At the moment, if you want to integrate Drupal and Salesforce, you have three options:

  1. Use the contributed modules (or have a developer install and configure them for you).
  2. Use Jackson River’s Springboard.
  3. Roll your own (or have a developer roll your own for you.)

I’m going to talk in much detail about #1 in a bit. I’ve not had any experience with Springboard, but it’s important to understand that it is not open source, and is only maintained by one shop. That is going to be an inherent weakness – no matter what. I don’t know enough about it to match it to the contributed modules, but it’s hard to imagine that it’s possible for it to keep up, given the nature of open source development. All of that said, it’s supposed to be an interesting all-in-one sort of option, so it’s probably worth a look.

Rolling your own is always a precarious proposition. I frankly can’t imagine much of a situation where  it would be preferable to modifying what’s available and contributing the mods back.

So what is the status of the Drupal modules? Right now, there is an alpha release for Drupal 6, which is alpha in that very humble open source sense – it’s being used in quite a number of production sites. It includes some great stuff. You can see an overview here, in the slide deck for a talk given at NTC last week, which compares the integration of Salesforce with 3 of the big open source CMS platforms, Plone, Drupal, and Joomla.

There are four major projects:

  • Salesforce Suite, which includes:
    • The API – the core module that does the communicating with the Salesforce API
    • Contrib – a module that provides support for import/export from contributed modules
    • Export Queue (experimental) for queuing exports
    • Import – importing data from SF
    • Match – for matching objects before creating new ones
    • Node – for linking Drupal nodes to SF objects
    • Notifications (experimental, sort of – it’s worked quite well for me) – allowing Drupal to handle SF outbound messages
    • User – matching users to SF objects
  • Salesforce/Ubercart – provides integration for Ubercart. Uses the Salesforce Suite API
  • Salesforce Feeds – allows for feeding SF records into Drupal via Feeds. Also uses the Salesforce Suite API
  • Salesforce Webform – Allows for passing data from a Drupal Webform to Salesforce. Currently does not use the Salesforce Suite API, and cannot be used on the same site as the Salesforce Suite, but hopefully that will change soon.

All of these modules are actively maintained, there is an active base of folks using and contributing (including me) and there are plans afoot for Drupal 7, with big improvements. Of course, there are still some snaggy spots, and it helps if you know some about Salesforce to have this work really well, but I’ve gotten good results doing two-way sync of user and node data with the Salesforce Suite, as well as used the Salesforce Feeds module some.

If you use Salesforce, want integration, and are pondering a CMS choice, definitely check out the overview slides. If you are using Drupal, want integration, and considering a CRM, definitely consider Salesforce. And if you are already using both, and looking to find ways to integrate them, drop me a line, I can either directly help you, or point you in the direction of folks who can.

 

 

Tagged as: , , , ,

{ 2 comments }

Open Source vs. Proprietary: Nonprofit CRM

by Pearlbear on March 16, 2011

CRM systems (which I am defining rather loosely, rather than tightly, for the purpose of this post – as the tool or set of tools used to track constituents, donations, perhaps even events and volunteers) are arguably the most important technology tools that nonprofits use. Organizations use this tool to track donors, send out newsletters, track the success of campaigns, track who is engaged with the organization in what ways, etc.

And, in my experience over the past 15 years, it’s where organizations are willing to spend the most money on technology – often more than on their website or other technology tools – for good reason. Because of this, the deck has always been stacked against open source tools in this arena. The sheer number of vendors providing this toolset for nonprofits is huge (although rapidly shrinking.) Two of them (Convio and Blackbaud) are even publicly traded companies, which says a lot about the profit potential of this vertical.

On the proprietary side, there is a wide range of available tools, from the relatively inexpensive, like Salesforce (web-based, including Convio Common Ground and the Nonprofit Starter Pack,) eTapestry (web-based, now owned by Blackbaud), Democracy in Action, and GiftWorks (desktop) to the egregiously expensive (you know which ones I mean.) Both NTEN and Idealware are the best sources for information about the range of options for this toolset – that’s out of scope for this post.

As you can tell, I’ve lumped SaaS tools like Salesforce, DIA and eTapestry in with proprietary in this post – that’s because that’s what they are – proprietary. However, Salesforce in particular has a leg up that most other proprietary tools don’t have, because of their open APIs and their incredibly robust development platform. That combination is impossible to beat if you need integration, ease of data movement, and a lot of customization. From my perspective, open data (via open APIs) can sometimes be more important to consider than whether or not a tool is open source – since integration with other tools, as well as using external tools of various sorts is critical. Closed data systems, difficult to integrate systems, or systems that require payment to get access to your data should be avoided at all cost.

On the open source side, there are a number options: you can choose an open source CRM package (designed for business), like SugarCRM, and use it or customize it for use in a nonprofit, use CiviCRM, or choose the desktop-based nonprofit CRM called MPX (built by a company called Orange Leap.) I’m excited about a new Drupal project called “Red Hen CRM” but it’s very fledgeling.

CiviCRM is a web-based open source nonprofit-focused CRM/Donation management tool. It’s been around for a while now, and is used by many organizations, some quite large (like the Wikimedia Foundation.) It is quite broad in its feature set – it has donation pages, event management, e-newsletter functionality, even a case-management system. I’ve installed, configured and administered CiviCRM many times, still work with it, and I have, like most developers, a love/hate relationship with it:

  • I love that it’s open source/free software
  • It’s got a great community of developers and users
  • I love that it’s feature rich – you cannot find the whole set of things it does in any proprietary tool that I’ve seen.
  • It is a tool that has unmatched cost-effectiveness for small organizations
  • It’s great that it integrates with both Drupal and Joomla (although the Drupal integration is by far the most solid – and it is a very nice integration – hard to get with proprietary tools.)
  • It is relatively easy to set up for most functionality

But …

  • Data migration into CiviCRM is often nightmarish (this is really where the hate lies)
  • Reporting tools are improving, but don’t match the proprietary versions
  • It can sometimes be pretty tough to handle complex issues
  • It can be tough to troubleshoot issues

MPX is a desktop tool, and although it is open source (GPLv3,) unlike CiviCRM, or SugarCRM, it is built on top of a proprietary stack (.Net/MS SQL Server.) It has primarily been used in faith-based organizations (that is Orange Leap’s primary client base.) But it’s a very full featured product, and quite mature.

So if you are a small organization that perhaps is still working with spreadsheets, CiviCRM is a great idea to check out. But in general, there are a lot choices and, sadly, few of them are open source.

 

Tagged as: , , , , , ,

{ 6 comments }

Salesforce.com and Ruby on Rails

by Pearlbear on December 17, 2010

Programming languages and I have issues. By now, I’ve learned quite a number of them (I think 9 by last count), but for some reason, I seem to choose my work on them just at the top of the curve, or as they are going down. I have yet to manage to pick one early. I learned C at the height of its popularity, just as C++ was beginning to rise. I learned Fortran when it was almost dead, mostly for fun. I learned Pascal toward the tail end of its reign. In the late 90s, I chose to write a CMS in Perl instead of PHP. Dumb idea.

I’ve been moderately interested in Ruby and Rails for years now, although I haven’t yet spent very much time getting my hands really into coding Ruby. As pretty much all of you in the Salesforce.com world know, Salesforce.com agreed to buy Heroku for a pretty big chunk of change. I’d played with Heroku a little a while back, and I thought it rocked.

What is Heroku? Heroku is cloud Ruby on Rails. Build a Rails app, and deploy it on Heroku. It’s pretty sweet. So why would Salseforce.com buy it?

On one level, it makes über sense to me. As someone who has managed to learn some Apex, which is, frankly, somewhat of a monster of a programming language, it’s pretty clear that it’s not super easy to build complex apps using it. It’s like Java in heavy chains. A well-joined RoR & Salesforce.com platform, all in the cloud, would simply rock. (In case you are wondering, there already is a Ruby toolkit for the Salesforce API, although it looks like it only works on Rails 2.3, not 3.)

One another level, it’s fascinating. The culture of the Ruby and Rails world, the open source, community-driven, gift economy meritocracy, is very different than the Salesforce.com world – proprietary, business oriented, certifications-focused world. Of course, these are stereotypes – there are plenty of business-oriented Rails folks, and plenty of open-source oriented Salesforce folks, but the worlds really are culturally very different.

I’ll have a post soon where I talk in detail about why I think open source has both won and lost the open source vs. proprietary war, but this particular intercultural marriage will be interesting to watch. And the great thing is that our company has had such a marriage for a couple of years now, and it works.

Anyway, I’m dusting off my Ruby books, and diving in. Fun times!

Tagged as: , , ,

Salesforce as a CMS?

by Pearlbear on September 22, 2010

Salesforce is a very powerful platform onto which one can build a large variety of interesting kinds of custom applications. I’ve already talked on this blog about Salesforce integration with Drupal, Plone, and others. Today I’m going to delve into Salesforce-based CMS systems – systems built as applications on top of the Force.com platform.

First, what are the advantages and disadvantages of this approach? The disadvantage is that primarily, Salesforce was not designed as a CMS – it was designed as a Salesforce automation and customer service tool. It has become a powerful platform, and there is a lot you can do with it – but it was never designed with content or visual design in mind.

What are the advantages? If you’re running database applications (tracking donations, events, programs, clients) and want deep integration between your web content and your data, it is an approach that is hard to beat. Certainly CMS/CRM integrations can go a long way – but ultimately, using Salesforce as your CMS platform will provide a kind of power that is not easily replicable using an integration. But with that power, may come some sacrifices.

What are the options for doing CMS-like things on the Force.com platform?

  • The native capability of something called “Sites” – which is a publicly facing version of what’s called “VisualForce” – a markup language that includes HTML as well as APEX code (Force.com coding language). This requires a lot of custom code, and becomes unwieldy when you get to more than a few pages unless you write a mini-CMS yourself to handle things as a site gets more complex. But there is a lot there.
  • CMSForce – This is an “open source” (in quotes because although you can get the source code, do what you’d like with it, and contribute to the project, because it’s written on a proprietary platform, it’s not really open source.) I’ve spent quite a bit of time with this one, and more to come, I’m sure – like any open source project, there is a lot that could be done to make it more usable. But it certainly is something to evaluate, and contribute to, if you find it useful. It is written by Force.com Labs, so it’s got serious Force.com developers behind it.
  • OrchestraCMS – This is a paid app – with discounts for nonprofit organizations. I’ve taken just a test drive, but it’s pretty impressive – it has it’s own UI, and is well developed. There were a few hiccups in getting going, but I suspect it was because I only spent a little time with it. A partner we work with has done a lot of work with this application, and we’re pretty interested in it.

There are a couple of others, and I’m sure more in development. Salesforce has a rich enough data model and development platform to sustain a solid CMS – the big question is – is this the right fit in terms of integration? Salesforce-based content management is embryonic in comparison to CMS systems such as Drupal or Plone (or even WordPress for that matter) but being able to draw data directly in and out of salesforce very easily, for some organizations running Salesforce, might well be worth it.

And, it’s also possible to have one’s main site in a solid CMS, and instead of using complex integrations, have a mini-site with the same look and feel based in Salesforce, for the data needs you have. Again, it depends on what your use cases are, but that’s another way to go.

Tagged as: , ,

{ 6 comments }

What Drupal and Salesforce have taught me about coding

by Pearlbear on June 30, 2010

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

{ 1 comment }

Why use contributed Salesforce modules for Drupal?

by Pearlbear on March 24, 2010

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

Drupal and Salesforce

by Pearlbear on December 31, 2009

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

{ 10 comments }

Exciting changes afoot…

by Pearlbear on April 1, 2009

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

{ 1 comment }

CRM & CMS Integration: Plone and Salesforce.com

by Pearlbear on March 16, 2009

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

{ 4 comments }

← Previous Entries