Site Menu
Mon - Fri 8am - 6pm

Integrating Microsoft Dynamics 365 CRM & Business Central: The Perfect Match

Microsoft Dynamics 365 Business Central and Microsoft Dynamics 365 CRM can individually bring a lot of great functionality, helping improve and streamline business processes. But how well do they integrate with each other? Both being Microsoft products you’d expect seamless integration, however, that hasn’t always been the case. We’ll be exploring what integration challenges we’ve come up against previously and what limitations users could expect, as well as how integration has moved on with more recent software updates. 

Discover even more episodes from the Tecman Talks Dynamics Podcast

- Welcome to another episode of "Tecman Talks Dynamics." This time, it's myself, Jason, in kind of the interview seat, as such. But I've got with me, Kelly, who also works in the CRM and Power platform team. So welcome.

- Morning.

- So this week, we are going to be talking all about integration. And specifically, integration between BC, Business Central, and CRM, or as I like to call it, CE. And going a little bit back down memory lane of what integration used to be like, in perhaps the days of NAV to CRM, now to what we've got in BC and CE from a SaaS perspective. So I think even my time over the past decade or so, I've been in this industry. I can use certain words to describe how the integration used to be, but I see you've been with us for a little while, Kel. So in the early days where we still had a number of customers on NAV, N-A-V, and integrating to CRM, even SaaS or even on premise, how would you have described how the integration was technically to support and implement back then?

- Challenging.

- Okay, and in terms of challenging, is that challenging in terms of the capability that it had, or is it more or less of how to set it up or how to change it or from what perspective?

- All of it. So it was very limited in what you could integrate. It was very difficult to extend, the setup of it. To be fair, the setup of it wasn't too bad until they changed the authentication in CRM, and it needed to use OAuth, then it became complicated again. And then in terms of just the actual data transfer itself, you had lots of issues with data conflicts where people had updated something in CRM and updated it in Business Central and then you'd get data conflicts where it didn't know what to do with the updates and the standard things of job queues errored, things like that.

- So I think we're starting on a bit a negative here, but the integration between NAV and CRM, years gone by was challenging. Dare I say, even go unreliable?

- Yes, I'd say unreliable. And I think from our perspective over the years gone by, we used to talk about, it's Microsoft. It's a Microsoft Package. Microsoft can integrate to each other. I can't remember what version it really was that NAV and CRM was now able to integrate to one another. I want to say it was easily about a decade ago, maybe around now, 2013, after kind of 2009 had exited and 2013 two or sometime around that kind of thing. And I'm sure someone will correct me, but we used to be able to pitch that, hey, we've got Microsoft products. Microsoft doesn't just talk to Word. It doesn't talk to Outlook. It doesn't just talk to Excel. Do you know what business application can talk to each other? And whether it was 2015 or wherever said, hey, we've now got this tool. And it didn't really live up to expectation, I guess, is the best way of putting it. Yeah. Even extending it was challenging, I think, in previous time gone by. But let's fast forward to more recent times. In the past, kind of, I'd say few years, I think probably the past 18 months, 24 months has probably seen the best set of improvements that we've had in a very long time in terms of the integration, and that's not just purely based on what you can do, that's based on how reliable it now is and stuff like that. I can say from my point of view, surely, have support calls come down?

- Oh, absolutely. Yeah. They've introduced some really good tools into the platform since, to be fair, they've been working on it since BC16 was the first major change to the integration that we got where we started to see the progress they wanted to make. And now we're up to, you know, 21 and looking at 22 now. And the integration now works. So they've introduced tools to help with things like coupling data together. So in layman's terms, basically what that means is linking the two records, so the record in CRM and the record in BC together, so the integration knows which record goes to which record. So previously, you know, in previous versions of Business Central and NAV, if for whatever reason your system got out of sync, you know, or you just needed to do mass data imports and link them together in both systems, you know, it was difficult. You had to get a Business Central developer to go off and write you a report to go and find the records that you needed. Run that batch report, it took forever. Now the system has the capability where as long as you've got unique identifying fields on either side, you can just use the interface to couple them together. So you just go into couple records, you pick the fields you want it to match on and it runs a coupling and it finds the ones that it can find.

- Yeah, okay.

- Obviously, you know, it doesn't always find all of them. Sometimes you have to manually intervene. That's working with data. That's the joys of it. So that's a main major improvement on the system. They've also introduced the ability to resolve conflict updates, which is the main reason our support calls have gone down.

