Bonus: Extended Interview with CJ Brooks, MISSION CRM

Welcome to the Amazing app show from Microsoft Dynamics 365 and Power platform app makers who want to build amazing business applications that everyone will love. 

Welcome to the show. My name is Neil Benson and I'm honored to have you join me. The goal of Amazing Applications is to help you slash your project budgets, shrink your delivery timelines, mitigate technical risks, and build amazing Agile Dynamics 365 and Power Platform applications. This is another special bonus episode. 

We did one of these last week with my interview with Bert Wijns from Power Accelerate and this time we're doing it with CJ Brooks from Mission CRM.  If you haven't listened to my first part of the interview with CJ, you'll find it at customery dot com slash zero two seven. That's the word customer with a Y on the end dot com slash zero two seven. I drop bonus episodes like this one when there's too much to fit into one episode, but I don't want you to miss out on the valuable content. 

And bonus episodes don't show up on social media, so the easiest way to make sure you hear them is to subscribe to the Amazing Apps show in your podcast player. 

In this bonus episode, CJ shares his dataverse data modeling designs to try and solve the Elon Musk problem. 

The art of simplicity, from both an application design and a licensing point of view and lots more besides. 

Here's the rest of my chat with CJ Brooks Fundraising and Engagement Architect at Mission CRM. 

One other challenge that I have in the industries that I've worked in, let's call it the Elon Musk problem. This is a data modeling issue, so Elon Musk is involved in The Boring Company with Tesla and SpaceX, probably others, there's just three. In Dynamics 365. I could model that is 3 different Elon Musk contacts, each contact associated to a different account entity, account record or account row, what do we call them now. 

Uh huh. 

Yeah exactly. 

Exactly. 

I'm sure there must be similar data modeling challenges in the fund-raising space, how have you tackled those? 

And there must be people who sit on the boards, for example, of multiple philanthropic organizations, or fund-raising associations. 

Have you found a clever way of data modeling your way out of that limitation of the common data model? 

Yeah, so I mean the the current data model model has some pluses it it has a lot of people that have thought about these different scenarios, but I should stress thought about it under the under the guise of typical nonprofit scenarios. 

And nonprofits are all about relationships so when you apply that to dynamics, you get some pretty obvious challenges. 

The typical primary relationship to the account record we like to use the account record for like several different things, even though it's a single entity and there's always that well. 

Do I create an entity specifically for that? 

One use case? 

Or do I just have different entity types and so that's why you see like accounts be household organisations, institutions. 

You know. 

We've also seen organisations that have done one to one scenarios. 

Right, there's a very popular fund-raising system, which I shall not name, which effectively ties each contact and creates an account record corresponding to it. 

So now, not only do I have organizations, I also have organizations that are actually contacts. 

So, when we were kind of looking at fund raising engagement and we're also looking at like Mission CRM. 

What we looked at is what was available to us, so we looked at the common data model and we're like we can look at some scenarios that we fail and our feedback from the user groups. 

So, like that doesn't really work very well in the case-by-case area and so we created a very specific relationship, but to households and accounts that leveraged what was in dynamics already. 

But then if you wanted to. 

You could promote contacts into households and the households could then could be a grouping as an individual company and we also created a specific dedicated relationship. 

Which allows you to keep your organization-based relationship and so now I'm going to look at a contact. 

I can see that contact is part of the lead household, but then I can also see that that contact is also primary organization, Mission CRM and so you know the power of just that extra relationship. 

Kind of really gave us a lot more flexibility on how to manage those specific relationships as well. 

But I can't help but feel that whenever it comes to Dynamics, CRM and relationships, there's always some kind of a compromise, right? 

Yeah. 

Like in the design and the architecture. And you're always trying to weigh these different scenarios and, and I don't think we've ever seen the most ideal solution yet, but I think we've got pretty close to fund raising engagement at Mission CRM. 

That's actually fascinating. 

I love to see how the inner workings of those relationships play out, particularly from a user interface point of view, because I think several times, I've been guilty of coming up with a great design. 

But when you go to implement it, it's actually a very confusing user interface that doesn't doesn't really help anybody or serving anybody. 

