Integrating F&O and CRM with Dual Write: Johan Persson's MVP Journey and Personal Passions

Mark Smith: 0:06
Welcome to the MVP show. My intention is that you listen to the stories of these MVP guests and are inspired to become an MVP and bring value to the world through your skills. If you have not checked it out already, I do a YouTube series called how to Become an MVP. The link is in the show notes. With that, let's get on with the show. Today's guest is from Stockholm, sweden. He works at Engage Group as a senior specialist. He was first awarded as MVP in 2023. He is co-host of the Swedish podcast. Now I can't pronounce it. I'll let him pronounce it when he joins. But it's all around Dynamics updates and his main area of expertise is in infrastructure. Also does a lot of work in the Microsoft Dynamics and the Power Platform. Also does a lot of work in the Microsoft Dynamics and the Power Platform. You can find links to his bio, social media etc. And his podcast in the show notes for this episode.

Johan Persson: 1:12
Welcome to the show, johan, thank you. And thank you for that nice introduction. So one of the podcasts is actually in English and that's called Dynamics Update. So that is the English one, and then I have two others in Swedish. So those are not related to Dynamics. They are like a gadget podcast and just like a Windows infrastructure podcast, since that used to be my profession, more than the Dynamics side.

Mark Smith: 1:40
Nice, and what are the names of those podcasts? The other two?

Johan Persson: 1:43
Yeah, so the other ones are called the Nerd Herd, which is the IT infrastructure podcast, and the other one is called En Liten Podom Ite. In English it's A Little Podom About IT.

Mark Smith: 1:59
I'm interested to hear more about this podcast Before we get there. Food, family and fun what do they mean to you?

Johan Persson: 2:15
So food is is nice, um, but uh, I sort of, as many others, has a sort of a complicated situation with food. I, I, I try to to keep it to like a reasonable, but I like good food, that's nice. What was the other words?

Mark Smith: 2:29
Family and fun.

Johan Persson: 2:31
Family is important, but family doesn't always only mean relations, relatives. It also means very close friends, so those are also very important. I realized that, especially during COVID, that you need to keep people close to you because otherwise you will have a miserable life.

Mark Smith: 2:54
So true, so true. And then, finally, what do you do for fun?

Johan Persson: 2:59
For fun. Most of my fun things is, at least according to my wife, very similar to my work things. So I'm in front of a computer, coding, writing blog posts, doing other technology things, which means that she's annoyed with me because she says that I'm always working and I tend to say that I'm not.

Mark Smith: 3:24
I like it. I like it the best things to do in Sweden. If I was to visit, which I've been a couple of times now but if I was to come back outside of Stockholm, what do you recommend?

Johan Persson: 3:38
Yeah, I mean I like skiing, so going to northern part of Sweden and and skiing in the winter is really really nice. But also I mean we have we have great summers here. It's not as warm as as many other places, but it's I mean in june and july. Right now we have like 30 ish degrees centigrade, 25, 30-ish degrees centigrade, so it's a nice summer but it won't kill you, so to speak.

Mark Smith: 4:12
So that's nice, really nice, really nice. Tell me what area of the tech stack with Microsoft is your focus, because it's such a big area, right? What are you really focused on these days?

Johan Persson: 4:30
Yeah, so I come from a more Windows traditional infrastructure background where I used to work with servers and clients and mailboxes and stuff, and then about 10 years ago I started working more as a technical specialist on the Dynamics side, more exactly on the F&O side.

Johan Persson: 4:49
But I tend to tell people that I don't know that much about F&O because I mostly work outside of the application.

Johan Persson: 4:55
I mean, I don't know how a chart of account works and I don't know how our warehouse works, but I do know how integrations works and recently I've tended to take the place of doing the power platform integration stuff, the dual byte stuff and those things, because I realized that people that are in the F&O space are regularly normally just in the F&O space and people who are in the CRM space is only in the CRM space. There is basically no one who is in both, which means that especially dual right tend to be a bit misunderstood because no one really understands how it works and you tend to try to map it to something that used to work in the old platform, in the AX 2012 and the on-premise CRM time space, which means that and that's not how Jewelrite works it works a bit differently than you're used to from regular integrations. So that's why I tend to take those parts, since I don't have the bias of how it used to be done. I only have how it's done right now.