- Yep.

- Because now you can tell it, you know, if an account is modified and a customer is modified, actually I want the customer to take precedence. So overwrite the account with the customer data or vice versa, you know, if you are linking contacts from CRM into BC and CRMs to master, you can do the other way as well. So you can just tell it which way to send the data update.

- So you've got... There's more options capabilities in terms of helping with data quality, clearly right now. So we'll come onto in a sec, around what options we now have with integration between BC and CRM. But if, let's just recap, based on years gone by, the NAV and AV integration to CRM was not great. It was there. It kind of did work, but it kind of didn't And we couldn't truly say it was a, do you know what? This is seamless. This is great. And dare I say, could have been used from a marketing point from Microsoft or a partner, that look, you can integrate your tools together. The reality was it was, it was challenging and it caused headaches.

- Yeah.

- Now that's far. We are far, far away from that fact. But previously, I think, what people did when they wanted to integrate the two tools together, if the standard didn't work, we looked at what development, old school development we could do to make it work or people would have to use other tools.

- Yeah.

- And those tools were KingswaySoft. They were Scribe before. They've now become Tibco. You were paying another licence fee and another product that probably would sit on a service somewhere years gone by. They would have to maintain to be able to integrate the two data together. And it took away this whole Microsoft platform kind of ecosystem, because it really wasn't as joined up as you wanted it to be.

- No.

- I guess is the best way of putting it. But now the positive is that we are light years ahead now. We truly do have this ecosystem of the platform available. So let's talk about the standard, what Microsoft give us out the box. So BC to CRM. It's controlled via BC, in terms of we have to go into BC to enable it and set it up. So out of the box, we've got... We can go into something called Dataverse and Dynamics 365 sales connection set up and we can create a connection into CRM.

- Yeah.

- But firstly, what type of licence do we need for that? Do we still need a sales licence to enable the connection to start off with, 'cause obviously, Microsoft, they have sales, customer service, marketing, et cetera. So is there a prerequisite?

- So to enable the Dataverse connection setup, you need a Dataverse licence. A licence that gives you access to Dataverse. So. And you also need a BC, minimum, essentials licence 'cause you need access to

- Yep.

- The menus in BC. You don't need to maintain those licences once in the connection setup, but to do the connection setup, you need those licences. So the Dataverse connection setup, that will do is for BC SaaS customers, you run through the wizard on that and it will actually go and it will take all of the pain out of getting that connection setup. It goes and it creates the app registration that you need for the two systems to talk to each other. It goes and it creates, instals the solutions in CRM with all the security rolls in. I mean, it always did that, but it still does that now. And then it goes and it assigns all of the requisite permissions to the CRM app user that it creates as well.

- Yep.

- So taking a lot of headache out of the connection setup. So you have to enable the database connection setup first.

- Yep.

- And that includes the core tables, like accounts, contacts, currencies.

- The products been another one or items as such.

- No. Products actually includes on sales setup.

- Oh, okay. So just the core fundamentals of, you know, your customer base and your contacts and things.

- Yep. And then you can go and enable the sales setup, which uses the Dataverse connection setup details.

- [Jason] Yep.

- So you can't change those. It's gotta go to the same CRM instance. So it just uses the connection setup details that you've provided in the Dataverse connection setup and then it gives you a couple more options as well. So there are a few things that you can enable. So one of the really exciting things that they've actually introduced in BC 21 is the ability to do unit group mappings. So I dunno if you remember, but time gone by, it used to create the units of measure in CRM from NAV and you'd have NAV pieces, NAV box.

- Yep.

- Yep, and then you could only have the base unit of measure from the item in Business Central.

- Yes.

- But now with the unit group mapping, what it does is it creates a unit group for every item it maps over, and then so you can have all of the units of measure that are available against the item in Business Central. So if you've got boxes and cases and pallets, you can have them all in CRM. So you can quote against them all in CRM.

- Makes quoting far more achievable, I guess is the best way of putting it.

- Yeah.

- Using kind of true BC data.

- Yeah, and then in that form as well, if there are prices against those different units of measuring BC, it brings them all over in the price lists.

- Okay, so... And then on sales on the CRM side, do we need a sales licence or could we have any type of licence to help enable that connection?

- So for the sales licence, for the sales connection setup, you do need sales licence to do it as well, because you are accessing sales entities like quotes and things like that, and price lists.

