Talking Drupal #548 - How to build your own CRM

Nic: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 548, how to Build your Own CRM. On today's show, we are talking about CRMs, building them with Drupal and how you can help with our guest, JD Leonard.

We'll also cover social media links, block and Field as our module of the week. Welcome to Talking Drupal. A guest today is JD Leonard. JD is a freelance Drupal architect and developer in Austin, Texas. With nearly 19 years of Drupal experience, he focuses on the development and implementation of complex web applications using Drupal and enjoys organizing local meetups and regional conferences.

Welcome back to the show and thank you for joining us. Thanks

JD: for having me.

Nic: I am Nick Laughlin, founder Enlightened Development, and today my co-hosts are Martin Anderson, includes product marketing manager for Drupal at Acquia. Welcome to the show.

Martin: Thanks. Great to be here.

Nic: Also, joining us, John Zi, solution architect at EPAM.

You're muted.

John: Howdy, y'all.

Nic: And now to talk about a Martinique. Let's turn it over to Martin and I. It's even more awkward when it's live in memory. Introducing you. Uh, Martin, what do you have for us this week?

Uh, I think we might've lost Martin.

John: Nope,

Nic: for a second there.

John: He's back

Martin: Full field play for some reason. Oh, live internet things. Let me try. We can,

Nic: I think you're, I think you're back. So if you wanna just, uh, start at the top.

Martin: Sure. Thanks Nick. Have you ever wanted a single Drupal field that could collect and display multiple social media profiles, not only for the site, but also for things like users person profiles or organization entities?

There's a module for that. It's called Social Media Links Block and Field, and it was created in October of 2012 by Christian Bayer. The recent releases are by Nele, kil, Pinto, and Jacob Perry. It has an eight point x dash two point 10 version available, which works with Drupal 9.5, 10 and 11. It is actively maintained and has, uh, security and test coverage, and it has 54 open issues, 15 of which are bugs, which is quite good considering it's currently in use by almost 30,000 sites according to Drupal org.

Now after you install the main social media links module, you'll be able to use a new block for displaying social links site-wide that uses a new system of social media links using plugins for icon sets and platforms. Icon set. Uh, plugins. Allow social media links to work with your choice of icon sets with four integrated out of the box, including elegant themes, font awesome IMO and novea.

The platform plugins define a small amount of metadata for each platform. Uh, dozens are provided outta the box, but if you need something custom, you can define your own plugin, likely with less than 20 lines of code as the name of the project suggests. There is also a submodule that defines a new field type, which I personally think sets this module apart from a number of other modules that you can use to display social links.

With social media links field module installed, you can now collect social media links with the same set of plugins on any kind of fieldable entity, users, person, profiles, organizations, and so on. Within the field definition, a site builder can choose the icon set and which social platform should be available to populate.

It's worth pointing out that this module does involve outputting user provided URLs to your site pages, which obviously carries inherent risk. The module also defines a new twig extension to sanitize links before their output. So let's talk about social media links, block and field. I

Nic: mean, I can, I can see why this is useful.

I mean, most of the time. My clients are defining one set of links with a whole site or like a share type thing. So like this blog post you can share and it like automatically sends out like a pre-populated message, which is kind of a constructed field as well. So, Mo, most of my clients don't actually need this, but if you, it feels particularly useful if you want, um, uh, if you want to allow, you know, people to add links to a particular story or to their profile or something, um, I probably would've built this manually, but it's also nice to just have a, uh, have a field that you can reference.

JD: Well, Martin, I, I can see why you chose this for today's episode because you could, of course, use this module, uh, on CRM contacts, right? That would be a very obvious use case. You wanna track social media profiles in your CRM. So, um, I, I think this would be very useful for the right organization.

Martin: Yeah. And I will say I, I first came across this module when I was working on event platform where obviously it's useful for speakers to potentially have social links on their own, uh, profile page, but it kind of resurfaced.

Uh, recently when John and I were having a conversation about social links on user profiles, John, what was the, the project you were working on? Is there anything you can share there?

John: Uh, I, a hundred percent can. So on my, um, my personal site, I actually have a strip of social links in, um, in the rail there.

And, uh, they were, they were just hard coded, you know, links in, in images in a, in, uh, in a block. And I was kind of like, eh, this is like hard to reorder, hard to manage, hard to, hard to do things with. There has to be a better way of, um, of doing this. So I did look at this module as well as a few other modules we had, we had talked about and that I had found on drupal.org.

Um. Ultimately, I actually did end up going, um, down Nick's path, um, of kind of building my own content type and, um, bringing it into a view and using, um, uh, view, view order. Um, what's the view order module there? That's not the name of it. Um,

Nic: the sort Draggable fields.

Martin: Maybe.

John: Draggable Draggable views. That's it.

Views. There it is. Um, so started using Draggable views to sort it, and the only reason I didn't, uh, select this mo this module, um, I had installed it. I had, I had, I had tested it out. It worked great. It provided a ton of functionality that was super useful, but, um. I do have some links to some, some custom things that aren't necessarily social networks in that sidebar.

So it was kind of not exactly a hundred, a hundred percent feature match, but um, you know, the cases that you guys are talking about where like you might have a user profile where people wanna post, uh, links to their, their socials, um, makes a lot of sense here. Especially 'cause it, I think it, it incorporates website, incorporates email, so you do have a lot of options.

Nic: Yeah.

Alright, thank you Barn as always. You have an on-topic module of the week. If listeners wanted to suggest one or just chat about this week's module of the week, what's the best way for them to do that?

Martin: We're always happy to talk about the module of the week in the talking Drupal channel of Drupal Slack.

Or folks can reach out to me directly as man clue on a variety of Drupal and social platforms.

Nic: JD for our listeners, if it's, if they're new to the concept, what is a CRM and what problems does it solve?

JD: So, uh, A CRM is just a. A tool that, uh, organizations use to manage and track their interactions with its contacts. Um, and it solves the problem of you've got your data in a bunch of different places, um, and, you know, uh, you, you don't really have a tool that's purpose built right to managing this information.

Nic: Yeah. And I, I think it stands for customer relationship management or something. Or client

JD: management. Well, that depends who you ask. So Drupal, CRM we're a little opinionated on this topic. Um, so our CRM stands for contact relationship Management.

Nic: Okay.

JD: Um, which is, uh, I guess chosen because, uh, it's more generic.

Uh, and it kind of covers more use cases than, uh, customer relationship management or constituent relationship management, uh, which are sort of more common, uh, uses of the, uh, the acronym.