Mark Smith: 6:24
Let's unpack Jewelrite a bit more because, as you say, there's a lot of people that either come from it from either side, or historic views, and I felt that in the early days of Jewelright it had a bit of a rocky start, isn't it? It had a bit of a rocky start, isn't it? Probably I feel like it was the marketing over-delivered on the application, but it's come a long way. Tell me, how do you explain Jewelright nowadays? And, yeah, how do you explain it to people? You know my concern straightaway when I hear Jewelright is I'm obviously going to be paying for database storage twice. Right, if it's writing to two different locations? Is it negligible? Is it a non-issue? Give us your breakdown of.

Johan Persson: 7:22
Jew right. Yeah, so first I would like to add that I was at the business application summit in Seattle when they first mentioned dual right and my first reaction was that is a lot of duct tape. Someone has pasted things onto F&O that is not supposed to be there at all, because this is completely different. And then my second reflection is that what people tend to get wrong here is that when I talk to CRM people about dual right, their opinion is OK, so you do dual right in F&O, so we don't have to care about dual right. That is as far from the truth as humanly possible, because basically, when you turn on dual right, nothing happens on the F&O side. Everything happens on the CRM side, and you need to understand that. But I agree with you, it has had a bit of a rocky start. There has been a lot of things that has gotten better, but I also think that a bit of the rocky start has come from the fact that people understand how integrations work, how integration used to work.

Johan Persson: 8:42
You have two systems that are not interconnected. You set up an integration platform. You look at your business processes and say we want to create a sales order that comes from here to here. Okay, so let's design a message basically from nothing. We start with a blank paper, we draw up a message, we say this is what we're going to send from here to here, and the only thing this message does is that it creates a sales order, nothing else. Okay, so we also need to be able to confirm a sales order. Let's do a new message. We take a new paper, we write a new message, we send it the other way. We need to update the sales order. Okay, so that's the third message. We take a new paper, we write a new message, we send it the other way. We need to update the sales order. Okay, so that's the third message. That's the thing. That's not how dual write works, because what dual write actually does it's in the name. It writes things in two different places. It writes directly to the other database, which means that it doesn't really care about your business processes, so what it only does is it replicates data from one field in the database to another field in the database, and you need to make sure that your business processes are supported at a much higher level in order for dual write not to screw things up, because when it does, it does it in a big way, and the problem is that the error messages comes from the technology stack, which means that they are not obvious for users end users, so to speak.

Johan Persson: 10:22
Also, as you said, what you hear is that you need to pay for database storage in two places, and that is absolutely correct, because you are actually moving data between two different databases. So you need to understand that in some cases you need to pay twice for database. In some cases you need to pay twice for database. In some cases you only need to pay. You need to pay the same thing because some data that you already have in F&O you already also have in CRM, so you're already paying for the database. So if we're talking about synchronizing customers, for instance, you already have customers in CRM and in F&O, so you're not paying double, you're just paying the same thing over again. But if you are adding data that is not in CRM from F&O, then you're paying more for it. So there are a lot of tables that are being added. When you add these solutions and those you will have to pay double for.

Johan Persson: 11:26
That is also the reason why, if you ask Microsoft, there is a necessary pattern to do this and there is a preferred pattern to do this. The necessary one is that if you do need data in both places, then dual-write is the way to go, but if you don't need data in two places, then virtual entities is the way to go. What you need to understand, though, is that there is a different licensing model when you use dual-write compared to when you use virtual entities. So in that case, maybe if you have just a few tables with not extremely a lot of data, with not much data in them, then maybe it's cheaper to actually do dual write. But what you also need to understand is that syncing data between two databases adds complexity. Virtual entities doesn't sync any data. It only exposes data in a different database, which means that you don't have to care if it's in sync or not, because it will always be in sync.