- So we've got a Dataverse and a Dynamic 365 connection, which we enable from BC to CRM kind of URLs in connections and we then create an integration, a connection between the two.

- Yep.

- So you've alluded to some of the things that we can sync out the box.

- Yep.

- Customers to accounts.

- Yep.

- Vendors to accounts.

- Yeah. That's fairly new, actually.

- But of course when I say accounts, in CRM, it's a relationship type.

- It is. Yep.

- Items to products.

- Yep.

- And for those that are watching, yes, Microsoft don't use the same terminology across their systems. Then we've got salespeople or salespersons.

- Yeah, so if you are using salespeople in Business Central, you can use those to determine who will own the accounts or contacts or whatever entity it is.

- And what if you don't use salespeople, salesperson codes inside of BC? And what happens to them, the ownership of accounts, customers, suppliers inside of CRM?

- So if you don't use salespeople, what it will actually do, you can set the integration to use team ownership, as opposed to using person ownership. And then what that will do is it creates- It creates the team anyway, but it will create a default owning team in CRM, whichever version you choose. But then basically, it will assign all of the accounts or contacts or whatever, you know, table it is that you're syncing to that default owning team.

- Okay. What if you didn't want a team ownership or you didn't use salesperson codes, but you have a CRM solution that those, you still need somebody to own that account record. So Jason works for the business. He looks after 50 companies. Has no relationship to Business Central in my company whatsoever. I still want those 50 accounts synced between BC and CRM, but I need the team to link the records together. But then Jason actually needs to be able to be, I want to be able to see my accounts inside a CRM. So how does that work in terms of ownership of record?

- So the advice on that one would be just to set you up as a salesperson, to be honest and just assign the customers in Business Central because you don't have to be a BC user to be a salesperson.

- Okay. Yeah, that works.

- So just, you know, create the salespeople, assign the customers, and then the accounts belong to the people you want them to.

- Yeah, that makes sense. So salesperson. Talked about currencies. We've talked about products, items, customers, suppliers, vendors. What else can we sync out of the box? You mentioned price lists that you can sync as well.

- Yeah. So you can do customer price groups. So if you've got individual prices for your customers, you can synchronise those over and then, again, it'll bring all of those price list items over, now with the different units of measure available on it. It will also as well, create a default Business Central price list. So it will use the list price on the item in Business Central to create this default Business Central price listing in CRM. So you've got the list prices available, you know, as a default, out of the box.

- Yep. Is it fair to say that it doesn't replicate the whole pricing function from BC to CRM?

- Oh. No, no. The issue with trying to replicate the pricing function, isn't it having the data to do it, it's having the functionality to do it. So obviously, BC can do some quite complex calculations against prices. CRM doesn't do that. CRM, you put a price in and that's the price it is.

- With that said, CRM has the capability to do discounts or certain additional logic on pricing if you want it to.

- Yep. So we can build that functionality in. I was gonna say, and there is a concept of, you know, on a quote product for example, you can put in a manual quote amount, a manual discount amount, sorry, and that will take that discount amount off.

- [Jason] Yep.

- But if you want to do things like, you know, put discount percentages on, that's not there out of the box.

- So is it fair to say that people that, where do I quote, is it BC, is it CRM? Both tools can quote. Those tools can create a document that can be sent out to a prospect or a customer. It's a case by case basis of who should quote where.

- Yeah. It's largely gonna depend on how complicated the quoted process is. If it's a very simple, you know, this is the item, this is the price, then we can make that a quite nice experience in CRM now.

- Or if it's bespoke pricing that there isn't really a said price list we've got.

- Yeah, if you're finger in.

- Lots of customers that say

- Yeah.

- I've got lots of bits that I need to add together. I need to add margin to it, et cetera, and then it needs to go at value, but I'm probably not gonna sell the same again in the same way. So it's a one-off price. So again, CRM is more than capable of dealing with that kind of stuff as well.

- Yeah.

- And giving ultimately the overall price that needs to be invoiced to the order and the invoicing to BC.

- Yeah.

- Okay. So that's prices. So we've got flexibility on what we can sync on on prices and we can also, dare I say on integration, I'm chipping into kind of the other side of the fence here. In CRM, if I wanted to create a price list for a customer and send it to BC, can I do that and is that an out the box experience or is that something that we need to work with the customer as a partner to deliver?

- So again, it's gonna be on a case by case basis. So it's not standard functionality. You could technically try and bidirectionally sync price lists. I wouldn't recommend trying to do it.