Yeah. 

And and you know what the other thing as well is like, like who's driving the design decisions because you know if you listen to the client like say it was a client-based delivery and it kind of goes back to that whole theme of. 

If you're developing or the customers driving the development, they'll have very specific needs, which in their mind are universal. 

Everyone should be doing it like this, right? 

And that's never typically the case. 

So, one of the things that that we've done and backs like the agile methodology is if we don't know the answer then let's just go implement less code, less development, but more easy to use, universally acceptable from an interface standpoint, because although we might not be getting as much information, we're getting it like 99% more consistently. We would go down that road. Release, review, feedback and then layer on an. 

I think that's where that agile approach really benefits to you like anyone like. 

If I did the design right now that design is outdated by the time I go and deploy it. 

So so instead of trying to forward think all these scenarios, let's see how things organically evolve. 

By not pinning ourselves into a design decision from the get go that were then having to unpick and they were having to then deal with the data ramifications as a result of it right so. 

I think you're right. 

I think the best way to figure out if a feature is appropriately designed is not to have six architects review it. 

It's to have put it into production in six different places and see how the users adopted. 

It's exactly, and if you're worried about things being too complex too ... then don't design complexity like reduce the functionality. 

See, but ensure the flexibility right and and and then you're not boxing yourself into any corners. 

Thinking about licensing and application. 

Microsoft got … I don't want to turn this into an episode about Microsoft licensing, but they've got their own licensing model and it's generally per user based, has Mission CRM followed that pattern with its own application licensing or have you gone for something much more creative than that? 

So, we we spent a lot of time trying to figure this out right. 

Originally were per user. 

But then it was like what about organizations that don't all do fund raising and you know they're like case management and some fund raising. It is unfair for them to pay for like 100 users permission CRM if there's only 20 of them that are actually doing it. And so, so what we've done for our existing clients is we kind of just like dynamics was originally like an honor based. 

Like licensing, where effectively is the number of fund-raising users that you have in the system. 

Is is how it is actually utilized now because of the complexities in managing that where we're now in our latest release for new customers, going to adopt a more standardized per organization licensing so I could have 1000 users, I could have 100 it really wouldn't matter, but we're going to license it based on the different levels of functionality. 

That you're consuming within the organization. 

We're doing that model for two reasons. 

Licensing changes are coming now in ISV Connect, which means there will be more flexibility in the future with the reality is licensing, whether it's Salesforce, Dynamics, whatever. 

It's already complicated enough so we didn't want to be an additional thing that people had to figure out. 

Whereas now we can go into competitive situation and just say you want pages? 

It’s this much, done. 

Like there's no, there's no questioning about that or whatever it might be and for us coming from non-profits, we gotta think about how our competitors are licensing as well. We have some competitors. They’re licensing on per per donor record. So, I might have 1.8 million contacts only. Only deal with like 100,000 of them a year. But I'm paying for that. You know Dynamics has its other ramifications. 

Consumption is like not great and things, but you know those are things that are there, at least actively putting the onus on the organization to say. 

We're not going to punish you for the number of records you have, but we are going to say that if you want to hold on to everything in the world, you can't expect that to be the same price as those that don’t. 

So, in many ways that consumption usage is is really very fair and like its licensing. 

Like you said, we could have a whole bunch of other topics of all different opinions on it is never going to be ideally what the client wants, which is cheaper than what they wanted it to be as well so. 

So, we went for simply simplifying on our end to like just per organization and three different tiers. 

And if you fall into one of those tiers, you're done. 

And then that way I think about the deployments and you're you're costing your licensing, your renewals and everything else you know now. 

It's really easy. 

I know that they only have that tier because I only deployed that tier, so they can't possibly access anything else. 

It doesn't exist in there and that makes it really easy for me for operationally to do my renewals. 

And manage that moving forward whereas before it. 

Like 

Give me how many licenses you’ve got. 

How many of them are fundraisers and they'll say? 

How do I know that? 

Right? 

Because it's all education thing again and and it just yeah, it just takes so. 

So long as we moved away from that per user licensing. 

So, so your licensing is basically there's two access. 