Nic: Right. And I, I think, um, the important thing is it helps you track like, Hey, this is the last time we contacted them.

This is their preferred method of contact. This is, you know, the, if we're solving a problem, the problem we're solving, if it's a sales lead relationship, it like how close they are to closing or maybe what they've purchased before.

. So let's take a minute and, uh, hear from Matthew, Matthew Saunders about the Julee AI Summit.

Matthew: The conversation around AI is changing. We've moved past imagining what AI can do. The real question now is how do you operate it in production under real conditions with real consequences? And that is what the Drupal AI Summit New York City is about. It's happening May 14th, 2026 in New York City co-located with API Days New York.

This puts Drupal into a much broader conversation with enterprise leaders and teams already running AI in production. We'll have a focus on governance, data ownership, integration. What actually happens when AI systems are live. You'll hear from people who are doing this work today, including what worked, what didn't, what need to be fixed.

So if you're responsible for platform or architectural decisions, this is a conversation I think is really worth being part of. You can find full details at dr.org/ai and I really hope to see you there.

Nic: Thank you, Matthew. And I'd be interested, interested to see what comes outta that summit. Alright, before we move on. There is a, uh, a, a fashion trend going on on the podcast. I'd like to call out. Um, I do, I do have a hat as well, but I, I think it's at the PO box and I, I, uh, just haven't had a chance to get out there yet, so I will go pick that up later today.

But, uh, the team was, was kind enough to send CRM hats to everybody.

JD: So Steve Ayers, who's the lead maintainer of, uh, Drupal CRM, uh, is big on the hats. And so he had a bunch of, a bunch of hats made. He's had even more hats made. He's very keen to, uh, get them out to, uh, people who are supporting Dral, CRM, uh, and who were contributing to Drupal CRM.

So, uh, if, if you're out there listening and, uh, you, you'd like one of these very fashionable, uh, beanies, um, get busy.

John: They're very warm, I will say. So jd. CRM customer relationship management. Are we going with contact relationship management? Remind me again what you just said. We said

JD: contact, we

John: said

JD: contact because, got it.

You could build a customer, uh, you know, based CRM, like a sales CRM, uh, using triple CRM, but you could build something more like CCRM, which targets non-profits and their constituents. Yeah, constituent CRM. So we're, we're not being opinionated about how you use Drupal CRM, but we are being opinionated by what you call it.

John: Okay. So that makes, that makes complete sense. Cus you know, contacts are everywhere, so why not? Why not generalize on that? I'm wondering if you can talk more about the kind of core features, um, you kind of expect from a CRM platform.

JD: Sure. I mean, you know, the most obvious is it has to track information about your contacts.

John: Mm-hmm.

JD: Right? Um, but then that r is for relationship, so it's also about, uh. Tracking their relationships with one another, right? And so contacts can be a lot of different things. They could be people, they could be organizations, they could be households, they could be pets. If you wanna build a, you know, tool to track your pets, uh, like you, you could use Drupal CRM for that.

Um, there are definitely other ways you could do that, right? Um, and, you know, that's, that's sort of the core of it, right? Like that's, that's the only thing that must be there beyond that, right? It's kind of up to the individual use cases of the organizations that are using them, kind of what makes the most sense.

So there are lots of of commercial CRMs out there that target different niches and have different feature sets, but they're all based around, you've got these contacts and you want to do something with them and have some structured data.

John: I would imagine a, another big part of that is, is integrations and, and kind of getting, you know, interconnecting that, that contact data with other platforms, other systems.

Also also bringing in maybe some contact data from other platforms and other systems. Is that, is that true to say too?

JD: A hundred percent. And you see this with, you know, this trend with a lot of CRMs out there that are building more and more integrations with other tools, um, or, you know, with orchestration platforms, uh, that, you know, let you do interesting things with your, your CRM data.

Um, and whether that means you're pushing your data out to other, uh, platforms or you're bringing additional data in from other platforms. Yeah, there's a lot of, a lot of power there.

John: Interesting.

Martin: So what kinds of organizations are likely to benefit the most from using A CRM?

JD: Well, um, I think. Any organization really, um, unless you're, you know, an organization that doesn't interact with contacts with people or other organizations.

Right. Um, and I guess those do exist. Um, but, you know, whether you're a, a nonprofit, uh, looking to track your donors, your prospective donors, maybe you run a museum and you want to, uh, track attendees, um, you know, lots, lots of stuff in sort of the NGO space. It makes a lot of sense. Um, then from a sales perspective, right, a lot of companies that sell a product or service, uh, they wanna be able to track their leads, uh, track the status of those things, have some workflow associated with that.

Um, you know, they need to be able to, uh, maybe assign, uh, different, uh, work to different individuals. So having some case management, uh, capabilities, uh, which, you know, could be useful in a sales context, could be useful in a, um, in a nonprofit context. Uh, membership organizations. Um, you can imagine, uh, higher education institutions that wanna track information about their students and about their staff.

Many use cases.

John: So an open, an open source project perhaps that wants to track who it has and hasn't given hats to.

JD: It's a great example.

Nic: Uh,

JD: we need to dog food our CRM for that.

Nic: W what about the Drupal CRM project itself? What, what problem are you trying to solve in kind of the CRM space?

JD: So Drupal, CRM, uh, is obviously doing CRM in Drupal, right?

As opposed to elsewhere. Uh, and that's, I think the big headline, right? Is, you know, you can have, uh, a really strong CRM that is Drupal based, uh, existing solutions out there in the open source world. Uh, CCRM has really got the market share there, right? And they do a great job. They've got a really large feature set, um, and they're open source, which, you know, is really important, uh, for, you know, a number of reasons for a business, uh, who want to, wants to have control over their data and, you know, security around what happens to that data.

Um, but, uh, while you can integrate CCRM or, or other external CRMs with Drupal, uh, you're kind of hobbled, right? You're, you're starting out, uh, from not the best place. If you then wanna do something interesting with that data, um. Uh, you know, in, in your Drupal system, right? So maybe you already have a Drupal site and you've got some features where it would make sense to track information about contacts.

Well, you could do an integration with an extra service, um, or you could do it natively, right? And benefit from all the great things that we have in Drupal. Uh, you know, the entity architecture, um, field system, right? Uh, views, right? You can use all your favorite tools in Drupal, uh, to manage the data with your CRM,