- [Jason] Yep.

- So what you can do instead is you can go and create the price list in CRM, you know, get it all approved by your customer and then use Flow to send it over to Business Central.

- Yep.

- So I would need to verify, but I believe price list items are not part of the standard API. So you would need an extra API to do it. From the BC side?

- From the BC side. Yep. So you just need to get the BC API extended, but then Flow would pick that extension up automatically once it was published and then you could just send the data into Business Central.

- Okay. So we've got some opportunity. The reason why is that we've got many customers for example, that they don't really quote a specific, and it's quite common in kind of food industry for example, or consumer goods is that what you are quote, what you're giving an agreement to is a price that's to the start and end date for those set products based on potential volumes that you might buy, but you have no idea when the customer will buy. So you just wanna agree a price list. And the idea is that whenever someone comes to place the order, they know what price they're gonna get. So your quoting process is arguably giving them a price list.

- Yeah.

- So we need the ability to create potentially as a sales process what a potential price list will be to then give it to BC. So it's possible but it's custom essentially.

- Yeah.

- Okay. So price list products, et cetera. So what else out of the box from Microsoft can we sync?

- So quotes and sales orders. So we've touched briefly on quotes.

- Yep.

- Obviously, you do have in CRM the ability to convert the quote into an order and submit that to Business Central and it will go into Business Central as an order. They've actually changed the functionality on the sales order synchronisation now. So you can still opt for legacy sales order integration, which essentially monitored an API. And then when it found an order, it pushed it into Business Central. But now they've actually enabled something called bidirectional sales order sync. So basically that takes it outta the API and it puts it into the integration table mappings, which is obviously what defines what data we're gonna sync.

- Yeah, yeah.

- So now instead of the sales order going into Business Central and essentially being orphaned in CRM, apart from the odd status update when, you know, it got invoiced or whatever, what actually happens now if the order is changed in Business Central, it'll get changed in CRM.

- Okay.

- Yep. So I mean, we've had, you know, with customers previously where people have deleted lines on an order in Business Central or added things on and then they've been, like, well the orders don't match. And it's like, yeah.

- They've compared against what the person sold to actually what you've actually processed and shipped to them.

- Yeah. So now with bidirectional orders sync, you can get that information. So it will update the order back in CRM. I would say likewise, if you update the order in CRM but you wouldn't be able to deactivate it.

- Does that sales order record still sit there after that sales order's been processed? 'Cause of course, BC has its own little way of working where it archives that order, because then comes into an invoice, et cetera, and you don't look at the order anymore, you look at the invoice record. So what happens in CRM against, now this sales order?

- So yeah, it sits there. You do also get an invoices synced. So the invoice will be linked to the order when it comes back into CRM. So if you do wanna use bidirectional sync, I'd probably recommend setting up a bulk delete job on those orders

- Yeah, okay.

- after the invoices come through. No, no.

- So that's an interesting one. Invoices. It's a contentious discussion at times within our team.

- Yeah.

- Because Microsoft allow you to do it and sync it and clearly, you are only gonna do it from BC to CRM whilst CRM has this invoice function. I wish that to an extent, unless you had a BC system there or a Dynamic system, they would get rid of it because you would never use CRM

- No.

- to do invoicing. But we have a debate going, should we sync invoices into CRM or not? And I think it's based on what you're going to use the data for.

- Yes. Absolutely. So if you need to, if you've got account managers, you know, that need to know the details of what those invoices are, they need to know, you know, how many products people have bought and things like that, and they need to actually be able to drill down into that information, then you need the invoices. If they just want to know, right, my customer has bought 20 of, you know, X, Y, Z in the last however many years, use Power BI Report.

- That was where I was going to here, going, if you want to look at their sales history, surely syncing invoices across, there's better ways to do it than syncing invoice data into CRM.

- Yeah. Using Power BI. Another thing as well that will training integration briefly is that virtual tables, maybe do it that way, but the only thing I see invoice's value for is a customer that we're talking to at the moment is they're using the marketing app and they want to be able to create marketing journeys and emails based on what people have bought and what people actually haven't bought, or if they haven't had an invoice issued to them within X period of time.

- Yeah. So in that scenario, you're gonna need the core data there to do that.

- And then you can say, hey, you haven't bought from us in three months. Please come back, please. We miss you. So again, you've got the data in there to facilitate that as well as the line level detail if you want to work through that perspective. So again, along with that, Microsoft give you the opportunity to do it, but there's gotta be a right business case to use it for as well. So is there anything else that Microsoft do out of the box?

