 All right, while we're waiting for everybody to get seated, this is the integrating Drupal with non-profit CRMs session. So if that's what you came to see, you're in the right place. You're looking for entities or symphony, you're in the wrong place. Yeah, exactly. Don't take the beer with you. Yeah, dig deep. You've got to dig deep. You've got to be in it to win it, people. You might entertain people. All right, well, let's go ahead and get started. We'll do some introductions first. My name is TJ Griffin. I'm also here with my colleagues Tom Williamson and Philip Cave, we're up here on the front. We're a part of Jackson River. We need to go up. All right, we're part of Jackson River. We build websites for non-profits. We integrate them with Salesforce. We use Drupal and Salesforce primarily. And we have an open source non-profit Drupal distribution that powers online fundraising and marketing. It's called Go Springboard. You can get to it at gospringboard.com. Let me just go this way. Cool, my name is Sean Larkin. I work at a company called ThinkShout. We're in Portland, Oregon. We work with progressive organizations as well. We're right now really interested in native Drupal CRM solutions. So we'll be presenting on Red Hen CRM, which is our native Drupal 7 solution. And I'll pass it along. Chris Clark, I'm with FreeFlow Digital. We're in Eugene, Oregon. We're in Portland as well. We deal with non-profits exclusively, a lot of data migration and moving from CRM to CRM. Excellent. So we're going to do this session in two parts. The first part is we're going to do an overview of non-profit CRMs that integrate with Drupal. We'll also talk about those that don't. So we'll cover, kind of, run the gamut. So we're going to talk about ones that don't have any active contrib modules. We'll then go into, kind of, split the integration or the non-profit CRM integration into two things, ones with light integration and then ones with deep integration. And then following that, so that's kind of more of a survey of what's out there. Some of that you guys may or may not know, but I kind of compiled it all from what's on d.o. And then after that, we're actually going to do deep dives. Sorry? OK. Come on up, people. Come on up. Come closer. It's a giant room. Please come to us. Or don't. After that, we're going to do a deep dive into three things. Chris is going to cover the Convio integration that FreeFlow has done. I'm going to talk about springboard and Salesforce integration. And then Sean is going to cover, as he said, native CRM and Drupal. And then after that, we'll do some questions, and we'll get the hell out of here. Sound good? All right, so before we get started, how many people are working at a non-profit organization? All right, lots of non-profits. How many people are here from a shop that works with non-profits? OK, so lots of those. And about how many people are developers? Lots of developers. And then how many people are just kind of business user type, administrator types? OK. All right, so we're not going to get too deep into code. I don't think we can. But time is not going to allow for a lot of that. So if you want to talk code level, hit us up after this. We are going to be showing some front-end stuff. We'll be showing some admin interfaces, and we'll be talking more around integration. How many people are still hungover from last night? Yes, excellent. Thank you. All right. Well, without further ado, let's get started, shall we? All right, so the first set of CRMs that we're going to talk about are ones that don't have any active Drupal contrib modules. ActionKit, how many people are familiar with ActionKit? So this is basically the people that built the MoveOn platform. It's used by organizations like 1.org. I think there's a variety of organizations. And just recently, I would say it's the last two years, year and a half, they actually started selling it as ActionKit. There is an API. So there really isn't really a reason why there shouldn't be a Drupal integration with ActionKit, but it's probably just one of those things that someone's never built it or needed it. Is there one using ActionKit? No ActionKit users? OK. BlackBot Sphere, also known as ContaraSphere. Everyone familiar with that? Heard of it? There is no Drupal integration. They do have an API, but there is nothing on Contrib to integrate BlackBot Sphere with Drupal. I'm pretty sure people have done some integration work, but at least as far as I know, it hasn't been contributed back to the community. Is anyone using BlackBot Sphere? OK. And you have Drupal sites as well? Razor's Edge. OK. So Razor's Edge is more of your offline donor management, Sphere would be your kind of ECRM net community, which integrates with Razor's Edge. That is an alternative to Sphere. It's a little less full-featured. It's more about fundraising forms. And then BlackBot has a new Enterprise CRM. Anyone using that? Probably not, because as far as we can tell, it's paper. No. Yeah, it's unclear where it is in the space of development. I know that they're selling it, but I don't think we know of anyone who's actually launched on it. I think they have one or two works that have. This is where they're moving. So I think it's, I don't know that they'll get rid of all the other platforms, but this is the direction that they're going in, which is Enterprise CRM. So those three are pretty large CRMs. I'm sure there's a bunch of other CRMs that I'm not going to touch or talk about. So if I miss any, don't hold it against me, there's a lot. So let's talk about CRMs with light integration. So engaging networks used to be called advocacy online. They rebranded as engaging networks. They're very popular in the international space because they do international advocacy. And there's very few of these CRMs that have any kind of international advocacy platform. So they have an integration of sorts. We actually built it as part of our International Fund for Animal Welfare project. And it integrates with their advocacy tools. And we'll get into some of the features of that. And then Convio online marketing, not to be confused with Convio Common Ground or Convio Luminate, this is their sort of ECRM platform. There is a Drupal Contrib module. I don't know how many people are using it. Convio people here, you're using it? The one that's on Contrib? OK, great. So she would be good to talk to you. So for the engaging networks, this is a summary of what you will find on d.o. But these are the things that it integrates with. So engaging networks is really just designed to handle the advocacy portion. It does pass. So part of what it does is it sucks in the engaging networks campaigns, renders them as Drupal web forms, and then those submissions are passed back to engaging networks to fulfill the advocacy message to target. So I have asterisks on users' nodes and other objects because it's really not a deep user integration. It's not a two-way sync. We're literally just passing it off to them. You can find this module on d.o. It's feel free to download it if you're in engaging networks. Anyone using engaging networks? OK, well, there you go. On the Convio side, so Convio has an integration API. There is only a 6x version of it. For whatever reason, the installs aren't reporting back to Drupal, so it's tough to tell what the install base is. I think this integrates with their REST API. I'm pretty sure it integrates with their REST API rather than it's not a SOAP-based integration. And I think it handles users. I know that. I don't know that it handles anything else. So no node integration, no order or fundraising integration, and no custom objects, just users. And theoretically, you can build. And Chris from FreeFlow will talk about their integration with Convio, but they do have a donation API. I think they have an advocacy API. So they have other things that you can do. They funded the development of this at first, and then I think it just died on the vine. So I know there's a lot of Convio users, theoretically, out there. And there's a lot of those shops that are also using Drupal. So I'm sure some added energy around development there would be good. So now we're going to talk about CRMs that have a little bit more robust integration. And we're talking about four. There are probably, as I said before, other CRMs that we're not going to cover here. But I think we're getting the bulk of them. Netform is an association management system, or AMS. It's built by a Vectra. Is there anyone, Netform people? You're a Netform user? Netform, OK. They actually have a variety of modules, and we'll go into that. Salsa, I'm sure a lot of people know who Salsa, Salsa Labs, Salsa is a CRM wired for change, democracy and action. All of that is actually Salsa. They have an API available as well with a proprietary scripting language. And there's actually, again, multiple modules that power the Salsa integration. CVCRM, can't talk about CRM in Drupal without talking about CVCRM. So of course, yes, we will talk about that. And then Salesforce, which is near and dear to my heart. We do a lot of Salesforce integration. There's actually contrib modules, but we also have our own, as part of the springboard, distro that handle the integration. And that's actually the one that we're gonna talk about today. They have a very robust API, well documented, easy to integrate with. And the other thing that's good is they version their APIs. So in terms of Netform, there are, and someone's gonna have to help me out with this because I went through this, and I still don't understand exactly what all these modules do. But they have what they call their X-Web interface. Dynamic facade nodes. They have authentication, which I can only assume is single sign on. And they have Netform views, which as far as I can tell has been deprecated. There's about, according to d.o, 60 sites-ish that are integrating with Netform. It's unclear to me, or even in the documentation, all of the things that it does, but I know that you can sync users and you can actually render Netform content in Drupal. And the dynamic facade nodes powers that. The user sync is powered by the authentication. It looks like they're doing a 7x port. It's not ready for prime time, but they have 5x and 6x versions. So it's been around for a while. Salsa, you have two options. So the first three bars in this chart are all related. The Salsa API and Salsa rules and Salsa supporters, they kind of go together. And then there is a Salsa integration that was built a little bit later. I think by Trellon, could be wrong. Someone here from Trellon confirm that? So if you're running Salsa, you have two options available to you. It looks to me like the API is the only one that's making a port to seven. So if you're running a seven site, you're probably not able to integrate much there. It integrates users. I know that. And then the Salsa integration module integrates nodes as well. So it's a little deeper than just users. Outside of that, it's unclear to me what they're doing. And if someone, well, so later when we get to Q&A, I would love it. Is anyone using Salsa and integrating with Drupal? Okay, so it would be good to hear, might be good to hear what you're doing and how it works for you. I did, so when I was doing this, I sent out a lot of emails and tried to get people who have done this stuff to come and present, but there wasn't a lot of response. So, so what? CIVICRM, so CIVICRM, there's six X, and there is a port to seven X. According to D.o., there's only 25 sites. That doesn't, I mean, that doesn't actually compute. I'm sure there's a lot more Drupal sites integrating with CIVICRM, so I don't really trust that number. But CIVICRM has been integrated with Drupals, I think, since the beginning, or if not shortly after the beginning. And it's a very tight integration. Users nodes, I think CIVICRM actually renders all of the forms and stuff, so technically that's not integration. It's just CIVICRM handling the forms, but it will, you will be able to integrate users and nodes into CIVICRM. I don't know if there's really custom object support or if that kind of even exists in CIVICRM, so hard to tell. And then finally Salesforce, 351 sites running Salesforce, which is surprising, I was very surprised by that. And that doesn't include the stuff that we're doing on Springboard, and I'm sure there's other one-off integrations. And I really here focused on the Salesforce suite of modules. Is there anyone using Salesforce and Drupal? Oh, I know you are, Marcus. So yeah, you can integrate pretty much anything in theory, and there's a lot of hooks for the things that aren't out of the box. There's a very nice user interface for field mapping to power your integration, and it's very full-featured. And we'll actually show, so when we do the, we're gonna talk about Salesforce integration later, we're actually gonna show Springboard's integration, but it's similar to what is in Contrib in some ways. And then the idea is that the seven version of Contrib will have the features that aren't there in the Springboard thing. So right now there is a port to 7x. It is, it's not really ready for prime time, but you can get it up, you can stand it up, you can sync users, you can sync nodes with the 7x port, but it's definitely a little buggy. I think of the 351 sites, there's something like 80 that are seven, so it's not that people, people are using it, so good to note. All right, that ends the overview portion of our, how's it going? I'm enjoying it, isn't it fun? Riveting, right? This is why we gave you beer, people. All right, well let's, I'm gonna turn it over to Chris and he's gonna talk about FreeFlow's Convio integration and show kind of the stuff that they've been doing. This actually doesn't have reached full day event for nonprofits that are interested in Drupal, there'll be a lot of talk about CRM there as well. So if you can head down to San Francisco for that, right now we've got about 100 people participating. It should be a really good full day event. Okay, so here's the Convio APIs. And we integrated with the donation, which is client-side only, and then we also have some into, I don't know if it's advocacy, I think it's constituent, which is server-side. So, and unfortunately, we have a couple modules. They need to be cleaned up before they can be submitted to Drupal, there's still some hard-coded stuff in there because this was designed as a one-off that we realized could be used. And Convio has changed their client-side authentication so that we have to completely rewrite. It still works, but there's no point in submitting something that's going away soon. So we have that to do. What we do with this, so it's a Drupal 7 site, it's just running a commerce kickstart with products and it's a regular store. We've added some configuration and you get all this from when you sign up with Convio, you go in and there's a password in here as well. It's obviously blanked out for demo purposes. What they've gotten rid of is the cross-domain script file and I believe the API library URL, they changed how they do that. But initially, you had to download some files to your site and that's gone away. So I guess what we do here is you go to the store, you purchase something and we've written a payment gateway for Drupal commerce that will, through AJAX, will submit it to Convio. It'll get the response back, will then process the form in Drupal saving all the, we blank out the credit card information and then it saves all that information to Drupal. So you know what, somebody bought and everything but the processing is done through your Convio account and then because there was some constituent data that you couldn't access through donation APIs, we turn around and we make a server side call back to Convio to update the rest of the record. So it just works, this is just a regular kickstart commerce, Drupal 7, add to cart, you can go to the shopping cart, you check out. Yes, it does, yes, so you create, right, and there's some, yes, there's a shadow form on the backside on Convio that they all get sent to. It's in the configuration and we can take a look at that in a moment. Yes, I typed this in a lot, that's why it's all automated. And so we've now completed it, it's been processed by Convio and everything's been updated in Drupal and, right, so let's see configuration, the donation configuration. So here's the donation form ID and the other Convio information that you need to set up. So you set that up ahead first time and then it passes that back and forth. So is the user integrated or not? There, yes, so that's part of the server side callback afterwards is we then update the constituent record on the, but you can't do that through the donation APIs. So that's why we have this weird two step approach. It's actually a three step because Convio, Drupal, Convio, but that's how we get everything updated. Right, it's on your domain and it sends it through the Ajax call, so there's a, oh it's the JavaScript, that would help. No, what we're, so as if you see here, this is after we get it back from, the response back from Convio, but here it's commented out so that I can just run these without actually sending them through, I just fake it, but here you get the key and you send it and it goes to their, through a secure Ajax call. So it goes over SSL to Convio, it comes back, we wipe out all of this data and then we submit the form to Drupal. You're definitely in scope of PCI, oh yes. So you would need to, if you want to be PCI compliant, you would need to get this game. We're not saving, the credit card's not saved on your site. No, but it's being entered on that page. But that page is submitted through SSL, doesn't, okay. Okay. But it'll be, there's different level of things. Right, that's what I, because they, right, they're only customer, it's only client side. Actually a PCI session. Right, well, and the other thing I know that Drupal Commerce does not, Drupal Commerce also blanks out the credit card information and they don't store that just so that they could get around that same issue, that it is never, the credit card information is never stored on your server at all, right. And by the time it gets submitted to Drupal with this, we've already blanked it out as an extra step. Anything else on this? I guess we'll pass it over. Yeah, do you want to get, do you want to do yours? Sure. Yeah, go ahead. Awesome, cool. So I'm going to talk about native CRM. You could talk for way more than 10 minutes just around what's going on in the community. And I'll probably have to sit by saying that like, right now there are a number of kind of competing efforts, which I think is a really good thing towards, wow, that's an interesting resolution. Towards getting CRM running natively in Drupal. So, I'm going to get resized to the right side, so at least, just one second. Hey, Lev, do you want to do this while I talk? I'm bringing up my Vanna White here to help out with it. So I'll talk about it real quick while Lev gets the screen running. Thank you, Vanna. You'll have to come up here. Cool, all right, so, native CRM. So, the first question is why would you want to do CRM natively in Drupal? And also, why hasn't it been done really successfully before Drupal 7? Why you'd want to do it in Drupal, a couple reasons. One, a lot of them we've actually talked about. If you really want to kind of control that workflow of a user interacting with your website and having association management tools running, you have a lot more control if it's all in one system. Another thing is, we talked about some of these APIs with different CRMs, sometimes being fragile. That is why he is my business partner. Sometimes APIs change. If you have it natively in Drupal, you don't have to worry about that quite as much. So then the question is, why hasn't this been done before Drupal 7? Effectively, and the answer is the entity system in Drupal 7. As we go here, we'll show you what we're doing and what most of the movement in this is doing is creating custom entity types for contacts, as well as relationships and memberships and things like that. So there's a lot of benefits to it. And from our perspective, it can kind of lower your costs for getting into a CRM for lighter weight solutions. And then for folks who are integrating with very large solutions, it can provide sort of a nice kind of intermediate layer. We're doing this mainly for a couple different clients that are on Salesforce. And so if we can store stuff in Drupal natively and then we can ship it off the Salesforce, we're not quite as reliant on Salesforce for authentication and for kind of checking permissions on the fly all the time. Also one of our distributions that we're working on for foundations right now needs to integrate with two third-party CRMs. So having all of those objects natively in Drupal provides a level of abstraction so that we can talk to multiple backends at the same time. So Red Hen CRM is our open-source solution. It's all up on Drupal.org at Project Red Hen. And then cool, so it looks great with this on this right up here right now. But here's what we have so far. So it's still an active development. We have, if you go to the Red Hen project page, there's a link to a demo installation profile that we've built that demos that builds this right here which is just kind of a quick demo of a fictional pet association of pet shelter organizations. So a couple of things that we're doing here. One, we have two different entity types, one for organizations and one for individuals. And then using the entity system, you can build your own bundles for each of those types. So one thing, for example, in terms of contacts, just as kind of an example here, we have a staff bundle and then a volunteer bundle and they can have different fields, which is kind of nice because different types of contacts that you store data on, you might want to store different fields. You could also handle that using conditional fields or something like that if you wanted to have a single bundle. But we provide some flexibility around that so there's opportunity to do both. Then what we're doing, and this kind of sets us apart from, I should actually mention, the two other kind of big efforts that are going on for Native CRM and Drupal are the party module, which is built on profile two and is kind of the CRM API group on Drupal groups. That, it's a great effort. It's very tied to, from our perspective, it's very tied to user accounts. And also it's really kind of based around doing a lot more in configuration. We're really targeting building solutions, a framework that other developers could leverage because we want stuff not to break for our clients once they, and we want our system to be extendable. So we're doing a lot more in code, as I'll kind of show you. The other effort that's going on is the Trelin has CRM Core. We're very similar to CRM Core in that they're reliant on custom entity types for contacts. They actually have one entity type and then they have a bundle for households and a different bundle for organizations and contacts. We're a little bit different in that we have two different entity types for those two things. The big difference between what we're doing, I think, and what CRM Core is doing is that all of their interfaces are built with views. And that is a big plus if you want to pass off a solution and have your customers or site administrators be able to really quickly add fields to layouts and listings. That is a con in our opinion if you want to create a really vibrant contributed add-on space because as soon as someone overrides a view, if another view through features overrides or whatnot goes in there and adds another column to a tabular listing, all that stuff breaks. So I don't know how many of you guys have worked with features and it's really wonderful. I'm not sure if many of you have kind of banged your head on it, but trying to get different views exported stuff to work when you build on top of it gets really kind of fragile really quickly. Yeah, well I mean it does unless the original feature is overridden in the, it does if one feature is overriding, if one codified feature is overriding another codified feature, it works great. But the whole point of having views is to give your client the ability to override views in the database which renders all that stuff moved. If the goal is actually to write, to extend code with code, why have that intermediate level of having features and exports? At least from our opinion. So what we're doing is actually leveraging entity field query. So this is a list of contacts that we have right here. And we're doing some interesting stuff. So right now we have a real basic search. This is just some custom code that we've abstracted on top of all of our different listings. And what's kind of neat is that we can go in here these different bundles, say staff. And then does an Ajax callback to find all the fields that are on that entity type, or that entity bundle to find the unique one. So staff, I haven't done anything, it just has an email field. But volunteers, I've added a text field for availability. And because it's on that bundle, it automatically shows up. Which is really pretty slick if you're gonna give the ability to your site administrators to add fields. And all CRMs kind of need to do that. But now they don't have to worry about views, editing views in order to get that stuff to show up as filter options. So I can just type in here Mondays. Not sure if it's a, yeah, there we go. Cool, so then on our contacts here, we have summary information, we have another custom entity type that lets us create connections. Same kind of paradigm, we have different bundles that a site administrator can build for different types of connections. And those different bundles can have their own fields, which is pretty slick. And that's just using the relations module. Memberships, same paradigm. We've got a custom entity type called membership that can be extended with as many bundles as you want. So different types of memberships can have different fields available to them. As well as the fact that since we're using an entity API module, we get the view support and we get the rule support. So if you wanna do really awesome, like provide different discounts through Drupal commerce based on membership rules, interacting with these membership entities, you can do some really complex business logic. So for really tight association management features, this works really well. Then one of the things that we have that we're pretty darn stoked on is this concept of engagement scoring. So we have an API built that lets you create engagement points for different types of interactions with a site. So real quick kind of example of that is we have a note system and I can add a note for Lev here. I can choose what type of note and this is using taxonomy so it can be extended really easily. I can say that I'm taking a note that's reflecting a meeting that we have. And then we can give that note, we can track that by giving an engagement score. I'm gonna say this was a high value engagement and this is all configurable. You can create your own types of engagement, give them different scoring algorithms, things like that, integrate these algorithms with rules if you wanted to down the road. We're not doing that yet, but we could. Now I saved this note and if I go back to engagement, I can see I just gave him 10 engagement points for that interaction. So you can see how this could get really cool with dealing with unauthenticated users. You could say if someone leaves an anonymous blog post, a comment, and they leave an email address, go look that email address up against your CRM and score it and track engagement that way. Or if you have a Twitter handle in your CRM, go out Twitter, pull a hashtag or a different Twitter account that you're looking at to see if they're retweeting it, give them scores for that. So some of that stuff we're gonna be building soon, it's not all there now, but the basic framework is there to extend this in those kind of ways. And then finally, something that's really important to our users is registrations. So we have a module called entity registrations, project's name is just registration to make it confusing. But this is basically an entity-based version of the signup module for Drupal 7 and lets you do both authenticated and unauthenticated registrations. We're integrating it with Drupal Commerce in the next month as we are integrating our membership with Drupal Commerce. And what that does, and again, it's really neat because we can key off email addresses. If someone goes to your site and registers for an event anonymously, but you have their email address in your CRM, you can give them discounts on the fly, even if they're not logged in, as well as track all those anonymous registrations to their account. So you're really lowering the barrier for people to engage with you and actually track meaningful data with them. You could get pretty big brother here, too. Someone makes a comment on your website. You figure out who they are based on their email address and then you can start tracking them on your site through their session ID. You can start to get some really interesting data there through engage with these folks. And again, entity registrations just working right with... This isn't necessarily part of Red Hen, but being able to just make an event, open it up for registrations, be it the track registrations, set registration limits, things like that. So what we're doing here, really, I think the real value of having this stuff natively in Drupal is when you wanna build these association management tools, where the integration starts to get really, really expensive sometimes. Cool, let me see. Lev, did I miss anything? Oh cool, oh yeah, the last thing that people ask about is how does it integrate with user accounts? So we have the schema in place right now. We're gonna continue in kind of a contrib space, like flesh this out even further, but right now what we're doing is that when we save, and we have an API for this that we're calling on entity save here for these contact entities, but what I'm doing is I'm going in, I'm gonna save this contact record. And when I save it, we're just gonna look up and see if there was a Drupal user account that has the same email address, and then we tag that user account with it. And then we can go in there, we're gonna keep fleshing this out. We can go in there and we can actually say, well, let's not delete that connection, but that's the wrong connection, so we can unlink those user accounts. And then finally, the only other thing that I'll show you real quick, and then I'll shut up, is working a lot on the ability to archive contact records, as well as to archive organization records, archive memberships, and things like that. The membership management stuff, we're gonna be continuing to flesh out a lot in the next month, because you get into some really crazy business rules. We can manage organizational memberships, and then we can cascade that to members who are connected, to individuals that are connected to those organizations, which is really cool, and opens up some really neat opportunities to do things like apply discounts based on someone's membership, if it's a personal membership, or if they're associated with an organization that has a membership, and things like that. So some of that really complex business logic, again, I think it's pretty difficult to do if you're integrating across third-party CRMs. But again, we're a little bit biased on that, so definitely not a replacement for stuff like Salesforce. There's a lot of stuff that you can do in Salesforce in particular, and we really recommend it to a lot of our clients, that you would never be able to do in Drupal. We're not gonna integrate red-hand CRM with Outlook, or your desktop applications, or any of that kind of, we're not gonna integrate with your accounting package, Google Apps, things like that. So there's definitely, this is one tool in a very large toolkit that you need if you really wanna get going on this stuff hardcore. So we're doing a bop on this tomorrow. We'd love to dive into some code with some folks, and kinda work through some things, get some, if there's features that folks wanna see us prioritize, or if they wanna engage in the community, that would be rad, we'd love to talk to you about it. No, I wouldn't say that. I would say that, well, we've got three clients that are launching on it within the next two months, so we have to be pretty darn close. It's kind of a unique model. We have three clients that all invested a collective 500 hours, billable hours into this project, so it's really being driven by those needs. We can't really fail, like it's not really one of those things that as a company we can handle. So there's a lot of pressure to get it done and get it done really well. The stuff that we have right here works pretty darn well. If you just wanna start tracking data, the integration with user accounts and the integration with commerce is not there yet. But we've got three folks working on this pretty much full time right now, so the development's happening really rapidly. No, it's an interesting thing. It's a long conversation about a community engagement, and we want community engagement, but it's really hard to be dealing with bug reports that are coming in because we tagged a release and stuff like that, so we're just kind of accounting on folks who can download the code via Git, engaging at this point, and we'll engage with a wider community as soon as things get a little bit further along. Musical laptops. So I'm gonna be talking about our Salesforce integration and touching on our Drupal distribution called Springboard. If you want to download it and try it out, you may do so at ghostspringboard.com. It's all up on GitHub. There's also a Drupal.org project page at I think project slash springboard, but ghostspringboard.com has all kinds of stuff. So I'm gonna walk through the International Fund for Animal Welfare as an example of how they're integrating with Salesforce on their site. Pretty unique sites, multiple currencies, multiple languages, sites that are regional based so that we have multiple sites with the same language which in Drupal, IETNN is not great, but it's where I'm doing a bunch of things to make that work. And so if I go into the U.S. form, if I get a donation form in the U.S., you know, I get credit card and PayPal. If I go back to, if I do the UK, I get direct debit, PayPal and credit card and impounds. So, you know, fairly complex requirements around currency management and languages and it makes for some complex things, not just in Drupal but also in Salesforce. So in Salesforce, to handle multi-currency, you actually have to install, you have to get the support people to install multi-currency and enable it for you. And all of this stuff happens on the Drupal end, gets synced down to Salesforce through our integration. So anything that a user does online, whether it's donate or take action, all of that is happening in Drupal. And we have a variety of field maps and we go ahead and open up the field map so you can see how this kind of plays out. So every, all of the donation forms and action forms are actually web forms and all of those submissions are then synced down into a variety of objects. So donations go to opportunities, web forms go to a custom object called actions, so action forms. And then we also have user field maps for contacts. So if I go in here, you can just see how a field map between the two systems works. There's the Salesforce field name here, the Drupal field here, which you get to pick. We have some business rules for how to handle the data going to and from Salesforce. So you can choose if you're gonna overwrite it or not overwrite it or only overwrite one blank. So all of the objects are handled through field maps. There's also some hooks for if there's other complicated things that you need to do to extend the integration. There's hooks where you can extend those by their objects or the data that gets passed or you can have rules. And when the system collects all this stuff on Cron, it will batch up all this stuff, put it in a queue and sync it down. And so we have a variety of, let me just bring up some of the queue reports. So how many of you actually use Salesforce? Salesforce people? And have you hit your API limits ever? Integrating with Salesforce? Yes. So that's because if you just sync, if you do a lot of volume, and this is I fall, they don't do a ton, but they do enough that when they do an action they could definitely go over their API limits. So what we do is we batch up all of the like items, put them in a batch, and then we sync it down. And then we have this report where you can tell when the sync happened and how many items were a success or failure. And then you can actually click through. So if there was a failure in here, I could find it and I could fix it. And that gives you all the details of what was sent down to Salesforce. We also have a retry queue. So if something does fail, you can go in here. It will wait a day and then retry it. It assumes that it failed for any one of a number of reasons. There could be bad data that needs to be addressed in the record. If Salesforce goes into maintenance mode and Salesforce is down, then you're not gonna be able to sync up with it. There could be network connection loss. So we wanna make sure that that data gets captured and then synced when we're able to sync it. If I do nothing, this will all get synced based on this retry date. Or I can re-queue it now. I'll just click on my little retry link and I'm unable to, excellent. Perfect. And then finally we have a permanent failure. So if it retries three times and then it can't sync it, then we stick it in this permanent failure queue and you can bulk retry all of them in the queue or manually retry them then. There's a few other things that we have baked in. So if you, there's some rules integration on the integration itself. So based on whether something has happened. So in this case, if an object fails to export to Salesforce, we have a rule that will fix the last name. So in Salesforce, last name field is required on the contact object. So if you have users that join your site and they don't put a last name in, it's gonna fail on the sync. And we actually have a rule to handle that. Most of the forms will require it, but if the client decides to create a form without last name, they just have email address on it. We've created this rule here that if it fails to export and the last name field is blank and it's a user, then we go in and we update the field and then we add it back into the queue. So it kind of automatically handles data issue or common data issues, and it's totally configurable. So not every organization has the same problems. So you can configure these based on how your sync, what you learn from your sync as you go. What else should I talk about integration wise? Oh yeah, we can go into a web form. Sure. So our integration is a little bit different than what's on contrib right now. And one of the things that we do have is a really robust web form integration and part of what makes it awesome is, let me go here. So this is actually a donation form. This isn't actually a good example, but in donations you can map all of the fields from the form and we preset these fields too. So the maps are already built when you create the donation form, but you can map any field on the web form to the Salesforce opportunity. So if you create custom fields on your donation forms, you can either map them to the opportunity record or you can map them to the user. So if you add a how did you hear about us field, that would go on your user profile. If you added a what t-shirt size do you want or do you want a gift field, that would go on this side. So there's field maps on web forms, field maps on donation forms, and they're a little bit different. Let me just go back to web forms. Here we go. So this is a petition form for the Netherlands. So, and it's in Dutch, which is gonna make this really awesome. So there's a couple of things that you can do with web forms. One thing is that you are able to, so these aren't even getting synced. So I can choose my Salesforce object that I wanna sync to and then it gives me all of the fields and then I can select the fields that I wanna sync down. You also get things like the node ID, the node title, you can sync down the submission ID and the submission date, which is also very helpful when you're getting web form data down, because you wanna know when they filled out the form. So it exposes all of the form fields as well as metadata about the submission and the node itself. Let's go into Springboard and Salesforce. So Salesforce's API is a SOAP-based API. So you need to upload a WisDL that describes all the objects. There's a handy dandy place to do that. You can also set the queue processor order in which the objects get synced down. You can also set batch sizes and things like that. So it's fairly configurable. And I think that's probably, yeah, about it. So why don't we just real quick. I don't think we have, oh, let's show the kitty. All right. Does anyone have any questions? Yeah. Step up to the mic, my man. So like I mentioned earlier on, we're using Razor's Edge and it's a whole mess that it has to go through Net Community. So our website is Drupal and when you wanna donate, we have to forward you to a one-page donation form that's on Net Community. But now we want the two to talk to each other, which by the sounds of it, is not really possible. Well, Drupal to talk to Razor's Edge or? Well, yeah, I suppose Drupal to talk to Razor's Edge and then Razor's Edge to talk back to it. I mean, I've tried to do a bit of research on this, but I mean, seeing as how that kind of falls under your, I think everybody that deals with Blackboard has a problem. Yeah. So what would your suggestion be if you're on one of these CRMs that just seem to fall into that list of... Yeah, no, we run into this a lot and my suggestion, honestly, is to use Salesforce as kind of the intermediary step, because then you can integrate Salesforce to Razor's Edge, which would be a much easier task than trying to integrate your Drupal site into your Razor's Edge system. And do you know what it's like migrating your data from Razor's Edge to Salesforce? Oh, well, I think they can peacefully coexist. So I'm saying you would keep Razor's Edge as donor management, have Salesforce running as just your ECRM platform. You could send emails from there. You could do a bunch of things on that piece. And there's lots of options for integrating Salesforce and Razor's Edge, whether that's, whether you do it with like an ETL tool or whether you're doing like file-based loads with just something like Data Loader, there's lots of options available in that space. So would Salesforce kind of take the place of net community? Yes, Salesforce and Drupal would take the place of net community. Drupal would take the front end place, Salesforce would take just the data storage and segmentation place. Okay, great, thanks a lot. One of the recurring headaches that we run into is contact merges. People create multiple users. When you start looking at the syncs, obviously syncing inserts, updates, deletes, the basic operations seem pretty straightforward. Do any of these integrations or syncs do a good job of dealing with contact merges? Yeah, so for the, whether you're using the Contrib Salesforce or Springboard, we sync and the Contrib, you can actually create your own pre-matching rules and it's fairly configurable. In Springboard, we sync down, we have a Ddupe key and you can set it on a field map. So for contacts, it's almost always email, but a user can go in and add another contact with that same email into Salesforce and now you have your duplicate. So what happens on our end is we put a trigger in in Salesforce to prevent that. So we have an Apex trigger that we use that will prevent duplicate contacts from getting created. If they do get created, there's lots of merge tools you can use. You can either use regular Salesforce native merge, CRM Fusion, if you're a Salesforce user, they give that stuff away to nonprofits and that's really powerful tools, especially for things like Dduping and Merge. Once you've merged your record on the Salesforce side, depending on which one was the keep record, you might also need to clean out the Drupal side. So we have a utility that allows you to kind of clear out the Salesforce data on a user or on a batch of users. I think for other systems, it's gonna depend on how that system works. At least in Drupal, you can always rely on the fact that users are unique on email. So you know that your starting point is gonna be unique on email. So with Salesforce, you would Ddupe on Salesforce and then kind of wipe them out entirely on Drupal and then resync down. Yeah, you break the connection in Drupal and then it gets resinked and merges into that existing record. Yeah, we call it Wipe, which is kind of gross. I came in a little bit late, missed the cell support of the presentation, but just wanted to let everyone know that the Dormant Salsa API and Salsa Supporters modules are under development again. And there is some early code in the 7x Dev Branch for both. And we've got two sites going live in the next month, so there should be some much later code being posted in the next couple of weeks. And Salsa Supporters specifically will now sync to two profiles. And the ultimate goal is to have any Salsa object synchronized to any Drupal entity. Awesome, awesome, that's great news. I am looking for collaborators. Beard here in Switzerland and I are working on Salsa API, but looking for other collaborators and other use cases to work on. So. Are you working with anyone at Salsa as well? Yes, we're working with Salsa Labs. We're based in Washington DC, so we talk to them on a regular basis. Okay, awesome. And do you know what the difference is between those modules and the Salsa Integration module? I know that the Salsa Integration module kind of sort of works. I think there were some changes to Salsa's API that broke some things. And they don't, this is the Trellin module? Yeah. Yeah, I don't really know much about what the current status of that module is. I know that the person who created that module for Trellin is no longer with Trellin. So I think that they are more focused on CRM core at this point. Yeah, okay. Cool, that's great news. Thanks for that. That's a good update. Well, around the subject, we have revived also the net forum views, the deprecated net forum views integration as part of a project that was basically a work for hire for a Vectra. And right now it's not on Drupal.org, but we're working with Vectra to hopefully bring that to light. It actually is a views three query plugin that allows the Vectra's X Web API to be a data source under views. So you can just build dynamic queries. From the net forum product. So hopefully that'll be around pretty soon. We're trying to convince the folks at Vectra that it's a great idea to get it out there in the community. Yeah, no, that's a great thing. And a great use of views three too, since you're gonna have the different data sources. Any other questions, comments? We're out of beer, a lot of people left, I think. And I think we're at the end. So if you guys would, locate this session on Drupal.com Denver website. Oh yeah, click the take survey link. Thanks so much for coming to the session. We really appreciate your time and I know it's late in the day, so you'll get your drink on and your snack on or whatever you're doing. And we'll see you around.