John: just outta curiosity, what, like, how are you built? We talked about relationships, obviously, and then like, are, how are you building relationships with, in the Drupal CRM project? Is it just like relationship fields to other, other data points within, within Drupal or, um. Open, open text fields or like, is it kind of like you get to choose because you're kind of using that, that open platform?

JD: Yeah. So maybe I'll start with just sort of the overall architecture of Drupal CRM. Um, and you know, this will make sense to people who know these terms in the Drupal community, right? Um, so CRM provides, uh, a number of entity types, um, as opposed to content types, right? So these are en uh, you know, dedicated entity types.

Uh, one for contact, one for relationship, one for contact method, um, and one for method detail. You know, we don't have to get into the, the details of all those, but, um, you know, a contact and a relationship are both, uh, fieldable revision able, um, you know, bundle entities. Um, that you can do all the great things you wanna do in Drupal with, right?

So for, uh, contact, uh, Drupal, CRM ships with, uh, three contact types outta the box. One is person, the second is organization, and the last is household. And you can create, you know, more beyond that and you can add different fields to each one of those bundles for relationship. That entity type, um, also ships with a bunch of, um, well, it ships with a bunch of relationship types outta the box.

So you've got things like, uh, employee employer relationship, uh, like a sibling relationship, a parent child relationship, um, you know, you name it, right? Sky's the limit because they're, um, they're bundles and they're fieldable, right? You can track different information about each type of relationship. So if you wanna track, for example, um, when two people became spouses, right, you could have a field, um, you know, that.

On a relationship type, uh, for spouse that tracks that information.

Nic: Okay. And we, we have a listener question, uh, from Roger Cast it looks like, um, I think he's asking if there's a place that he can see a live demo for the CRM and if he can integrate with like an existing, uh, he says he's built kind of a tech support and inventory system with Drupal already.

Is this something he could integrate into his existing system?

JD: Yeah, so I don't know a lot about the existing system, but because it's Drupal, you can integrate it with anything that, you know, allows you to integrate. Um, and as far as a, you know, a live demo, you know, to kind of follow along here, uh, if you go to drupal.org/project/crm and you scroll down and you look for a big green button, um, it says try the latest, uh, there's a link to the simply test.me demo.

Um, so you could click around in there, um, and, you know, basically explore while you're listening. Um, and, uh, you know, that that'll really help. I think some of what we're talking about feel a little more concrete.

John: I think you mean after you're done listening, right?

JD: Multitasking.

John: Yeah. Okay.

Nic: Steven, I, I put it in the chat if you wanna send that over to him in the, in the live comments too.

Martin: So, jd, how does Drupal CRM differ from earlier Drupal based CRM efforts like CRM core red hand CRM, or integrations with external tools?

JD: Yeah, great question. So in Drupal seven, there were sort of competing, uh, CRM options. You had red hand and you had CRM Core. Um, now, CRM Core, I should be very explicit, is not the same as Drupal CRM, right?

They both have CRM at the beginning of their namespace. Um, uh, but that's sort of, you know, uh, where it ends. Um, Drupal CRM is in many ways, uh, inspired, uh, you know, by those, uh, projects. Um, but those projects have fallen by the wayside. They're not maintained, they're not really kept up to date with modern Drupal Drupal 11.

Um, and, you know, we're building, uh, migration paths, right from those old, uh, solutions to Drupal CRM. And our hope is that the community can rally around one solution, contribute in one place, uh, to a common, uh, pardon the use of the word core because it's not CRM Core, but um. Uh, yeah, so, uh, how it differs.

So besides, you know, being modern and up to date and sort of relevant if you wanna start building now, um, there are some architectural differences. Uh, one big one is that, uh, some previous solutions, uh, uh, had one entity type for a person and one entity type for an organization, which means if you wanted to do something that's common to both types of contacts, you kind of were in a bit of a bind.

You could use something like dynamic entity reference. Um, but pretty much any functionality you're building, it was extra work because you would have to target two different types of entities instead of just one in any of its bundles. It also means you don't have the flexibility to add other types of contacts, um, you know, and kind of track those, uh, you know, in a, in a, in a different way.

Um, uh, there are other CRMs or other. People who have built custom CRMs on Drupal, who have used Drupal users as the way to represent those contacts. And that's very tempting. 'cause that's the thing, you get out of the box with Drupal core that's like, Hey, this is for a person, right? Clearly it's for a person.

This is where you do it, right? You get out a bunch of fields and you know, if, voila, you've got a very, you know, basic sort of custom CRM. What it doesn't have, um, is the ability to differentiate between, uh, types of contacts. And it feels wrong to me to represent an organization as a Drupal user, right?

Drupal users are for, for people who log in and have credentials to log in, right? Um, and so it feels, it feels just like a misuse of, you know, the user entity. Now, granted, what you lose when you don't use the user entity is all of the existing integrations out there in the Drupal world that do amazing things with user entities.

Right. And so that's a bit of a challenge is that we have to rebuild, you know, different integrations, Foral, CRM, um, but I think the advantages outweigh the disadvantages, uh, because you get a really pure, uh, way and very customizable, well-structured way to, uh, track your data, your structured data about contacts and relationships.

And, um, my hope is that a large ecosystem develops, uh, around Drupal CRM, where people are building all sorts of different experiences and contributing them back to the community, uh, that rely on these, you know, common well entities.

John: Jd, I wanna make sure I understood. Well, I have a question. I think you just answered it, but I wanna make sure I understand.

I understood what you said, uh, in the reference to my question. So my question is around, um, you know, Drupal CRM is a new project, right? New namespace for CRM. Um, Martin asked about, you know, CRM core redhead, CRM, other CRM projects, um, and I'm wondering why Dr. Starting Drupal CRM as opposed to just contributing to one of those projects, wa was, uh, you know, was the path you took.

And it sounds like you, it was because the way that those projects were structured and their kind of thoughts were not, not in line with the way you guys wanted to structure yours, it might've been too, too difficult to kind of shift, shift the goalposts there. Is that a fair assessment of, of

JD: Yeah, so it, it is, and let me go back to the origins of, of Drupal CRM.

So, um. This sort of iteration of, of, or yeah. Triple CRM started, uh, by Steve Ayers or Blue Geek nine on drupal.org. Um, and he needed it, uh, to build, uh, a, a platform that he's working on for, uh, knowledge-based learning. And, um, that, you know, he, he had started that he started contributing to the namespace.

Um, meanwhile I'm the project lead for the, uh, Drupal Community Initiative, uh, member platform. And so, uh, we, uh, try to build tools for membership organizations, uh, to help them with their day-to-day needs. So tracking their members, processing dues, event registration, communicating with members, et cetera.