- So you've just touched on it actually. So the other thing that they've introduced in the SAS platform now and it is only SAS, unfortunately at the moment, but is virtual entities. So in CRM, we've had this concept of virtual entities for forever. It seems like it anyway. And basically, what that means is that we can connect to any API, create a connection to it, pull that data in CRM and it looks like we're processing that data in CRM even though it never actually touches the database. So what we can do now with Business Central is we can, you know, use that functionality, but when you enable the Dataverse connection now, it actually instals the virtual entities by default for you anyway.

- [Jason] Okay.

- So it automatically enables that connection. It creates that connection to Business Central. So all you need to go and do is basically go and tick a box on the table that you wanna see and it'll start pulling that data into Dataverse. And by pulling that data, I mean, it'll start showing that data, and look like it's pulling it into Dataverse. So the difficulty with the virtual entities is, you know, a good example for using a virtual entity would be something like creating an API fee service items and then pulling them through the API so you don't have to synchronise all that data because that's gonna end up being a lot of data.

- Yeah.

- But then you could create a lookup upon a case to that virtual table, you know, and have all of that information of that service item. So when you create that reference to that case, the virtual entity link will remain. But if you wanted to bring in your customers through a virtual entity, for example, unless you've got somewhere to anchor that record, when that data refreshes, you're gonna lose the connections that you've got. So you've gotta anchor the virtual entity somewhere by using a lookup, for example, of a case. Or you'd have to create, like, an data link to an account in CRM to pull in the customer details to link them together. So it's good, but it's not straightforward.

- And I guess is the best way of putting it. It's like being able to have a peek into a different system, but you're actually not using that system day by day.

- Yeah.

- So I always use the example that in principle, it's like an iframe. You go onto a screen, you are using a system, but then you've got a little window on that screen, a box. And the idea is it's like you've embedded like a webpage or something into it that is potentially filtered down, linked to that record that you're on, company A, and it then gives you their related invoices, related posted sales invoices for that customer. And it just gives you an insight to that. So I'll be able to click onto it and go through kind of high level what that data is there. But that data doesn't exist in my CRM system. It doesn't allow me to kind of really embed anything I can truly use it. It's just a... I said truly use. It's a sneak peek in terms of, opposed to me clicking onto another tab in another window trying to open another application, it's giving me a bit of a view directly from what I'm already in.

- Yeah.

- Is that a fair way of trying to describe what a virtual table really does?

- Yeah, essentially. Yeah.

- So I think Microsoft have enabled that and I think with the right scenario, if you don't want to embed that data, invoices is another good one, for example. So if you don't need all your invoice data but you want that invoice view, then maybe it's an opportunity to use a virtual table. If you didn't want to go down the Power BI route, well, Power BI is a really good way to put it in place.

- I think Power BI would probably be better in that instance because firstly, you can do the calculations on the sales figures.

- Yeah.

- And you can filter the report down and, you know, embed it in the CRM and it looks all nice on the account form and you've got it all there in one view. And then the other thing is it comes back to that thing I was saying about anchoring it. You'd have to link that account to that customer to be able to pull that customer's information against that account.

- [Jason] Yeah, okay.

- So creating that anchor point, you know, would limit that there.

- Yeah, okay. I understand. So standard integration then, we can create the connection. Data first, sales, et cetera. There is, before anybody asks or inquires or has a Google around it or a Bing, there is no customer service connection. Microsoft talked about wanting to do more around customer service and better integration between the two. In BC, you get a fact box and you get a part of the fact box that says opportunities, however many and then cases, and it's just a hyperlink to take you to that part of the record is the best way you get from the CR in the BC side. But aside from that, the standard integration is one BC company to CRM.

- So no, not anymore. So now what it does, and this actually came with the team ownership is it now actually creates a business unit in CRM by default.

- So those that don't understand business units of CRM.

- Okay, so...

- 20-second summary of what business units do.

- Business units in CRM are a bit like slicing up a pie and making sure that people can only see their own little slice of pie.

- Yep.

- Okay, and then, obviously you've still got the whole pie as a whole and certain people that are in the root business unit can see all the pie.

- So if you're a group company and you had one CRM system, business units would be a way of segregating those...

- Divisions.

- Divisions businesses.

