 All right, let's go ahead and get started. Thanks for joining us this morning, everyone. I'm sure it's been a long week and a late night. So I appreciate you making the effort. Is that good for volume? All right, wonderful. So we're gonna talk about a few different integrations that we've had the pleasure of working on in the Drupal space. And we're kinda using a bit of a storyline of telling the story of three different integrations, seeing what they had in common, what didn't work, and kinda talk about a little bit why Drupal is a really great platform for doing these types of third-party integrations. So before we dive into the fun stuff, kind of a little bit about us, so I'm Lev Zippin, I'm the CEO and co-founder of ThinkShout, and I'll be joined in Acts 2 and 3 by Talna Hogue, our CTO, and Gabe Carlton-Barns, our engineering manager. And so we'll each kinda talk about a different product that we've been able to integrate. So first, a little bit about ThinkShout, so it's kind of a few core things that we identify with. Number one is who we work with, so we work almost exclusively with nonprofits and mission-driven organizations, and it's really kind of a big part of who we are and what we do. So a lot of our integrations, while we design things to have a really wide array of use cases, it's one of our kinda core philosophies that we'll talk about a little bit more that we think leads to successful integrations, we do target a lot of our work, a lot of our open-source contributions towards the nonprofit sector. So we offer a full set of services strategy, user experience design, development, and support, like most other shops do, and one of the things that we're really most proud of is that our over 60,000 websites are running on our open-source contributions, and we'll kinda talk about three of our most popular modules that are included in those numbers as well. So our philosophy is always that in our work with our clients, we try really hard to abstract any of the work that we're doing into reusable building blocks that we release to the community, we leverage those tools in our work, and a lot of grassroots organizations that maybe couldn't afford to work with an agency like ThinkShout, they can then leverage those tools on their own or with smaller, independent contractors, and we think it's really one of those great situations because our clients, they get their sites based on widely adopted code bases as opposed to a bunch of custom code that was written just for them, which as you all know, can be really difficult to maintain. The community gets a well-maintained contribution, and it's not poorly altruistic. ThinkShout gets some lead generation and marketing, of course, by having those tools be out there. All right, so I'm gonna start off and talk about Mailchimp, our favorite email service provider. So full disclosure, Mailchimp has actually been a client of ours for some time, and I'll kind of tell you how that started. We've been co-marketing together this solution for over five years, so we try to be objective, but I thought it'd be good to disclose that. So like every good story, the one about us using Mailchimp does have its origin. So back when I was on my own, so before starting ThinkShout in 2011, I had my own company kinda do an independent work for a number of years, and I had a case of what I used to call Shiny Object Syndrome, so there wasn't really a, I never meant to start up, I didn't like, and I had all these different side ventures, none of which went anywhere, but one of them did have a need for integrating with an email service provider. So this was back in the Drupal 4.6, Drupal 5 days, and I wrote out the Mailchimp integration with Drupal, and the project was actually, it was something called Mom Hub, and it was like a Google Group's clone for parents to organize playdates. I just had my first kid, so it seemed really like a fabulous idea at the time. Not around anymore. So I wrote out this integration, I did a little research, Mailchimp seemed like a really great email marketing platform. They had really cute monkey stuff, I liked it. And Mailchimp, that was kind of the start of its rise, and it quickly saw meteoric growth within the email marketing space. Drupal was also seeing its own tremendous growth, and those two kind of forces together made the module all of a sudden become more prominent and grow, and I was on my own, and I started getting pelted with support requests constantly. Like, oh, can you help us do this? Can you add that? You guys know what it's like in the Drupal issue queue. And as an independent contractor running my own business, it really was not something that I had time for. In addition to my client work, and as I mentioned, having a new kid as well, so I reached out to Mailchimp back in the late aughts, and to their credit, they had the foresight to see what this partnership, sorry, they had the foresight to see what this partnership could lead to. And so yeah, when I reached out to them right away, they're like, yeah, that's a great idea. We'll definitely support you, and we can work on this project together. So starting back then, we basically had an arrangement that we more or less have still today. They pay us kind of on a monthly basis to basically support the module, and then we do more structured project work to do major feature enhancements to Mailchimp. So adding different tools. Over the years, we've added things like activity reporting and the ability to send campaigns and really enhance the power of the integration. And we'll kind of talk a little bit more in detail about those different features. But so we kind of in parallel support the community and the module. We respond to bugs in the issue queue. We're constantly doing minor point releases to make sure it's up to date. And at the same time, we're doing major new feature enhancements. So for example, right now, we're doing Mailchimp has a big priority to focus on their e-commerce integration. So be able to basically close a loop like when you send out an email, promoting something you want to sell, and then kind of closing the loop from when you actually sell it on your website. So that's something we're really excited for that we're working on with them right now. So the basic structure of the integration, it's we have always kind of taken a layer cake approach to our modules. So with the goal that you only should be using the code that you actually need. So the Mailchimp module is broken down into the underlying base module which manages authentication and communication with the Mailchimp API. So if you're a developer and you want to do your own custom Mailchimp integration and you basically want to just authorize to your API key and write your own code, you can just use the really lightweight base module. And then built on top of that, we have a signup module which exposes what you'd expect your basic signup forms. And I'll talk a little bit more of that in a subsequent slide. We have a list module, which is one of the more powerful features of the suite. And it allows you to basically synchronize one or more of your Mailchimp lists with one or more Drupal objects. And again, I'll talk more about all of these later on. Activity which tracks all of the email activity for any entity with an email address and the ability to send campaigns natively from within Drupal, embedding Drupal content in those campaigns as well. So you can use one or more of those and you don't have to use all of them. All right, so diving a little bit more into each of the features. So subscription forms, this is like the most common use case with an email marketing platform, right? So you want people to sign up for your newsletter and we provide a lot of ways to do that with the Mailchimp module. There's, I'm hopefully gonna have time to do a real quick demo, but the way it works is that all of your lists are exposed. We basically create an entity in Drupal for every list that you want to expose as a sign up form on your site. And you can expose those sign up forms in either a page or in a block. And then you can obviously, then you can use the rest of Drupal's ecosystem to place those blocks contextually. You can create any number of pages with sign up forms embedded in them and you can give those pages custom URIs, put them wherever you want. You can do some access control around them. It's pretty slick and easy. And again, sticking to our approach of giving you really a flexible approach that meets a wide array of use cases. This exactly speaks to that because there's no one way that an organization wants to do its email marketing and this lets you do it in any number of approaches. So this is, this is, this is probably the most powerful and complicated aspect of the system. So we've used this type of architecture in a number of our modules including entity registration which was also quite popular. But it's a field based architecture. So the module has a special field type called the MailChimp subscription field. And that field has a bunch of field level settings which connect it in the background to an email list. And then the display of that field is actually gonna be your subscription form. And the value of that field when you're creating content actually nevermind, that's it. Yeah, so the value is gonna be whether or not an individual is subscribed when you create the entity. So when you add a subscription field, you can then display, you can use the display settings of the field to determine how it displays like as a checkbox, as a signup form and whatnot. And you specify which list is associated with that field. So a really common use case would then be so you've got a user object, right? Your user object and you can manage fields and add fields to users in Drupal, right? You can add names, addresses, phone numbers. You can also add this MailChimp subscription field. So when a user goes to edit their profile, they'll have a separate section of their profile which will allow them to subscribe to newsletters. And behind the scenes, we manage all that communication with the MailChimp API. And the way, one really important note here, right? Somebody could communicate with the MailChimp service in lots of different ways, not necessarily through your Drupal website. Or they could manage their profile from the MailChimp site. They could clip the unsubscribe link in the footer of the email. Well, so that's obviously, that's a canonical source. So we kind of have a caching technique using MailChimp's webhook system that then clears the cache when a change is made on the MailChimp side. But you can't override using the Drupal form values, whatever the actual subscription status is within the MailChimp site. But that field is available to you throughout the Drupal ecosystem. You can use it in views. You can use it in rules and anywhere else. So activities are really neat features. So what this lets you do, this also takes an entity-based approach. So we create an activity entity, which is basically like, okay, we have a Drupal entity. We need to figure out the email address of that Drupal entity. And we create mappings for each object. So using the user example again, you could say, all right, so I wanna be able to look at a user and see all of the email activity for that user. So we create an activity entity where we say I wanna track Drupal users. Here's the bundle I wanna use. Users only have one bundle. And you gotta specify which of the attributes of that bundle is the email address. And then you are able to track all the activities in the Mailchimp API that was ever sent to that email address. And again, you can see that all within Drupal. You can track opens, clicks. You could track opens, clicks, any other events that Mailchimp tracks. And finally, we have a campaign feature. So this lets you actually create your campaigns from within Drupal. And this can be great if your staff is already trained in Drupal and you don't wanna also train them to use the Mailchimp interface. But even perhaps more powerfully, you can embed Drupal content. Using a token-based approach. So if you wanna show your last three blog entries in your news article, you don't have to cut and paste those blog entries. You can actually just embed tokens in the campaign here. And when it gets sent out, it'll transform those tokens into the actual content from your website. So that can be really great. So a question that often gets asked is, well, why would I use a third-party service for sending newsletters when I can, there's the newsletter module, which is really well-used and a really powerful tool. There's a number of other modules and capabilities within the Drupal ecosystem that would let you send out email newsletters without using a third-party service. And this is kind of a theme kind of throughout our integration work. You know, I always like to say that, you know, let the cobbler make the shoes. You know, there are some things that you really are best left to a specialized service provider. In the case of email marketing, you know, Mailchimp and similar services like Campaign Monitor, Constant Contact, Exact Target, what not, they provide some really compelling features that you are gonna have a really hard time recreating within your own server infrastructure. One of them is certainly deliverability. So there's lots of different firewalls, lots of different corporate firewalls, lots of spam prevention tools, and to actually get your email into the inbox of your users is no small feat given all of those hurdles that you have to get over. And a service like Mailchimp, that's what they do. Like they've built a million, you know, multi-million dollar business on ensuring that when they send an email, it gets through to the recipient. Additionally, accountability and reporting. So when you send an email from your web server, it's often the ether, you have no idea what happened to it. You don't know if it was sent, if it was caught in the spam filter, if it was opened, if any links were clicked. And I don't know if any of you have used Mailchimp, but it has a really, really rich and powerful reporting interface that there's no way you could recreate on your own. And then finally, consistent appearance. So there are countless email clients on phones, you know, you got Gmail, you got Outlook, you know, dozens and dozens and dozens of different email clients. And to actually have your email look the way you want it to look in all those different email clients is really, really hard to do. And Mailchimp's templating system, you know, ensures or at least helps you. I have a higher chance of your emails looking good on all those different platforms. So, you know, that said, the results. When I first started working with Mailchimp, there were about 300 reported installs of the module. About five, six years later, there's over 25,000 and growing. The list has been very linear. And, let me back up a sec. So with that, you know, I think that, I'll keep going, sorry. So the community gets a well-supported integration with a popular and important service. And Mailchimp gets new customers and respect from the community. These are, Mailchimp would have certainly gotten some of this work anyways because they provide a great service and they do a great job of marketing it. But by having that really well-maintained integration that we kind of promote together with them, I think that they gain a lot of respect from the community. There's a canonical module that we know works really well with the Mailchimp service. And that's more likely to kind of increase adoption. And again, it's not all altruistic. ThinkShell gets the hourly work from Mailchimp. We get some lead generation by being the authors of that module. And, you know, and to some extent, it burnishes our reputation in the community as well. So I'd like to joke around that it's, you know, truly one of unique win-win-win situations. The community wins. They've got a really great module that's really well-supported and maintained. Mailchimp gets to grow its customer base. You know, ThinkShell gets the benefits that I alluded to earlier. And it's definitely a good situation. So, I think maybe I'll skip the demo until later to make sure we have time for the other points. All right, so again, I think Tano's gonna jump in and talk about Salesforce next. So, yeah, next we'll talk about Salesforce a little bit. Imagine most folks are familiar with what Salesforce is. Gigantic CRM system that's out there. So our first encounter with Salesforce on our projects was in late 2011, 2012, where we had an organization forum of regional association of grant makers. I think I got that right. It's a pretty long name. And they needed a new association management system. And they wanted Drupal on the front end. They wanted it tightly integrated to manage things like membership access, interest groups, event registrations, all sorts of things built in there. So we created this great Trello board of high level features that we needed for this association management system. And one of those cards was this one here that I dug up recently that says Salesforce integration and a little bit understated here where it says big issue needs to be fleshed out. I don't know if we realized at the time what a big issue it was, but it turned out to be pretty significant. So a bunch of these associations were already planning to use Salesforce as their CRM. And we wanted to integrate that with Drupal. There was another group that was just gonna use Drupal for their CRM and we were gonna have a separate application for them. And we realized pretty quickly that pretty much all these groups were going to use Salesforce. So we had to figure out how to build this integration. So we could have just used Drupal, right? We had kind of started on Redhand at the time which is our Drupal native CRM. You could build theoretically, you could build everything in there if you wanted to. But it really just wasn't a great fit for what these folks wanted to do. They already had users that were using Salesforce. There was requirements within Salesforce that could have been recreated in Drupal or would have been extremely costly and really difficult to maintain. And that's a pretty common theme that there's certain tools like Lev was saying that really are best done elsewhere. For a simple application, the CRM within Drupal can work great. But for something as complex as what Salesforce can do, it's really hard to recreate that. The Salesforce ecosystem is gigantic. It's probably more than, much larger than this at this point but the app exchange environment is gargantuan. There's far more integrations there than there are with Drupal. And there are much different kinds of integrations than what you get with Drupal. You also have a really different mix of users where the folks that are using the CRM heavily are not always the folks that are producing content on the website. And it can be really difficult to convince those CRM users in an organization that yes, Drupal is a great choice for all of their CRM needs. So there's other reasons to do things like reporting can be really challenging with Drupal when you're starting to instruct users how to build views to create ad hoc reports. I don't know if anyone's had to do that. It's not a great experience trying to explain to people how to use that interface that aren't more technical. So what it comes down to is trying to find the right tool for the job. And in this case, Salesforce was really the right tool and we needed to figure out a way to make it work. Building on this a little bit, the idea of using these integrations really lets you extend the reach of your website in ways that would be very difficult to build natively. Drupal is great, but it's really not the right tool for absolutely everything you can dream of. So in trying to figure out how to build this integration, we started from the side of well, what are the key requirements that we need? And we needed a few things to integrate well with Drupal to be able to do all the membership stuff, event registration and the complex functionality that we needed. So one of those core ideas was we needed to be able to map Drupal entities to Salesforce objects. We needed to be able to set different fields to push and pull in different directions. So we wanted the email address to go up to Salesforce, but not to come back down, for example. Although that's probably not the right example because that does go in both directions. But there's other things that we didn't want to go in both directions. And we wanted the ability to customize. Like mapping interfaces are great, but there's so many edge cases that we needed the ability to say, yes, when we're pushing the membership field from Salesforce to Drupal, we want to bring it into this field, but we also need to validate it against these possible options and assign a user role based on it and do all sorts of other stuff. So we needed that extensibility and flexibility. We also wanted to have legitimate authentication and good authentication. So use the OAuth authentication system and then also use the REST API for performance and simplicity purposes. So, great. There's a Drupal module out there that does Salesforce integration. But it didn't really meet these requirements. So there was the 7x2x branch of the Salesforce module, did a lot of things, was used by a lot of folks, but really didn't meet our requirements for this project. So we took a step back and said, well, how can we modify this to do what we need? And ultimately the answer was no, we needed to rewrite it from the ground up to really fit those requirements. And so building on the idea that Lev was talking about where we try and build these modules in a really flexible abstract way so that they can be core building blocks, we started this Salesforce 3x branch. And the way this worked is we started off, so there's the form of regional associations of grant makers, call them frag for short. So we started off with them and it wasn't reasonable for them to invest the entire cost of rewriting this module. And so we made an investment ourselves, a significant investment ourselves into doing this. So it was really a partnership between our client and ourselves and rewriting this module. And we knew that long-term this would pay off for us because we would have other clients that we could then bring on to do Salesforce integrations and that really expand our business from there. And that's what happened. So we started with the forum and then we moved quickly, still while we were developing the forum project, we were working with another group facing history in ourselves, which had a very complex Salesforce integration, the Los Angeles Conservancy that was doing event registrations and donations through their website. They also needed Salesforce integration and these were all kind of happening at the same time. And then of course now, now that we've done this work, it's out there in the community, it's got over 1500 installs, that's really just the 3X branch of the module. Lots of other organizations are using it that we have no idea about and it's taken on a life of its own. But there's one critical thing missing here is that you don't see the Salesforce logo here, right? So unlike MailChimp, they are not official partners or sponsors in this module. There's a lot of reasons for that in part because they have sort of similar products. Their Salesforce communities product has some similar ideas and it's a per user licensing piece. It's a very different model than what a Drupal integration has. But when we talk to them frequently, trying to figure out ways to work together, but ultimately this module is supported by the community and the clients that pay to support it. It's a pretty different thing than MailChimp. We're not able to be quite as proactive in terms of things like upgrading to Drupal 8, which I'll talk about in a minute, adding new features, that sort of thing. It's a really great module. It gets incremental improvements as clients need things, but there's not a pool of money there just to support it. So I'll talk a little bit about some of the features which I think are, there's some really cool features that are in here. I'm gonna show you some screenshots of different things. So this is the mapping UI where we're mapping the Drupal entities on the left side to the Salesforce objects there on the right side. So you get to pick, I wanna map contacts of type general to the contact object in Salesforce. And you can even specify the record types in Salesforce as well. There's all sorts of interesting stuff with the data models in Drupal and Salesforce look really similar until you start doing it a little bit and realize like, well, bundles in Drupal have unique fields, record types in Salesforce. Really don't have that. They all have the same fields. There's not really any data validation happening in Salesforce, but Drupal's really aggressive about data validation. So it seems really easy, but it turns out there's a lot of little ins and outs to it. Next thing here is the field mapping. So we take for every mapping of objects to entities, you can decide what fields you wanna map. And on the Drupal side, you can pick properties. This is Drupal 7, so you've got properties, you have fields related entities. So if you have an entity reference or a text on any reference, and even relations, which is a little less popular or less known module, but we use it for Redhem. And then you can choose the directionality. So that's what I was talking about before. I want the membership information to flow from Salesforce to Drupal. There's really complex membership rules in Salesforce. I don't wanna recreate that in Drupal. So we just have one field that pulls that data from Salesforce and just goes in that direction. And then the last piece of the mapping is that you decide the triggers and whether it's asynchronous or not. So there's the action triggers. When do you wanna push things to Salesforce and when do you wanna pull back down to Drupal? And then the asynchronous stuff is related to the SOAP API. So when we did this rewrite, we primarily rely on the REST API. A lot more pleasant to work with than the SOAP API. You can do things all at once, push objects individually. Tends to be a lot more performant. But there's times when you do wanna batch things out. Maybe you're running against API limits. Maybe you're doing something that really doesn't need to happen real time and you wanna have a little bit more resiliency to Salesforce being unavailable or something, then you would use the asynchronous or the batch options. Some of the other features is we have this. This is a later feature that actually came from one of our clients facing history after the main push on the module had been completed. So they wanted to be able to see a little more information about what was happening with all of these syncs. They had a couple hundred thousand roughly contacts that were being pushed back and forth. And they wanted to figure out some of the problems that were happening. So we built this UI where you can, it sounds awfully similar to the mapping UI, but it's actually the mapped object UI. It's a little confusing. You can look at all the objects that are mapped and see what the history is. So you can see on here that these are contacts. There's the Salesforce thing that they mapped to, the object, and then you can see the history. So the last push was an error, and here's the error message. Or we've pushed successfully 10 times and the third time was an error, things like that. Very helpful for debugging the integration. Drupalate. So I mentioned this earlier that we don't have someone sponsoring Drupalate development on its own. It will be coming. We fully expect this, but we don't have a particular target date because we don't have a contract to say, there's money to do this upgrade. So it's dependent on client projects that are gonna help sponsor this work. It's gonna look really similar to the existing module. A lot of the reason we did the rewrite is we wanted to really leverage the entity system. A lot of that is very similar in Drupalate in terms of concepts. So we're gonna see a pretty similar module on Drupalate when we do do that. There are other folks in the community that are doing some work on it, and that's great. It's nice to have other folks contributing to it. We're definitely excited for our first big Drupalate Salesforce project. It's probably not too far off, but it'll take a little while to really get that momentum for us to do that. And I'm not gonna do a demo because the wireless is iffy. All right. So I'm gonna talk about Commerce IATS, which is a plugin for Drupal Commerce that integrates with the IATS payment system. So I know it sounds a little bit less exciting than MailChimp and the rich integration there and with Salesforce. And it seems pretty simple. You're gonna take some credit card numbers, you're gonna submit it to a processor and everything should be fine. And why would we even get involved with this building a plugin like this when you're doing exciting stuff like Salesforce or MailChimp? But it turns out that there's a lot more to payment processors than just taking credit card numbers. And the story of how we became maintainers of the IATS module is a little bit more complicated. That's what our maze demonstrates here. So our parts here are played by ThinkShot, that's us, over in the far corner you see Los Angeles Conservancy, which Tauno mentioned. We were building a site for them and so they already had a relationship with IATS and Drupal Commerce, of course, the Los Angeles Conservancy site wanted to take paid registrations and donations. And so we said, well, let's use commerce for it. This is a great tool in Drupal already. And they already were using IATS for payments. So how hard could it be one little payment integration? So here's the Los Angeles Conservancy site that we were to replace. This is an image from 2013. So they contracted with us to build their new site with ThinkShot. And a key feature of their site, as I said, was selling tickets. So they had this relationship with the credit card payment processor called IATS. And there was a Drupal Commerce integration module for IATS already. So here you can see the page for it at the time. Note that there are two total commits. There is a release there. And so we thought, great, we'll try this out. These commits by A. Dixon, who's a member of the community, great community work. There's a module for that. Cool, we tried it out and it wasn't quite ready for prime time. So needed a little bit of work, but here it was. Townhill, I think, reached out. Or maybe it was Lev at the time. And got commit access to the IATS module. A. Dixon was done with it. He said, I don't have a project for this anymore. So we started making commits in April of that same year, or of 2013. So worked on it a little bit and it was, we got it to a point where we could take credit cards through commerce and submit the payments and process them. And that worked, very basic improvements. And we launched in July 2013. LAC's new site, beautiful, all done. And commerce payment processing, entity registration, sales force. Cool site, and so we're done with that, right? We don't need to deal with this commerce IATS thing anymore. We're gonna be the next A. Dixon. We're gonna leave the module behind and say, well, whoever needs it next, you can make some improvements. We looked a little closer into IATS though. We talked to them or saw their website. And we noticed a similarity. So these are quotes from ThinkShouts and IATS websites. ThinkShout, we use technology and strategy to elevate organizations creating positive change in the world. That's coded language for we work mostly with nonprofits. And IATS payments is payment processing products to nonprofit organizations. And that's all they do. They only work with nonprofits. So we saw there's something here, you know? Maybe we should talk to these guys. So we reached out and started a conversation with IATS that went very, very slowly. So we launched that site 2013, middle of 2013. And the next year at the nonprofit technology conference actually had a meeting with IATS. And we talked to them and inspired by sort of the history of the MailChimp module. Super healthy. We convinced them that they should work with us and got contracted them to do maintenance, to do improvements and built a new version of the IATS module improving on a lot of the things that were wrong with the first one and could add features. And so this is the IATS module page yesterday. And our most recent release right now is 7x211. So we've had 11 releases on the module. I guess 12 with 2.0. And you can see the number of commits over there. There's over 400 commits. Most of those are, in fact, all of those people are ThinkShot employees. And it turns out that you can do a lot with the payment module. We added features such as doing direct debits instead of credit cards, doing direct post so that the credit card information doesn't touch your Drupal site at all and you can offload a lot of that compliance issues to IATS. We built a tool, you can plug in a USB card reader and run cards right there into your website and charge them to IATS. We built refund processing into the module. So now instead of just having a payment module that will do credit card processing, but you're kind of stuck there, we have full featured payment module and we can go to our clients when they want to use Drupal commerce and they say, well, then we have to process our own payments and we need these features that, you know, we could get from some other service that does it for us. So we say, we know a company that's focused on nonprofits, knows your needs and integrates awesome with Drupal commerce. And we also have some budget to do maintenance with them because IATS is taking care of us and when we're working together so that we can make improvements. We also helped IATS. Their API had a lot of functionality but not a lot of great documentation. So our team created some documentation for their API that they can now share with their other API builders. So we have a nice relationship there. Another nice thing about this, of course, is when the Drupal 8 question came up, we could go right to IATS and say, hey, we have some interesting work. We could build, you know, your integration with commerce for Drupal 8. So we have a roadmap for that. Of course, we are waiting on commerce payment plug-in specifications to be finalized so we can actually do that, but that's supposed to happen soon. Now, once we had a nonprofit-friendly, full-featured commerce payment processor, we sort of thought, what can we do now? We have these other tools. You know, Drupal commerce is beautiful and functional and does lots of cool stuff. We had built our own CRM into Drupal and we had this payment processor. So we thought, where can we go from here? One of the big things that nonprofits want is single-page donations. And they want to take single-page donations from people. They also want to ask those people questions and record that information and they want the processing to be quick and easy right there on the site. So that single-page donation form was something that was really hard to build with just commerce. And so we had to build a module to do it. And that led us to build a red-hand donation, which is a tool you can integrate with red-hand and commerce and create single-page donation forms. So when we go and talk about building this for clients, we say, yes, we know a payment processor that does work with our customizations to how commerce behaves. It will work with any mature functional payment processor for commerce, but we know it works with IATS. So that's been really valuable. In most of the instances in which we've built red-hand donation out, we've used IATS payments. So you can see this is a, the screenshots sort of broken up because this is a long form. But this is an instance of the single-page donation form. Put in all your information, select a donation amount, put in your billing information right there. That billing information gets dropped into the CRM. So you get, you can send that person a letter in the mail and you can record that information long-term as you're tracking your relationships with your constituents. And it processes the payment right there and it creates a separate table of donations so you can do reporting on that with views. It matches with your existing CRM data based on email address. So if someone comes and makes a donation and you already have data on them, it updates the address you have in the database for them. So pretty cool stuff. This also supports commerce recurring and commerce card-on-file. So we worked with IATS to make sure that their payment processor was working with commerce card-on-file module as well. So you can do recurring donations with these forms. All with point-and-click configuration. So we were really excited about this and so were some other folks and we decided to take it further and build a social fundraising distribution. So based on Red Hen donation and Drupal commerce, we built Red Hen Razor, which is a fundraising tool, a social fundraising. So you can create campaigns, get other people to join your campaigns. Obviously there's some sharing tools in there. Check out leaderboards and compete with other groups to do fundraising stuff and you can do it all in Drupal. So you're capturing all your own data and you don't have to get exports from some other service you're paying to do this stuff. And of course it has the full Drupal ecosystem and you can customize everything that's in it with the power of Drupal. And you can process your payments through commerce and the IATS module. So the original instance of this was built for the Capital Area Food Bank of Washington, DC and they've already raised $400,000, over $400,000 with this tool. And you can also, if you wanna play with this, by the way, you can go on Pantheon and just like point and click install it. This distribution's right there. So cool. So three integrations we talked about, all very different in their way, but there are certain threads that go through and lead to successful integration. I think the one that we've talked about the most is actually having the official backing and support of the organization you're integrating with our tools. So we have that with IATS and MailChimp and that's great. We get consistent funding from them to do issue maintenance, to do support and to keep making enhancements to those modules and you can see it in the release history for those modules, they're consistent and we get patches up for things. And that's awesome and we love that. Obviously the win-win-win situation that Lev talked about. There's also a big deal with the stamp of approval sort of saying this is the official integration, right? If you look at, I think, Instagram, there's like a couple of different integrations out there and if you go and you're looking for the tool to use for one of these services with Drupal, you know who it is and so that's sort of the stamp of approval there. So you can make no ambiguity about what tools you should use. So the other thing is that there's this advantage of the sort of functionality fast, right? We talked about with Salesforce, you could build these reporting tools with MailChimp, you could build tools to send out your own campaigns and the same thing with IATS payment processing, you could probably build your own payment processing tools but you get that functionality very quickly and you don't have to worry about the details. If you integrate with somebody who's already doing that. Also, Drupal makes a great hub for all of these so we have a lot of sites that use all of these integrations and more, Drupal's really has a very flexible architecture and really sophisticated data structures so it makes a great platform for integration so you can jump into any of the process of the life cycle of an entity and fire off your integration right there. And of course, the other big advantage is the community engagement and community alignment. We all know the power of the Drupal community and I think the thing that happens with MailChimp, for example, we have MailChimp hats at our booth today, we can sort of cross market and be coordinated in the way we both address the community's needs so MailChimp comes to us and we're the experts on Drupal and we can go to MailChimp and say, what can you do for Drupal and what do you want Drupal, the Drupal community to know about you and to learn about your services. There are a lot of sort of advantages to doing integrations and not just building everything out on Drupal. I think that you sort of see what some of those are. Now I've got the standard slides here about joining us for sprints. I'm sure you've all seen these, but we'll take questions about our integrations or about the sort of process of building integrations if anybody has them. I don't know the fees at the top of my head. IATS is very affordable. I mean, they're target non-profit community that's very price sensitive. So I think they're cheaper, but I mean, most payment processing services in my experience very close to like 3% per transaction. I believe IATS is less than that. Right. Well, the Salesforce Foundation itself offers free Salesforce to nonprofits. And as a result, the nonprofit world is really psyched about Salesforce. A lot of people come to us saying we wanna use Salesforce. And then you have folks who are in the nonprofit world who learn Salesforce, learn to like it, go to other organizations and want it again. So oftentimes, people come to us with Salesforce in mind already. I think that reminds me of a lot of the ways that our modules have developed in the past, which is oftentimes we'll build it for a very narrow use case, and then wait for someone else to want the similar thing and then expand it from there. We're in a different place there where we're dealing with multiple clients so we can look for those opportunities. I mean, my thinking is I think if you can hire a developer who is comfortable doing those things and you have the resources to do that, then that's gonna be a great option, especially if you get it out there in the community. Then other people can start using it, giving feedback and giving other contributions. I think that's the starting the snowball sort of technique. I think the other thing you can do is build it for your needs, but do put it out there, even if you can't release it as a 1.0 release, even if you release it and say there's some code in here that isn't abstract, but put it up there for the Drupal community to see and for other people to work with. Let somebody else abstract it for you. Well, I mean, we talk about our integration so people know they're out there. I think that's it. I don't know, we're pretty careful about making sure you get the right name space, you know? Name it something that people are gonna find. Lev? You're the eyeballs guy. Or like what happened to MailChimp at the beginning before the, oh, I'm sorry. So that's a really great question. It's a topic that's near and dear to our hearts. Probably the ones who don't be honest and talk about it more, but that's the general space, and I'm on the private sector side, marketing innovation is a flavor of that. So I think it's a really exciting idea, and we have the Salesforce of bidirectional sync and we want to store all of the... You mean specifically with the payment processing, or? No, no, it's, you're not missing it. Counting departments tend to be very, very specific about what they want, so for most of the folks we work with, we put a layer between the accounting and the data sources, so either if we use Red Hen CRM or Salesforce, we'll have reports or exportable views that the accounting department can use to get the data they need so they can manipulate it and look at it exactly the way they want. Salesforce does have some integrations with accounting software, so if we use Salesforce, Salesforce is usually the database of record for any financial data or contact data, and so that becomes like the sort of central hub. Drupal feeds data into it, and other sources feed data into it as well. Manually entering check donations, things like that, and then the finance team pulls the data out the way that they want it. So yeah, that's a good question. It's a pretty challenging space because of how specific and picky finance departments tend to be. Yep. QuickBooks, Financial Edge, what are the other ones we hear a lot? No, there can be with, so like the Salesforce world has a lot of integrations, so on that level you could do it, but not direct from Drupal. We haven't done any direct integrations. Yeah, just running reports. Anyone else? Questions? If you do think of any more questions, please feel free to get in touch with any of us. We got a booth, 216, and Think Shout is, you know, we exist on the internet and you can find us there. Twitter, email, whatever. Thanks.