Um, and as we were starting our initiative, one of the first big questions that, you know, decision points that we needed to, uh, to, to make is how are we gonna track this data about the members, right? Where are we gonna track this? What's the, uh, the architecture we're gonna use? And it came down to, well, we either need to use something that's already out there.

Um, or build something ourselves. Um, and in some ways we kind of chose a middle route, um, because the CRMs that were sort of already out there were, uh, really red hand, uh, and, um, CRM Core. Um, there was also one called Contacts, which is a user entity based, uh, CRM. And we, none of those were kind of really doing it for us.

Um, and there was also gonna be a lot of work to bring them up to scratch, right? To like work with Ripple 11, um, in the case of, uh, red Hand and uh, CRM Core. Um, and there just had a lot of legacy functionality and sort of baggage that was gonna be friction right, to, to deal with. But, um, in our research we found, uh, the CRM namespace, uh, where there were the beginnings, right, of another CRM.

Uh, and so I set up a call with, uh, with Steve and talked it through and said, Hey, like, this is what we're trying to do. Wouldn't it be great to collaborate? He said, yes, it would. And so here we are. Um, and so I think going back to the question about what differentiates Drupal CRM from the other projects, um, I think it's that this one is very community based, right?

We've got different individuals in the community who are contributing, you know, for their own reasons, for, you know, different use cases that they have. Um, whereas some of the past projects have been heavily agency sponsored and really focused on meeting the needs of those agencies, uh, clients, which is great, right?

And like great to have, you know, the, the power of those agencies, right? But I think one of the challenges is. Those agencies don't no longer have clients who need work involving CRM, then they're less incentivized to continue contributing to it. Um, you know, and in these economic times, you know, they gotta cut back.

They're, they're probably not gonna be contributing to something that's not benefiting their clients in their bottom line.

Nic: Yeah. I think, I think that makes those all make sense. Um, speaking of the kind of feature set though, what, what are some of the key features available out of the box in Drupal CRM today?

And Steven specifically is curious about the email capabilities. Um, 'cause a lot of CRMs, a a lot of the relationship management part of it is communicating with the context.

JD: Yeah.

Nic: Um, how, how does that work?

JD: So I should, I should start by differentiating between Drupal CRM. Project, right? It's under the CRM namespace and the concept of a broader ecosystem around Drupal CRM.

Nic: Okay?

JD: Because, um, the CRM project itself, uh, is very much designed to not be very much, right? Like, we're not trying to build a ton of features into this base project, right? This base project is the, the, the core around which the ecosystem will, you know, revolve, um, and, and extend. So, Drupal CRM itself, uh, just has, um, you know, these entities that we've talked about.

So tracking your contacts and your relationships. Um, we've got a concept, concept of contact methods, right? So outta the box address, email and phone number. Uh, I think one notable thing about our representation of these is that they are, uh, these are, this are fe fieldable entities. Right. So if you want to track information about everybody's email address, let's say they're opt-in or opt-out status for being contacted, right?

And you've got a specific need to track that in a specific way, that's very easy to do. You can track that information per email address, right? Um, and so we, you know, provide out of the box a concept of a, uh, method detail. So for a phone number and address or an email address, is that a home number? Is it a work number, right?

And that's extensible as well. Um, so those are some simple things outta the box. Um, we also have a, a pretty powerful, uh, integration with the user entity. So you can map a CRM contact with a Drupal user, um, in a, you know, one-to-one, uh, way such that, um, those two things are representing the same person. Um, and it also, uh, facilitates access control.

So a user can have access to edit their contact information by virtue of being mapped or linked right to that contact in the system. And that means you can have users logging in, um, to edit their information. And then, uh, we have planned, um, you know, better, uh, better functionality that allows you to, for example, have that user inherit access control from the relationships that their mapped contact have.

Let that sink in for a minute, right? So

Nic: yeah,

JD: if you have a relationship that is, um, like a member of a household, for example, and you want the person who has the head of household relationship, uh, to be able to modify the contacts for anybody in that household. Right, you could build some sort of plugin, right?

That, uh, helps provide that access. When the head of household's user logs in, um, they can navigate to their household and navigate to the contacts of, you know, members of the household and edit them directly, right? So that's not something that's exactly available outta the box, but the architecture supports it so that you can build whatever, you know, kind of custom access control, uh, functionality you need.

Another thing with, um, sort of contact mapping is you can map contacts to users. You can also, um, surface their fields on the user entity. So while the user interface for CRM is a little more kind of back office, sort of organization facing, um, the user edit form, right, which is where users already go when they need to edit information, they log in.

Uh, right, you can surface their. Whichever fields from the contact that you want, right? So if you want the user to be able to edit their first name and last name for example, but you want that data to live on, the contact not on the user, that's something that we support out of the box.

Martin: So jd, you've talked quite a bit about sort of user information and access.

I'm curious what kinds of security features are built into Drupal CRM

JD: security features? Well, it really revolves around the entity system, right? So we, we use Drupal's, uh, entity system, um, you know, just sort of in, in the best practices way that you should with Drupal. Um, we do have different permissions.

Uh, we're working on having finer, uh, grained, uh, permissions, uh, to allow people to, you know, uh, have specific permissions around editing, say, uh, different types of contacts or, or you know, the different types of entities in the system. Um. Ultimately, I wouldn't say there are specific security concerns with Drupal CRM, uh, you know, that are any different than any other, uh, project that provides entities.

Um, but certainly when you're dealing with, you know, personal information, PII, right, that's a top concern. Drupal is very good in the security space. Um, ultimately, you know, any developer's responsible for ensuring the solution that they're developing, you know, kind of meets their security needs. Um, but certainly triple CRM is not doing anything to get in the way.

Nic: So I, I, I think that's the specific question though. Like if, 'cause obviously this is built to handle PII, um, so do you, do you use like the field encrypt module or do you intend to add that or a recipe for adding that Very fair. I, I guess that would be kind of the question.

JD: Very fair. Um, we've talked a little bit about field encrypt.

I think that's the kind of thing we would expect the ecosystem to provide. Right. Uh, and so this goes back to like, Hey, you want X feature, right? That's what the ecosystem is for, for the most part. Um, but certainly there's, there's nothing in the, the base module, right? For CRM that would prevent somebody from doing that, uh, using the field encrypt module to, to encrypt whatever information they want.