- Yeah. Entities, whatever you need to do. So that just puts security restrictions on who can see what in CRM.

- Yep.

- So what the Business Central integration now does is it will create for each company that you integrate into a CRM instance, it will create a business unit for that company.

- Okay. So the data automatically comes in segregated.

- Can you unsegregate it?

- So there are a couple of ways of segregating it. If you want everybody to be able to see everything from all companies, you'd basically just give them organisation level permissions.

- Okay.

- Yeah. That's the easiest way to unsegregated the data.

- [Jason] Yep.

- You can start messing around using Flows to move records around and things like that. But if you-

- It's hard work.

- It does feel like hard work. Yeah. Or you can use access teams to try and, you know, navigate around the business units. But to be honest, the simplest way is if you've got people that only need to access certain companies, just leave them in those certain companies.

- Yeah, okay.

- And if you've got people that need to see everything, move them into the root business unit.

- Yeah. Okay. So multiple companies to one CRM, possible.

- [Kelly] Yep.

- What if those multiple companies in BC, So with Brexit.

- Yep.

- And people setting up different countries, in different European countries, et cetera or you've got a group division that's got one company that's US, one company that's Euro, one company that's GDP, can that work?

- [Kelly] No.

- Okay, so I can integrate to BC to CRM, multiple companies as well.

- Yep.

- As long as my companies in BC and my base currency of my companies in BC and my base currency of my CRM match.

- Yes.

- Okay so. That leads us onto, if we can't use the standard integration, what can we use? Flow, Power Automate APIs? What does that give us to do?

- So you've got a couple of options. You can use Flow to do it or you can use third party, you know, data migration tool.

- [Jason] Yep.

- So with Flow, most of the standard table mappings you would get with the standard integration are available as APIs. So you can just integrate most things, you know, using Flow natively. With the BC SaaS connector, you can now filter by modified on, you've got triggers. So we didn't use to have triggers for connecting to Business Central from Flow. So now you can actually trigger when an account is, oh sorry, when a customer, use the right system terminology, when a customer is created in Business Central, create it in Dataverse or when it's modified in Business Central, go and modify it in Dataverse. Whereas before, it used to just be a go and get a list of customers, throw the data at CRM.

- [Jason] Yeah, yeah, yeah. But also as well, it's now a lot easier with the advent of the SaaS-BC connector and the abilities that it now has to actually extend the APIs in Business Central for the things that it doesn't have a standard that you would get with a standard integration and add those into Flow.

- Okay.

- So Flow is a very good way of actually integrating the two now.

- So Flow can can not just pass data in terms of, like, sync customers, sync contacts, sync items, we can also use it to process orders, create a new item from CRM to BC.

- If you really want to.

- To be fair, we have got that example where it's a bespoke item for one customer where, you know, where we're saying something quite bespoke of the projects. We've got the parent item with a set of components. There as a bomb and they're unique each time. So let's not flood BC with a load of data that will never transact.

- Yep.

- Create it there when it's ready to be in order. Send it to send it to BC, and we're doing that via Flow and APIs and stuff like that. So from our perspective. So Flow, Power Automate APIs with BC and SaaS and et cetera, even on premise BC, we can still have APIs and we can still use Flow. Can we?

- Yeah. So the limitation of using the APIs on a BC on-prem system is that we'd go and create a custom connector to do it. So it just takes a little bit more setup.

- It's still possible, but just a live extra time.

- Yeah. Just a little bit of extra time to configure it.

- So the Flows are another option and kind of, it can do can do pretty much what out of the box Microsoft does and possibly a little more.

- Definitely a little more.

- So things like an example of wanting to sync more data. So if a customer sells a product that's got a warranty and use a service item in BC, service items get created, you might have a warranty period of two, three, four, 10 years on that item. Obviously, cases in CRM, I need to create a warranty case of what's going on, et cetera. So from that perspective, we are looking at wanting on CRM when I create a case or a problem, to tag my issue against that serial number, that device, whatever it is I've sold to kind and look at doing a follow up, a warranty claim or whatever. So how do I get that data from BC to CRM?

- So if you are using BC SaaS.

- Yep.

- I'd say use a virtual entity, because you don't really want all of that data in CRM unless you need to do anything against that data in CRM.

- From a reporting or a point of view.

- Yeah.

- Okay.

- Then you don't really want all that extra data in CRM, because data takes up storage. Storage costs money.

- Yep.