One is small, medium, large, and the size of the the organization that you're selling to. 

It's the features. 

Then there's a right OK. 

Yeah. 

So, it's a simple, intermediate and advanced. 

You got it, you got it and that way we can also be like, hey, if you want to use all these enterprise features, these cost us a lot to develop. 

And it also means that if you're using more of the system. 

You're going to be requiring more support and more training and more onboarding, right? 

So, it was a nice way for us to true up those that needed that actual resource capability from you, then those that were quite happy just doing their own thing with the donation pages or whatever. 

It might be too. 

They're also getting more value. 

They're also avoiding more costs of other systems. 

Exactly like one of the really neat things about this application specifically, and I say this for any application you know. 

Like every client is coming to the same story. 

I've got too many siloed data sources. 

I don't see a central source of truth, or how many times have we heard that story? 

It's like the common recurring theme of every CRM project. 

So, looking at building applications, you should also consider what applications can you consume in that marketplace. 

So, for example, when we were thinking about our features for Mission CRM, we were driven specifically by what would be needed, but also, what are our competitors lacking that required another system, another integration, and so we were very strategic. 

Like we built, donation pages were carrying. 

Integrations to change of address services and things like that right into the core of the product. 

Because we knew that our competitor or whoever I was speaking to, needed for or five different products to do that and couldn't get them all to speak together. So, you're in a incredible advantage if you were thinking of like applications that you can build that are needed. I think often an overlooked thing is actually what is the marketplace currently need you to do? 

In order to perform those functions and can you create an application that reduces the need for those other, different siloed pieces of data and that is then a great shoo in for a competitive advantage as well. 

Yeah, that's a really clever way of thinking about it. I love that. 

Final question for you CJ thinking about Microsoft's road map. As far as any of us can see that what does? What does the future look like for Mission CRM? What investments you excited about that are coming up? Where do you think, the product is going to go? The next kind of two or three years? 

We're really excited. 

We have actually, our spring release is almost on its doors, right? 

So? 

So, we'll be looking at shipping that out. 

And we've introduced some some really, really cool features. 

We've completed a peer-to-peer online fund-raising pages, so now organisations can spin up their own team-based fund raising. 

And of course, lack of integration is the key there. 

We're also pushing out our NCOA service, which means that as donors, addresses change and they get registered in their countries post office, they will actually update the system as a result of that as well, and including additional integrations to payment gateways to onboard new wallets and different types of funding and ways of giving that they aren't typically available as well. 

And one of our really exciting things that we're looking at doing towards the back end of this year is really getting to grips with all the Azure cognitive services we introduced. 

Azure Cognitive search just this early spring as well, which is going to be rolling out soon. 

And we're really looking forward to get our hands of the OCR stuff. Nonprofits they deal with papers, so if you can kind of find out ways to relinquish that paper use, then you are really into a winning product. 

And so, there's some really fun, exciting things that we're doing. 

And of course, all in that Azure environment which is our playground right now. 

Fantastic sounds really exciting. 

CJ I really appreciate you coming on the show. 

I've learned heaps about the challenges ISVs face building amazing applications. 

I'm working behind the scenes with a team in a completely different sector, but you’ve given me so much to think about. 

Thanks very much for sharing your expertise and your insights on the show. 

Oh, it's all my pleasure. 

Thank you so much Neal, and take care. 

CJ, shout out to you for joining me on the Amazing Apps show. 

I really appreciate you coming on and sharing your insights with us. 

If you'd like to find out how to start adopting an agile approach to building dynamics 365 and power platform applications, my free minicourse Agile Foundations for Microsoft Business Apps will teach you the benefits and basics of Agile software development. Give you a quick primer into Scrum, which is their most popular agile framework. 

And I'll share with you my recommendations on how to learn Scrum and get certified. 

A free mini course takes less than an hour and you can join at customery.com/foundations. 

Thanks so much for joining me in this special bonus episode. Remember if you'd like to share your story about an amazing application that you've built like Haniel or Bert or CJ have done recently, you can apply to appear on the Amazing Apps show at customery.com/guest. We'd love to help you share your success and the keys to your success with our community. 

See you next time, keep sprinting.