Um, maybe the trickiest piece would be, you know, some of the, the fields that come by default. So we leverage the name module, right, to, uh, capture different components of, of somebody's name, first, middle, last suffix, you know, et cetera. Um, and you don't have to use that field, right? You could, you could work around not, you know, not use that field.

Um, but I don't know how you would go around encrypting, you know, that field that's sort of already, already there outta the box. I'm just not, not that familiar with it.

John: So. One of the stated goals of CRM is Core First and, and being Drupal native. And I'm just curious, like, you know, what does that look like in practice and, and why does it matter to, to you guys as far as maintainers of this project?

JD: Yeah, so Core First, you know, basically means there are features that triple core ships with and we should integrate with them, right?

We should leverage them to the best, the best of our abilities. So that means we integrate with the search capability that comes out of Triple Core.

John: Hmm.

JD: Should we also integrate with Search API? Yes. And I think that probably belongs in the ecosystem, right? I could imagine a CRM search, API, uh, you know, module that.

Uh, that does that. I feel like Nick is telling me new news here that's coming

Nic: up. Yeah. Uh, the search box is being deprecated and removed from core, just so you know. Oh,

JD: yeah. Well, okay. Fair enough.

Nic: Yeah, just so we, just so you don't do that. I think I knew that to integrate.

John: Can we, can we take a two second, uh, uh, side side tangent into that.

What, when is that happening, Nick?

Nic: Um, probably for Drupal 12, I mean, it's slated for removal

John: and, and the, the, the core, uh, the core suggested path forward is search API.

Nic: Yeah. I mean, very briefly, because this is a bit of an aside, but very briefly, one of the new philosophies, one of the things that, one of the greatest things I think that CMS has done, aside from the evangelism and an easy outta the box solution, is allowed the core team to kind of evaluate things and say, is this something that Drupal should do out of the box?

And most people would say, yes, search is something that it should do. But the truth is, anybody who ever implements search in Drupal uses search API, period. Drupal CMS comes with a recipe outta the box for it. And even if you want the simpler version of search, it's still gonna be a module. Like, it's not like con core goes, we're we're moving this out and it's deleted.

You can't use it, it just becomes contrib. The truth is search is very complex. It's hard to maintain, hasn't had a lot of updates, and it doesn't do what it needs. So, uh, search API covers all the bases. And so yeah, the recommendation is to use search API. So yeah, if you, if you've already integrated with search, I think that's fine.

If you haven't done that work, I don't know that I would do that work yet. It, it's probably gonna be removed for triple 12.

John: There you go. So jd, back to the, the core first Drupal native question.

JD: Well, that's always a risk when you, uh, integrate with Core. It might go away, but that's true in in contra as well.

Um, yeah. So we, we wanna just leverage all the best practices in Drupal is really what that comes down to, right? So that you're not left wondering like, Hey, how come I can't do X because I can do it over here? Well, you should be able to.

Nic: Yeah. Makes

John: sense. How do you, how do you kind of, like, how do you kind of split that logic, right?

Because like core first, great, like, hey, I'm gonna, I'm gonna align myself to the core set of modules that do a thing, right? Um, sometimes there aren't core modules that do a thing that might be necessary for your project, right? So, um, when you have to select kind of a module to bring into your ecosystem, is there some sort of process there that you are looking at to kind of say, okay, um.

You know, this module, uh, aligns itself with Core as well. Like let's choose this one over this other one because they don't, or is there, is there some sort of, um, you know, I don't know, is there some sort of selection process when you can't be core first that you kind of go through?

JD: Yeah, it's a good question.

And I think, you know, it would be great if we had like a written, you know, documentation of like, these are the criteria for, you know, inclusion integration with Rupal CRM. The reality is it's sort of on a case by case basis and, you know, balancing concerns. Um, we're not opposed to integrating with, you know, contra projects.

Like obviously that's sort of the whole point of building an ecosystem right around triple CRM. Mm-hmm. Um, and when we do find something that Core doesn't provide, um, we're, we're trying to build that and we're trying to build that in. Whatever way will benefit the Drupal community most. Um, so if Drupal CRM needs some functionality, uh, it doesn't necessarily need to be built in the Drupal CRM namespace, right?

We're not, we're not trying to own every piece of the puzzle here, all the building blocks, we're trying to leverage Drupal. We'll push things upstream, uh, when we can. Um, so a great example, uh, would be the primary entity reference field, uh, module, um, right, which is basically entity reference, but it lets you choose which of the referenced entities is the primary.

And so we use that for contact methods on a contact. So you can have a primary phone number, a primary email address, uh, et cetera. Uh, and so that's something that you know is relevant outside of Drupal CRM. And so here it is, and it's now available for anybody in the Drupal community to use, and we, we hope they will.

Um. We also have integration with the group module. Um, and I'm trying to think what else we integrate with. It's on our homepage.

Nic: I mean, it, it says that you, uh, integrate with comment, navigation, search and group. Um,

JD: yeah, so we use, we use chorus, you know, comment for, um, yeah, a lot of

Nic: which is also moving out, I think at some point, although it's not, it's not for Dral 12, but there's discussion.

You

JD: killing me, Nick. You're killing me. Um, you know, navigation, uh, is another example and in Dral core, so, you know, I think it took a few lines of code and just make the navigation bit work well in, in CRM. And so we're, we're committed to doing that, right? And helping to move forward whatever the core initiatives are.

Nic: I, I also just wanna mention briefly, Steve Ayers is following along and thank you for listening. Uh, he wanted us to mention that there is a plan on the roadmap for field encryption. We'll have the link, uh, to the issue in the show notes, uh, after the show. I

JD: should also note, um, and this is not to say this is not what's happening, but, um, we're using the Drupal CRM issue queue to track feature requests, not just for the base module, for the ecosystem.

Um, and so there, there may be things, uh, that are feature requests that we're kind of keeping open or keeping around in Drupal CRM that we wouldn't necessarily consider for the base project. Um, but we would move into a new project, you know, when somebody steps up to, to lead that, uh, that effort. Um, and I don't know if, I think Core has like a core ideas project or something like that.

I don't know. Maybe to avoid confusion, we might do something similar, but I don't know how that's working out.

Nic: The core ideas q has gone away. Everything's moved back into the core queue. So, yeah, I swear I was just there the

JD: other day. But

Nic: yeah, no, they, they, they moved everything over. 'cause again, it was confusing to just have two places.

Um, so yeah, they, they, they removed that I think last year at some point. I wasn't involved in that part. I just saw my issues move over.

Martin: So for somebody not using Drupal today, but interested in building their own CRM, where's a good place to start?