- So use the virtual entity to do it. If you are Business Central on premise, then you're gonna have to integrate the data. It's that simple.

- Virtual tables can't be used with BC on premise.

- No, not at this time anyway. So you've got two options, really. You can use Flow to do it.

- [Jason] Yep.

- Or you can extend the standard integrations to it.

- And we've extended the standard integration through an app that we've got on the BC side that we can add more data from fields. Microsoft don't sync every field from even standard tables that they have,

- No.

- which is annoying. I wish Microsoft would... Microsoft, are you listening? Please.

- Account number.

- Yeah. Account number would be great. But also on top of that, give some flexibility on what fields you do and don't want to sync onto a table. Not, here's the ones that we've got. If you want anything more, either do it via API and Flow or create an app that allows you to sync more. But either way, I think from our point of view, when it comes to integrating and extending and syncing your service, we've got customers that do sync the service item data, because they want to use it to tag it against and do lots of reporting on cases of warranties and product types and that kind of stuff from a case resolution point of view. So there's a value to them doing that. But I think we've talked about standard integration, virtual tables, Flow. We've touched on other tools. So eOne SmartConnect is something that we're starting to utilise more and that's a hosted kind of middleware tool that can sync data from one system to another and you've got a tool in the middle that can help say that field equals that field and sync it on this basis. And I think that tool is good at kind of error management and reporting and capturing stuff like that, whereas Flow, you've gotta build all that stuff in there, 'cause it doesn't exist apart from looking at Flow log when it fails or create an email notification as part of the flow creation to say send an email when it fails.

- Yeah. So that's a downside of flow to a little bit, there. But in terms of overall of integration and summarising, it feels like we've now got a world of capability with the Microsoft platform itself without having to go out third party, without kind of kind complicating it. Or even, dare I say, we can now sell the dream that Microsoft do have a truly integrated set of business applications, even though they don't offer everything out of the box and it's a point, click, tick and it's done. But working with a partner and the customer together, we can create something that is truly integrated. Yes?

- So I would say that with the standard that we get from Microsoft, you can probably get about 85% of the way there and then with the abilities that we have to extend what we need, using the tools available to us, be that Flow or virtual entities, you know, or extending the standard integration,

- Yep.

- which again, would be a case by case decision.

- [Jason] Yeah.

- We're probably about 95% of the way there. There's always things that can improve.

- Of course.

- But it's looking good.

- So I think from our point of view, when you came into Tecman, integration-

- Was a dirty word.

- Yeah, between NAV and CRM, it was, oh really? Do I?

- Yeah. It was, if people could avoid it, people would avoid it. What would you say the culture and the attitude towards integration is now? Not just in our team and CRM Power platform, but as technology as a whole business with the BC team and with all other departments and stuff like that, how do you feel people view integration these days as part of the wider business?

- So it's looking positive. People come and they ask questions and if they're not really sure on something, you know, we've been doing quite a few projects in the CRM team now and, you know, working quite closely with the BC team 'cause they've got parts of their solution that depend on ours and we've got parts of ours that depend on theirs, and through those projects and that collaboration, you know, the BC team have learned quite a lot about how the data integrates to CRM. And we've learned quite a lot about the restrictions of getting data into BC, you know. We're doing really, really well as an organisation of now getting that knowledge out there on how this tool can work and how we can make it work better.

- We are very collaborative. I'm not saying we weren't before, but I think there was a nervousness, previous years gone by. I think it's fair to say we're a partner now, that very much embrace what Microsoft offer to us and our defaults would you say is we look at what Microsoft give us in terms of standard, Flow, those capabilities before we go looking at... For the right reason, we will use eOne.

- [Kelly] Yep.

- Especially when there's more integrations of more tools out there that the customer's wanting to use and integrate all together. But when it's BC and CRM, very much, I think our approach, would you agree is we use what Microsoft give us.

- Yeah, I can't think of a scenario, this precise moment in time, putting me on the spot, where I would use anything other than either Flow or the standard integration or virtual entities.

- Yeah.

- Between BC and CRM. Like you say, you know, if you want to start linking other systems in, you may not have that capability in Flow or whatever and you may need to go to a third party tool. But specifically for BC to CRM,

- Yep.

- I'd stick with what we've got.

- Cool. Thank you very much.

- You're welcome.

- So that is the end of the discussion around BC-CRM integration and where we're now at. So thank you for listening to the latest session on "Tecman Talks Dynamics" and you'll see us again soon.