Mark Smith: 12:32
I like it. So, as my mind runs forward, in this world of, let's say, we add Fabric into the mix and I don't know if you have much experience with Fabric, but wouldn't it be better to put the F&O replicate the data inside Fabric and therefore, rather than because when we talk about database on the CRM side, we're obviously talking about Dataverse Would it be better then to make it available to Fabric and then consume it back in that way? What are your thoughts?

Johan Persson: 13:35
So the reason in most cases why I tend to almost always go with a dual-wide scenario is that that is the Microsoft recommended way of doing things. They have built it, they have doing things. They have built it, they have tested it, they have verified it and the whole point is that you need to create data, that is, since you're writing directly into the database, especially if we talk to things that are native to both CRM and FNO. You need to have things that the thing is using. The out-of-box experience means that you don't have to transform a lot of data. You don't have to care because it will always be in the correct format, which is basically turn it on, make the initial sync and it's done.

Johan Persson: 14:27
Basically, I think that in some cases, coming from a traditional integration scenario, people tend to sometimes overcomplicate dual write, but I totally agree with you that Fabric is a very interesting part coming into this mix as well. Very interesting part coming into this mix as well, because if you for some reason need the data in Fabric anyway for analytical purposes and you need to get it into CRM say, for instance, that you're talking about invoices, for instance. Or you're talking about sales orders you're not creating. Say that you're not creating your sales orders in CRM but you would like to be able to see them there, then I would definitely say that one of the patterns here is going with moving them out to Fabric and then using the Fabric connector to get them back into Dataverse in a virtual way. I would absolutely think that that is a reasonable path to go. A couple of other questions that come to mind. I would absolutely think that that is a reasonable path to go.

Mark Smith: 15:32
A couple of other questions that come to mind. I know this is not so much about your MVP journey, but a bit more technical. Tell me about is there any latency on the dual write as in if it's done in F&O to start with, is it instantly, is it real time?

Johan Persson: 15:51
Yeah. So the answer there is yes and no. Originally, everything is synchronous, which means that which also is a bit of the complicated one here, because if you use a traditional integration, you do something in FNO, you create the message, you send it over and then the other system decides whether it fails or not, and then in some cases you get a message back saying that this order wasn't processed correctly, and yada, yada, yada. The thing is that when you do your write, you actually write to both databases at the same time, which means that if one of the database writes fails during the update, you will actually get an error message. So if CRM doesn't exist, yeah, we take it the other way around, because FNO has much more business logic than CRM has.

Johan Persson: 16:48
So say that you're creating a customer in CRM and F&O doesn't have all the data it requires to create a customer, then it will tell CRM you're failing. It won't work. So it is instant. But when I say yes and no, the reason is that there is a public preview right now where you can actually set up some of the dual rate mappings as asynchronous mappings instead. So things that does not have to be instant will not be instant. They will be processed on a queue, basically more like FNO works right now, so basically a batch job, that's. That does the synchronization eventually and you will. You will end up in a consistent state, but not immediately so it's interesting what you're saying there.

Mark Smith: 17:40
let's say we're creating an account record in in the cerium system and in the fno system. An account record needs to have a unique identifier. In that scenario, when that record gets written, does it automatically know that that compulsory field which you know in CRM and model-driven would put a red star on it saying, hey, this is a required field? Do you need to make sure that both systems have those required fields captured correctly so if someone's entering it you are capturing all the data so it doesn't fire an error on the F&O side? But what about when the data to enrich that record can only come from F&O? How do you make sure that that process happens correctly?