JD: So certainly, um, if they go to the, uh, project page, um, we've got a few different ways for them to get started with Drupal.

CRM, you know, the big green button I mentioned earlier. Uh, to launch an instance on simply test me, just lets you click around without, you know, having to commit too much effort. Uh, we also have instructions for getting set up using D Dev. Uh, we've got those instructions both from a sort of user end, user facing, um.

Perspective. And we've got a recipe that has, uh, characters from the Simpsons, uh, that we populate the CRM with. So you can see how contacts and their relationships and their households kind of all interact with one another, uh, without having to kind of come up with that scenario yourself. Um, and we also have instructions for if you wanna contribute to Drupal CRM and get set up with d Dev, uh, you know, with the right steps to contribute back to the, the module.

Um, you know, we'd love to love to have you there.

Martin: Have you guys talked to any of the guys over at Drupal Forge about maybe having a profile set up there with CRM?

JD: We have and, uh, we're, we're definitely interested in, in making that happen. Um, uh, yeah, as a, a good way to help people, uh, get exposed to Drupal CRM.

And that's really one of the challenges we have, right? Any project has, is like getting the word out and getting known, um, so that people know it exists, know why they should use it, and then they actually use it.

John: Jd kind of building on Martin's question a little bit, um, I'm wondering if you have any insight or suggestions for somebody who's like evaluating CRMs and like how, you know, how they might either, either lean into Drupal CRM or, or maybe figure out another CRM is, is, is a, a better choice for them?

JD: Yeah, and it's a, it's a tough question. Um, and it's kind of funny. Um, this is a question that my wife, who is not at all involved in the Drupal community, has been, uh, focused on, um, uh, she runs a consultancy called Good Egg Solutions. Uh, and uh, her focus is on helping organizations figure out how to, um, make those sorts of decisions around their CRM, especially if they've got an existing CRM and they're not happy right, with how they're using it.

You know, should they stay or should they go? Um, you know, should they invest in improving the CRM and their usage of it so that it's meeting their needs, or should they invest in evaluating other solutions? Uh, and, you know, choosing one and, and jumping to it. So I would certainly encourage anybody, uh, you know, to go to her.

She doesn't know anything about Dr CRM except that it exists really. So she's not gonna be biased, uh, towards that too much, um, apart from being married to me. Um, but yeah, you know, it's a, it's a, it's a tricky, it's a tricky question because every organization has different requirements. There are so many CRMs to choose from.

Where do you start? And I think

John: the one, is she home right now? I feel like, I feel like we probably just wanna bring her in and, and

ask.

JD: I should bring her in. She's, she's not actually at home right now, but

John: if she was, I'd

drag

JD: her in here

John: too. Too bad. Too bad. Maybe, maybe a follow up show

JD: for sure.

Nic: Just a, just another quick comment from the livestream.

Um, Mor Morton, a 42 yt mentioned that the DD demo was very easy to set up. So. It's an endorsement, so

JD: fantastic. Glad to hear it. Um, I to the question of like, what, what CRM should you use, right? Um, for many, many organizations the answer should be an open source CRM, right? Um, so many reasons to choose an open source.

CRM cvi. CRM is the, the leader in the open source CRM space, in my opinion. Um, but they're very much focused on nonprofit use cases. There's nothing saying you can't use that for, you know, commercial enterprise, right? It's just not really optimized for it. Um, and I don't know of an open source. I mean, there are other open source CRMs out there, but I don't know of one that's like really killing it when it comes to, you know, meeting or, you know, large organization needs.

And I think that's where Drupal CRM could have an impact because it straddles the line between, um, hey, here's a CRM that you can use out of the box, and here's a CRM that you're fully custom. And

John: I'll say, and the reason you, and the reason you say to select an open source, CM, CRM, is that, is that around data, data ownership and that sort of stuff?

JD: Definitely around data ownership, data residency, vendor lock-in is a, a huge problem, right? There are a lot of organizations that have their data tied up in Salesforce and they're kind of running for the exit. Um, and there's a lot of friction. There's a lot of cost involved. We need to do that. You know, you're, you're stuck with that organization's policies, whether they're policies you disagree with or it's just a price you don't like or service is not good.

Um, so, you know, with an open source solution, uh, you're, you, you own the data. You can always take your data and your CRM and move it to a different hosting provider. You know, if that's where the, the problem lies. And if you don't like a feature or if there's a feature that's missing, you can implement it or you can pay somebody to implement it.

Right? With a, a lot of commercial, uh, CRMs, like, you're just sort of stuck, right? With the functionality that's, that's there out of the box.

Martin: So, jd apologies if this is actually maybe a question your wife would be better positioned to answer, but, you know, talking about some of the pitfalls, are there common pitfalls that organizations run into with CRMs as they grow?

So maybe they're happy with a feature set initially, but you know, a year or two down the line there's sort of common pain points that maybe they didn't anticipate.

JD: Well, I might not know so much about this if I weren't married to Laura. Um, but uh, yes, I have overheard from her in some conversations, um, that one of the big issues is around training, um, and documentation.

So organizations often make a big expense. They make a big decision. They say We're gonna take, you know, take on the CRM, we're locked into our three year contract, and, um, you know, this is what we're doing and we've paid, paid our money, but they haven't allocated the funds for ongoing training and professional development to leverage that investment so that they can really make the most of it.

Right. So whether it's a consultant coming in to, to help them, whether it's, um, you know, just courses that they can take or dedicating time to understanding how to use the CRM to properly customizing the CRM for their needs. I think a lot of organizations have a CRM and it's configured one way for everybody who uses it, but actually they have different roles in their organization who need to use the CRM differently, right?

Somebody who's focused on managing donors and those relationships, they don't need to see the side of the CRM that's tracking vendors, right. But here it is staring at them on their dashboard when they log in, right? So it's, it's things like that where there are opportunities for improvement.

Nic: Uh, I will say too, as, as somebody who's implemented and maintained several CM CRMs for clients, I would say that the two, there's kind of two buckets you, that most clients fall in.

Some clients need a very restricted CRM, right? They don't want any customization. They have a hyper-specific industry. There's a specialty service that does that. They know that use case perfectly well. Um, and they want to, they want to use it. Uh, an example of that is, um, theaters, right? They, they want like a membership package that handles the ability to like sell and buy limited tickets and all sorts of things like that.

Like there's a lot of really niche things there that yes, you could build and Drupal, but there are services that provide that at a cost that's probably lower than it would take to build out of the ps, and you have support, right? The other side of it is people generally need something that's gonna grow with them.

We'll need the ability to build not just custom data models, but custom routines. And that's something that Drupal being open source and being able to not have vendor lock-in is really powerful. I've done that in work in Salesforce. It is, I mean, the clients that are successful with Salesforce have a dedicated Salesforce development team.

A and I mean, when I say team, I mean team multiple people where their only job is to only handle Salesforce tickets and talking to their support. Um, and if you have that budget and you want that enterprise level, uh, support and fallback, like you need the, the IBM of CRMs, you need to have somebody you can sue if something goes wrong.

Salesforce is kind of the way to go, but if you want to control that data yourself, you need that flexibility and you have somebody who can make sure the data is protected properly. Open source Drupal. That's, that's the way to go. I mean, you, you definitely have precautions you have to take that you don't have to take with a normal Drupal site, but that's true of any CRM solution.

JD: I agree. And I think the question of support is such a good one. Right. Well, what support do you get with Drupal CRM? Well, you get sort of developer support, uh, free community-based support. Right. Um, you don't have a service provider that is actually responsible for the, the delivery, right. Of the, of the CRM.

And my hope is that there will be such providers built on top of Drupal CRM, right? I would love to see SaaS managed, uh, Drupal CRM solutions out there that, you know, a customer can hand over their credit card and have support.

Nic: Yeah.

JD: And have hosting, uh, and, and have that company be contributing back into the Drupal CRM ecosystem, um, and helping ensure it's, it's longevity.

Nic: Yeah, I think that makes sense. So you, you mentioned this a little bit earlier, but to put a finer point on it, um, this project is very much community first, you know, Drupal community first. Um, it's influencing kind of the development. Uh, how, how is it influencing kind of long-term sustainability and how is it influencing the direction that the project takes?

JD: That's a good question. I'm not sure exactly how to answer it, but maybe I'll, I'll deviate from the script a little bit and, you know, talk a little bit more about an example. Right. So with, um, the member platform initiative, right, there's a, a set of functionality that we wanna build and we wanna build that upstream to benefit anybody who wants to use Drupal CRM.

Um, and we want that functionality to be upstream and benefit anybody who's using Drupal to the extent it makes sense for their use cases. Um. So, you know, if we talk about, say, uh, communicating, you know, with members or communicating with your contacts, right? There are solutions today to do that. Um, with Drupal users, you could use, um, easy email as an example, right?

That gives you a form where you can compose a simple email and select the users that it gets sent to, right? So we have a CRM email, uh, project that to start with is just going to basically take that form and say, Hey, actually, instead of selecting users, you're gonna select contacts. Right?

Nic: Okay.

JD: Very simple solution.

Now, you can send emails to contacts regardless of whether they have a user account, um, but long term, right? I would love to, uh, to take that and turn it into a MailChimp killer. Right. So MailChimp, uh, focuses on marketing, uh, emails. Um, so you want to create an email campaign and send it to a segment of, you know, your contact list and track information about opens and clicks and react appropriately to bounces, uh, et cetera, right?

I think that's something that Drupal, uh, is well suited, uh, to, to doing, and that's the kind of thing that I would love. To see the member platform initiative and the CRM community rally behind and create some, some tooling, right? I imagine using Drupal Canvas, uh, to visually compose your email, right, with different blocks, and here's an image and here's two columns and, and this and that, right?

How incredible would it be to see that in the grease note, you know, uh, at the next, uh, Drupal Con North America? Um, and, and here we are, right? We're, we're using our Drupal CRM, we're sending emails out. Uh, we're, we're tracking everything appropriately. Like that's just a one example, right, of sort of a feature that we could build around the ecosystem.

Uh, and that's really, it's all about community, right? It's about getting everybody involved and focusing on the right issues to, to move us forward and, and, you know, have an impact and have Drupal do something well that it hasn't done well before.

John: Oh,

Nic: that's inspirational. I can't wait.

John: So

JD: seeking volunteers.

John: So speaking about that, right, Nick, Nick talked about, uh, sustainability. I'm wondering, um, is the development of this project funded or, or supported by any organization, or is it simply like, Hey, here's my free time that I'm donating to, to CRM?

JD: It is very much a volunteer effort. However, we're very fortunate, um, that Steve Ayer's employer, uh, gov Webworks, um, is sponsoring his time.

So they're sponsor, they've been sponsoring 16 hours of his time every month for, for over a year now, uh, to work on, on Drupal CRM. And I think it's notable to say that, that they, and they're also their, I think real name is Portland Webworks. They don't actually use Drupal CRM, they don't have a client that needs it yet.

Right. Um, that's really just a community investment that they're making. Um, and we would love to have other agencies and other organizations out there who will fund some of this work. Um, so definitely would encourage them to get in touch. We're, we're easy to get ahold of. Um, and yeah, we, we definitely could use, uh, financial assistance to dedicate more time, right, to moving this stuff along much more quickly, uh, to bringing more people on board.

Uh, we could use, you know, volunteer of, of hours. Um, we need folks of all different skill sets, not just developers, right, to be, uh, volunteered or voluntold by their organizations to help, uh, help with this initiative. Um, so yeah, we would love to have more, more people involved.

Martin: So looking ahead, what's on the roadmap for Drupal CRM and what are the priorities for the next year or two?

So, you know, when can we expect to see a 1.0 0.0?

JD: So you should expect 1.0 0.0? Um, definitely within a year. That sounds like a long way off, right? I don't think it actually has to take that long. Um, there are really two features that we wanna make sure that we are supporting before we tag one, 1.0 and kinda have a release candidate.

One would be, uh, fieldable subtypes for contact types. So, uh, let's say that you are a, a higher education institution and you've got a lot of people you need to track, right? So you've got a person contact type to track them, but some of those people are students, some of those people are employees, you know, some of those people might be visiting researchers or who knows quite what, right?

And there are different sets of information you need to track about each of them. We don't currently have a, a good way right. To do that out of the box. Okay. So we're still working on the solution, uh, to that, but I think it's sort of vaguely in the direction of the profile module, right? And how you have different profiles for users.

You could have something similar, uh, for contacts where if, you know, anybody who has the contact profile has these sets of fields, and any person who has the employee profile has these sets of fields. And in that way you're not cluttering the contact, uh, the person, you know, bundle of the contact entity, um, with all the fields, many of which may not be relevant to a given person.

Nic: Okay.

JD: Um, so that's one. And then the other one that's now escaping my mind, where'd it go? Um, well,