Johan Persson: 18:23
There are a couple of different scenarios here. One is like the customer ID. We always have a customer ID in F&O. If you talk to the CRM people they are like we don't need a customer ID, we have a grid that's perfectly unique and we don't care about having a customer ID. So the easiest way there is actually to either you build like a service in FNO that provides you with a customer ID, so you basically query from. You build logic in CRM that queries FNO and gets a new customer ID, puts it into the correct field and then it's done. So you're basically using the same number sequence in FNO as you do in CRM. An easier way to do it is actually to basically split the number sequence in half and say half of it belongs to CRM and half of it belongs to FNO, and CRM creates its own customer IDs, but you make sure that they don't collide. That's basically an easier way. But since there is no default logic to do a customer ID, for instance, you need to provide that logic in one way or another.

Mark Smith: 19:44
My last technical question is does the dual write allow it to happen at a field level or do you have to have unique tables, as an only does a table to table map? What's the, what's the um, what's the granularity of dual right?

Johan Persson: 20:02
so it's basically record level. I would say it's triggered on field level but it's written on record level, which means that if I understand it correctly I don't know the nitty gritty details down to developer level but if I understand it correctly, you have certain fields that trigger a dual write update and certain fields that does not. But if you trigger a dual write update and certain fields that does not, but if you trigger a dual write update, then all of the mapped fields will be written.

Mark Smith: 20:36
Yeah, okay, that makes sense Cool.

Johan Persson: 20:39
So that's. But I would like to say a bit caveat here. But I don't really know exactly all of the details, I just know how it tends to behave, sort of.

Mark Smith: 20:53
Final question, because we're at time, is tell us about how you became an MVP. What was the process for you?

Johan Persson: 21:03
Yeah. So I first got recommended once and I sent in all of my submissions and nothing ever happened and I didn't get an email saying that I didn't get it or anything like that. But I eventually I got a second recommendation and the thing is that I got awarded MVP during COVID. So basically we were in complete lockdown when I got the email and I actually had COVID when I got the email. So I had like a 40 degree centigrade fever when I got the email, which means that I was pretty out of it. So basically, when I read the email and a bit after that I was like did I read that email or was it just like a fever dream or something? So it was a bit of a strange situation.

Johan Persson: 22:02
The very first meeting I had over Teams with the MVP community was one of these. In Europe we had these virtual MVP coffees during COVID where people actually could talk about basically anything. It wasn't just about our subject, it was like there were people with mental health disorders and stuff and one of the first ones that I attended was actually on imposter syndrome. So that was extremely fitting that I had this call right at that time, because I realized that it's not just me who has this? Everyone else has this at some point, so that was really nice actually.

Mark Smith: 22:58
The very last question now is any advice to aspiring MVPs.

Johan Persson: 23:05
Yeah, so I tend to quote. There is a guy at Microsoft that doesn't work in dynamics, but he's one of my absolute heroes. He's called Scott Hanselman. He has this very good quote where he basically says that in your lifetime you have a finite amount of keystrokes. Make them count, because if someone asks you for an answer to a question, don't just write an email to them and answer them.

Johan Persson: 23:36
Write a blog post which is basically the same text as you should have written in the email and send them the link instead, because that way, more than one person can get to understand what you're trying to teach people.

Johan Persson: 23:52
And also one more thing which I try to use myself as well is that if you have a blog post, for instance, that you want to write, you tend to think everyone already knows this, this is nothing new, I knew it.

Johan Persson: 24:09
Then everyone else must know it already. That is not true. And even if it is true, even if it is like just the most basic, simple thing, the fact that you write it down in your way of expressing yourself means that more people will get the chance to find it and more people will understand it. Because I mean, one of the things that I think, like Microsoft, learn is a fantastic resource of knowledge, but it's not very easy to find things there. So if you can write something in your words with a simple step-by-step guide referring people back to learn eventually when they understand the gist of the process, that will help people a lot. And also, you need to think that if you've had this problem, then others have also had this problem and people will continue to have this problem forever. So writing it down, not only for yourself, is a really good contribution, and it's something that you were probably going to do anyway.

Mark Smith: 25:26
Hey, thanks for listening. I'm your host business application MVP Mark Smith, otherwise known as the NZ365 guy. If you like the show and want to be a supporter, check out buymeacoffeecom forward slash NZ365 guy. Thanks again and see you next time. Thank you.