Nic: so

JD: I'll think of it about it.

Nic: So, but you th you think both of these features will be, um. Ready within the next year. And then,

JD: yeah, I mean, definitely. Um, oh, the other one is one I already mentioned. It was the contact access granularity.

Right?

Nic: Oh, okay. Yep.

JD: Um, so yeah, there, there's, there's a lot to that. I don't want to di dive into that one too much, but just basically making the, the access control system a lot more flexible, um, uh, and, and putting that power right in the hands of the developer who wants to do something sophisticated and, and providing them with the, the infrastructure to do that.

Nic: So, so I imagine a lot of that will rely on the access policy API then, right? Because that's kind of the new way to do that in Drupal.

JD: Yes. I think it depends on, on the use cases. I would imagine we will use the access policy API for some of it. Um,

Nic: okay.

JD: Maybe not for, for every use case. Um, but the Access Policy API is fairly new to me.

I learned about it at, uh, Florida Drupal Camp, uh, a couple months ago. So, uh, definitely need, need more time to, to process it.

Nic: Yeah, it's pretty, it's pretty complex. It's, um, it should be able to cover most scenarios. I mean, it was built to be kind of very, very, very flexible. So, um, I think as you, as you learn it, you'll, you'll be happy.

Any other, before we close out the show, any other kind of roadmap, things you want to highlight? Maybe, maybe not crucial for 1.0, but things that are coming.

JD: Yeah. And this is really more around the, the ecosystem, right? Than Drupal CRM itself, because I think, except those two features that I mentioned, the base project is mostly feature complete, right?

Like, we're not, we're not looking to do a whole lot more in that base project. We wanna really wanna focus on the ecosystem. We already talked about CRM email. Uh, there's a CRM membership, uh, project, uh, whose focus is on representing memberships. Um, and there are a lot of. Things you need to be concerned about when you're tracking memberships.

Like, when did it start, when does it end? Uh, you know, what's the duration? Does it happen on a rolling timeframe or a fixed timeframe? Is this a a calendar year from the time you purchase it? Or a calendar year, or sorry, a year from the time you purchase it? Or a calendar year that starts the next calendar year, back dates to the previous calendar, right?

There's a lot, a lot to, to deal with there. Um, so that's the place to handle those representations. Um, uh, uh, has, uh, uh, created an integration for that with Drupal Commerce, uh, which is pretty exciting. Um, but this stuff is all very early and is gonna need a bunch of refactoring, um, CM membership as, as well as probably the CM membership commerce.

Um, so a lot of potential there. There's also a whole sort of, uh, a whole nother, uh, initiative here that's sort of related to, to CRM and and member platform, and that's around event registration, uh, involving contacts. So, uh, the entity registration module is sort of the obvious choice for, you wanna track somebody registering for an event.

Matthew: Yeah.

JD: However, it only supports Drupal users as the registrants. And in the CRM context, we need to track contacts because they may or may not have a Drupal user account. Right. If somebody attends a meetup and I want to, you know, track their attendance, but I don't have their email address and I don't have, you know, they don't have an account on my site.

Right. I wanna be able to track that. Uh, and then Yeah. But, but have it be part of the, the registration process. Um, there's the, uh, event project and the event name space. Uh, my hope is that, uh, we can kinda rally the community around using that, uh, to track, uh, or, or to, to be used as the entity to represent an event.

Build a whole ecosystem around, okay, you've got an event, not just a content type with a date, but you've got an event, right? That means certain things, right? Either, certain things that an event has, let's build a bunch of features around that, right? So part of that would be, uh, something like Drupal CRM event, uh, that would provide the glue between CRM contacts and, uh, the event module and the entity registration module to allow contacts to be registered for an event.

Um,

Nic: yeah. And I think there's also the recurring events module and obviously Smart Date, which Yep. Handles recurring events. Um, and I'm, I'm smart, I'm sure Smart. I'm sure Smart Date would, o one thing that I think would do some work is like the concept of instance right? Is a little bit more ephemeral.

Like, it, it's not, it, it's uh, I don't even know what you would call it 'cause it's. It's like an instance of a rule of a field.

John: Oh, it's an instance of a series. And then how

Nic: do you define instance of a series,

John: what the series is?

Nic: You, you, you're muted.

Martin: So yeah. Within smart day, we do call them instances. There are ways to associate instances with external entities, but that's like a whole rabbit hole that, uh, we're probably gonna get into right now.

John: I feel like, I feel like we should have this, this panel back and, uh, talk about events in Drupal. I don't know.

JD: I think events in Drupal would be a great topic, and there are a lot of people who are working on events in Drupal in sort of different areas of the contra community, and it'd be great to get 'em all in one room.

John: Hmm. All right. I'll add that to a list somewhere.

Nic: All right. Thank you JD for coming back and joining us again. It's always a pleasure having you.

JD: Thanks for having me back.

John: Do you have a question or feedback? Reach out to talking Drupal on the socials with Handle Talking Drupal or by email with [email protected]. You can connect with our hosts and other listeners on Drupal Slack and the Talking Drupal channel.

Nic: And if you would like to be a guest on Talking Drupal or our new show, TD Cafe, you can click the guest request button in the sidebar that someday I'll add back, uh, talking drupal.com.

John: You can promote your Drupal community event on Talking Drupal. Learn [email protected] slash td promo.

Nic: You can get the Talking Drupal newsletter to learn more about our guest host show news, upcoming shows, and much more. You can sign up for the [email protected] slash newsletter.

John: And thank you patrons for supporting talking Drupal.

Your support is greatly appreciated. You can learn more about becoming a [email protected] and choosing the Become a Patron button in the sidebar.

Nic: All right, uh, jd, if our listeners wanted to get in touch with you, had some ideas and wanted to contribute to CRM, what's the best way for them to do that?

JD: So they can find me, uh, at jd leonard on drupal.org or jd leonard.net, or just search for JD Leonard and avoid the musician that comes up first in the search results.

Nic: And how about you, Martin?

Martin: Folks can find me as man clue on all the Drupal and social platforms, but I will also be at the AI Summit next month and would love to catch up with folks there.

Nic: John, how about you?

John: Uh, you can find me [email protected] or on social media and drupal.org at John Zi, and you can find out about [email protected],

Nic: and you can find me pretty much everywhere at Nicks van N-I-C-X-V-A-N. See you guys next week.

John: And remember, if you've enjoyed listening, watching, perusing, ingesting, or digesting, we've enjoyed talking.

Have a good one, everyone.