Overcoming Integration Challenges for a Best-in-Class EAM Solution

And, welcome, everyone, to the latest in the Brightly Insights webinar series. Thank you very much for joining us. For those of you who joined us from our previous webinars, we hope you're enjoying and learning from these. I'm joined with a a couple of colleagues, but first I'll introduce Brian Burgess, and so for those of you that don't let me, I'm now the customer success manager at brightly. And my job is to make sure that our customers are satisfied, in fact, delighted with our software and services. And I've been involved in implementation of enterprise asset management solutions for close to thirty years. So, and I'm joined by, my colleagues, Jim apostrophe, and Jim has a really long track record in work government. Jim is our senior sales executive for the Asia Pacific region, for local government. So, he's, been with the company for a few years, but has a really in-depth knowledge of how the government works and what my requirements are in this space, the integration space. And, last but not least, I'm joined by Kevin Wilson, who will be doing the bulk of the heavy lifting on this one. For those of you who don't know Kevin. Kevin is our head of our integration team here at Bradley. And in any EAM implementation, we've done last decade or more. Kevin has been part of that to, make sure that, you know, our solutions talk other solutions within your environment, in an effective and efficient manner. So without further ado, oh, the other thing is I should direct you to, some of the icons at the bottom of your screen. So, we'll be taking questions. So feel free to use the question, ask questions in the buttons below. Also you've got the, speaker bios, are in there. You can use also those buttons contact us or request a demo, but we do have a lot of time, we have a lot of time at the end for Q and A. And they can, you know, ask us that you can send us we'll see those and we'll, deal with those, towards the end. And if we don't get through all of your questions, then we'll follow-up after the webinar. But without further ado, I'll hand over to Kevin. Good everybody that's on online. This piece is around the integration evolution. Since the, the nineteen eighties, the landscape of the application integration has gone through significant change and evolution. We've moved from the traditional file based communication or better known as the integration within mainframes to more modern methods such as the file and data transfer point to point integration, share database, enterprise application integration, and Microsoft Microsoft, and APIs. In the ever evolving digital landscape application programming interfaces or better known as APIs has have become a crucial component in various domains, including enterprise asset management, enabling seamless communications between software components and services across council. My presentation provides insight into how application integrations have evolved over the past four decades. The software and tools mentioned in the, in the overview diagram may not cover in the entire array of integration options available. As they serve as an example and reflect my initial experience in the public sector field. The widespread adoption of APIs is largely attributed to the majority of the API management platforms and the establishment of API standards. These platforms offer end to end capabilities throughout the API life cycle, encompassing API development, developable experience, security, API management gateways, APO orchestrations, and the department to ensure various quality of services requirements are met. But combining the API management and ESB capabilities within the API management platform. Level government councils across ANZ can unlock the full potential of their microservices architecture. This approach not only empowers councils to create scalable, agile, and interoperable software solutions, but also ensure that these solutions integrate seamlessly with existing point solutions and ERP systems and technologies. Fossering innovation and adaptability in a rapid evolving digital landscape within the public sector. Be risk and avoid ERP vendors that lock you in or provide you with the convoluted reasons why not to integrate. Offer your organization the choice, the and the flexibility to implement or decommission solutions as council seats fit and avoid the complexity of being locked into one ERP vendor. Brightly delivers the full integration journey with relevant products and services that Council seek such as CRM, finance, EDMRS, GIS integrations. We offer the full spectrum. We take complete accountability providing you with one simple experience, period. There are counters out there that have internal resources who prefer to deliver their own integration piece. Brightly openly supports this initiative and we provide you with the complete rest API catalog. We understand what it takes to transform businesses, make life simple and deliver tangible benefits lasting improvements. Kevin will now walk you through how we've been involving and integrating the integration landscape and delivering excellence in the seamless integration with over two hundred customers across the public sector space. Hello? So I guess the first thing is, when you're integrating your, your enterprise asset management system, You're looking for the best asset management system to use. So we're talking about the right tool for the right job. So I guess that's one of the first things is the reason that maybe integration comes up is because you've chosen, as you mentioned, you haven't chosen an ERP. You've chosen, in this instance, an enterprise asset management system. And that needs to fit in with your organization systems and with the workflows, with the with the advent of cloud based, software as a service solutions, the the IT burden that maybe once existed over the IT department having to manage a large number of independent applications has been taken care of in the deployment and administration of them is far simpler. In fact, you don't need to deploy. It's just a cloud delivered, service. As Jim mentioned, application interfaces, our application programming interfaces allow these various applications to talk to one another, to be incorporated into common workflows. So what do we get? Simplified workflows. So integration allows for simplification of workflows by just allowing the movement of information or transactions between different systems. It means that users are not having to open multiple applications or entering the same search criteria in multiple applications, instead they should be able to just navigate between different applications each application performing the the function, which it was designed for. Using the right tool for the right job. So basically what we're looking at here is using an enterprise asset management system that is purpose built for enterprise asset management system using a customer service system's purpose built for that, and so on and so forth. By using the right tool for the right job, it means that the people who are engaged in those activities are getting the best outcome for their particular role. What integration allows is at an organizational level is for all of those different activities to all consolidate So, an example of this might be customer service integration with maintenance activities. So if we implement a customer request integration with a maintenance, we allow the people who are taking care of, customer service to work within the customer service application. Likewise, the maintenance teams are working purely within the maintenance management system. There's no need for a customer service person to be trying to open and navigate another application that maybe they're not as familiar with, not having to re enter search criteria to find a request, instead all of that information is flown between the two applications. Another example is GAS integration, where you've got sophisticated mapping software such as arc GAS or mapinfo used by your GA's professionals, but your end users are accessing a published version of that data in a web browser that's also merged in the asset information. Next, we have data confidence. So integration allows for a greater level of confidence where you can have a single source of truth of the data and any risks associated with manual entry of manual rig entry, double entry, etcetera, of data is removed. Reporting to align to requirements. So coming back to the concept of using the right tool for the right job, that includes any reporting or dashboards or whatever within those applications are set up and maintained for the purpose of the activities which that application is just designed. Integration allows you to then draw all of that data out various applications for presenting in different manners in different applications and at different organizational levels. So, your your management team may see a different view of the data compared to your works team compared to your finance team. And those things are achievable when we've got integrations that allow in each team to use their preferred tools, get the reports and data that they're needing their preferred way, but still allow the organization as a whole to get those maybe those higher end metrics. So when to integrate as an integrator, I might be tempted to integrate everything because it's, quite enjoyable for me. But I think one of the first things you need to do is is actually understand what is your use case for integrating? And I've listed here what I feel are the strong use cases for an integration. First a high frequency of transactions. So when you've got a lot of a lot of, transactions such as customer service requests coming in, many, many tens of requests perhaps per hour. You're needing to create corresponding service requests and and trigger maintenance activities That's a good that's a good use case. Because to try and separately manage those within a customer service crest system and a and a maintenance system, I think you'd end up with a lot of errors and also waste a lot of time. Next is where where it's a, where the integration is an integral part or where where you've got multiple applications that are all integral to a workflow. So the the workflow can't be achieved in a single application alone. It's probably timely, and I guess customer service request is another example, or the same example reiterated. So a customer service request you want that to flow through the maintenance system quickly. You want the the, transactions, the activities that are taking place to to go back to the customer service request so that everyone's able to keep working, and with, we know sort of delay to the workflow. Another good strong case is where there's the potential for data loss or corruption. So in some instances, you need to automate the movement of the data from one application to another, to perhaps satisfy auditing requirements, perhaps to, avoid any data entry issues or potential issues, and to ensure basically that you're confident that when you're in any given application, you're looking at the current data and the most you have the most reliable source of data, regardless of which system you're in. So once again, historically prior to integrations, when people, you know, were using multiple systems, you might find that they, hang on a minute. I'll just check the other system to see what it says. So, yeah, not my ideal state. Another strong case is a well understood workflow. So when you understand the workflow and you understand what it is that you're trying to achieve from your integration. It's a lot, it's a lot easier dear to build an integration, and it's also a lot more likely that you're going to get the outcome that you need. Sometimes you might be inclined to feel that you need to integrate, but when you actually analyze it, you might discover that you're requirements very, you know, very, very quite considerably to what your initial understanding was. And then finally, a well understood integration. So if it's an integration that has been performed multiple times, you're more confident in that integration. You know that there's, less things to, worry about, less unknowns. So the integration process, is generally also going to be well supported by the various applications in their APIs because a well understood integration implies that it's a it's a it's a common integration and it's a common activity. Oh, I see there's some, some questions. We'll address the questions at the end. If that's okay? So what would a weak case be? A weak case might be that, it's just an annual event that you do once. It might just be a simple ETL process that doesn't necessarily require, any automation and so examples of that might just be an annual an annual extract, for provision into another application. And ETL tools, ETL being extract, translate, and load. So there there are a lot of ETL tools out there that can can give you the confidence of moving data from one application to another, in a well understood manner. But perhaps with, less effort, in terms of preparing an integration. High cost of development compared to the value of the outcome. So once again, you just need to look at what your requirements are, are they well understood? And how do they compare to does the does the cost and the effort involved in in preparing the integration, does that actually match the outcome? And you might, you might actually establish that there are other ways of going about it, such as the ETL process I mentioned a minute ago. And another weak case, probably the most weakest case is when the requirements are actually, unclear, or where there's a lack of consensus within the organization as to what the integration is trying to achieve. So it can it can become quite a costly exercise if you're actually unclear what your objectives are in the first place. So always pays to to have a very clear understanding, and we'll touch on this later. So What could be some common integration barriers? So lack of vendor support. So since since an integration is two or more applications that are interfacing with each other, if one of the vendors of one of those applications, is either unwilling or unable to to make APIs available or to assist with, making documentation, access available, that that can present, what appears to be a barrier. The reality is is that over over the course of many years, we've been able to integrate in spite of those barriers. But in an ideal world, you wouldn't have those barriers. But, yes, definitely, vendor support certainly makes an integration easier. Like of internal support. So that's that's where within the business, you're, there's not support for the integration, and there could be various internal conflicts or reasons for that. But the main the main thing to understand is that if the business isn't on the same page. If all of your stakeholders aren't on the same page, then that can make things really difficult. And it makes it harder at a if if there's lack of cohesion at a high level, then as you delve further and further into the workflows and the processes integration is going to be supporting, that that lack of cohesion becomes ever more apparent. So that's a barrier that would need addressing. Which kind of movement leads me into the next, next example, which is an unclear case for integration, and this kind of takes us back to those weak reasons for an integration. So you need to be quite clear as to what you're trying to achieve with your integration. You need to be quite clear about how it will help your workflow, and you need to be clear as to what the scope of that integration is. So how extensive does this integration need to be? Could it be done in stages? How well do you understand your workflows that you're trying to automate that's particularly relevant perhaps when you're implementing a new system. So when you're when you're implementing new enterprise asset management system, for example, it's offering you a new way to go about managing your assets. It's offering you a new way to look at your workflows, to look at how can you be doing things better? How can you be getting better outcomes? And that means potentially changing old workflows. And that means that an integration needs to be based on on your future state, not your past practice. So being clear about what your integration's trying to achieve, being clear about the the scope of it. Being clear about your workflow really helps with that. Costly APIs. So in some instances, it may be that actually the the APIs, from one of the vendors might be, quite expensive. That might perhaps be prohibitive. There are often other approaches that can be taken. So it's it's not, an insurmountable barrier, but it is something to be, cognizant of. And finally, technical barriers. So technical barriers could take any kind of, form, really, they could be issues with firewalls or access. They could be problems with on premise applications, not having access to cloud applications. They could be, the one of the applications simply doesn't have APIs or doesn't have APIs support the required workflow. With technical barriers, it's important to as you're going through the integration process, just to keep an open mind, that there there may be some hiccups, there may be some some times where where you encounter some kind of technical limitation. If you recall Jim's first slide, Kim listed over forty years, quite a number of different interface mechanisms, quite a number of different applications, And that's the, that's the environment in which we work. So it's not uncommon to, to have, the occasional, technical obstacle that you need to look at and resolve. So All of these things are not insurmountable. They're just things to be aware of. And when you encounter them, is to, I guess, work work in a collaborative manner to resolve. Which takes us on to some strategies. So the role of counsels. So engaging with your ERP vendor. So we've had some really positive experiences with ERP vendors. Implementing our enterprise asset management solutions. And in those scenarios, we've been able to come up with some really good outcomes. But often that involves, council actively engaging with their vendor, with with some open clear dialogue around what they're trying to achieve. And what the integration represents to them. And if able to if you're able to engage with your vendor and have those discussions, it it can give you, a really good outcome. So becoming integration champions, and empowering your team empowering your team, I guess it's what that what that basically means is you're giving your team, so each of your different, groups within the organization, the best software to use. You'll give it your implementing software that is class leading, and you're using integration as your as your way to ensure that at an organizational level, you're getting all of the outcomes that you need in terms of, workflows across applications in terms of reporting and metrics and understanding, your business at at a higher level. And also The other option the other opportunity is there are there are integration opportunities for your for your actual teams. So you can your your your teams can actually utilize tools such as our APIs to to build their own custom reports, to to write their own automations. And that kind of leads us into the next dot point, which is leveraging technical resources. So as Jim mentioned earlier, we can provide, an integration However, also your IT team, or another vendor can provide the integration. Or it might be a collaboration between ourselves and your IT or your IT in the other vendor. The the provision of APIs allows this, where where you choose or your IT team choose to provide the integration, it opens up an opportunity for you to use advanced integration tools, that with, messaging services that will basically allow a message to go from one application to any other application that's subscribing to that message, and that's what allows the various, applications to all talk to each other and also allows you to swap in and swap out different applications. So as you mentioned earlier, you're not locked in to any particular application when you've got an integration in place. The integration actually gives you flexibility. And then finally, effective communication. And I I've tried to stress a few times. For me, the most critical thing for the success of an integration is where expectations are aligned. It's where the workflow is understood. It's where the vendors and the, council or organization have a clear understanding as to what they're trying to achieve and that the integration is is is outcome based. So the integration is providing the the outcomes that the organization needs and communication is is is the most critical part of that because, at a technical level, your your IT people, my integration team, that we're the experts in resolving the technical aspects of an integration. It's the it's been on the same page with the workflows and requirements that's that's the critical thing. So thanks for that. Darren's got some successful integration examples. I can see there's a couple of questions. So, we can address those after that. Thank you. Thanks, Kevin. And, yeah, keep those questions coming everyone because, we've got a couple of interesting ones in there and and we'll, it'd be good to, to have a few more coming through. And thanks for, Jim Ann and came from that, there's a, a lot of lessons learned over the years in terms of these implementations that we've done. And I thought it'd be useful to kind of share some of those, at some some success stories. One of the early pieces, so when, we were implementing the cloud solution for Sarel in Tasmania. There was a requirement to integrate to Microsoft Dynamics. So, with the APIs we've got available, in our system, we were able to do a point to point for that one, a point to point integration, so a little bit of old school, but still that running still does the job, and and is a frequently a reference point for people that really want to kind of, have that maintenance management work tied into your, finance system. So one of the things that's, interesting about a CMS or maintenance management system, as part of your asset management system is that there's always a, a requirement, to, to establish integrate, maintenance against an asset. You don't expect your finance system to have a full blown maintenance led asset register. You know, your finance system should just be dealing with its accounts and and and ledgers and things like that. And so talking to that system and and kind of requesting purchase orders, to engage contractors and things like that, is a good way of kind of making the maintenance management system do its job very well, which is tying maintenance to assets and looking at the cost of management at an asset level, and then giving the finance system to just do its things which just purchase all those invoices, all of the things that the finance system is really good So that integration is a well trodden path. It's it's, not as well trodden as the CRM integration. In fact, I haven't mentioned any CRM integrations as such in here, is that they are so ubiquitous and the other ones that are ubiquitous are certainly GIS integrations, which are all pretty well understood. And then we took a next level up, really, when we look at the city of Adelaide, and they use as your logic apps, and, however, the service bus. And one of the things that we've seen there is, you know, they took like a doctor also with our APIs that are well published and well understood. And basically, we're able to switch systems in that corporate environment really easily. So if they're replacing, you know, the GIS or editor GIS Center, let's just say you're just gonna change your GIS Center. So you're going to switch from, you know, right input to qgis or vice versa, whatever it is. It's very easy for them to do that using that environment. Is a very mature way of of dealing with multiple systems. And what we're seeing is IT departments, you know, have made that switch now. It was it's been a long time coming. So rather than, you know, in a SaaS environment with SaaS world that we live in, they don't have to maintain servers and upgrades off and things like that. What they now become is integration brokers and they make sure that the corporate systems talk to each other and actually support that infrastructure for doing it. And Adelaide are a really good example of that. And then a smaller example, but but, you know, was are our friends at ways of Metropolitan Center Trust in Victoria. So they, they have an integration, platform, that they use to, integrate their Oracle system to, to, lots of other systems around, well, so one of the things in that one is actually an integrated asset register. It's interesting, you know, frequently, the asset management system wants to be the dominant asset register, but there are jury asset registers and asset data coming in from different places. So you do need to kind of synchronize the registers from time to time, and GMCT is is a good example of an integration platform that let them kind of integrate to those systems. And then a real win for the DOE department of education in Tasmania It's just something simple. But but it was something that that this this software had some limitations so that we, you know, there are alerts and notifications in the system, but they don't necessarily trigger when you want, you know, when they, that this organization wanted them to go to the people that they wanted to go to. So we built, well, you know, with them, a solution using our APIs to issue emails, and because it because it's an old, older fashioned environment, as well as some of the users aren't gonna be using the software. They they use email. To manage their work. So letting the school know contractor know that, you know, the work is coming up and and just sending the notifications out was really important. So it's actually kind of trying to keep an existing workflow that was working. And so that those tools were used to to deliver that with the DOE. In Taos. And then, our friends at Wanna Roo, and I think there are a couple of Wanna Roo people on on Boto, hi there, from the a team out west. They've been doing some remarkable work. One of the few integrations I've seen in the HR system where we're keeping the resource library up to date, and, and resource costing. And then they had something called three way matching. You just basically purchased all those and, invoices and, I can't remember what the third entity was. Keeping those entities, purchase orders, purchase order receipts, and purchase orders all in sync. And so, we combined two integrations that we already have, which is basic something similar to SarelPA, I'm often getting the purchase order, but then also bringing in actuals from outside of the system. So the finance system which is, again, I think it was Oracle at that. It was bringing in those actuals and then pushing those actors against the work sort of in the system. So the system is a central source of truth for the work staff as I So Wanna Ro is is set me a shiny beacon in terms of of the work that's going on there and allowing the team to do some some outstanding stuff. So that those are a couple of examples. But, I might go through some of the questions that we've here. And I think, there's a couple. So I'll just go from the bottom up, Kevin, unless there's anything in there at you. I think one of the things that from Jeff here is, explaining, what you meant when you said intubated, an intubating system can improve confidence compared with the ERP. And I'm not sure that that is what your statement was, but do you wanna kind of clarify that? Yeah. Sure. Yeah, I probably didn't make myself here with that because, yeah, that's not what I was trying to say was that by by having the integrations, that tell you have data confidence as opposed to, integrate where where's where you've got environment where you don't have integrations. So, yeah, I wasn't really trying to compare with an ERP. It was more if you've got you've got two, disparate systems and you're relying on, some kind of data transfer process that it's not automated, then the then you are then you have issues with data So, yeah, it was more around, I guess, by by having by having these integrations, that's one of the ways that you ensure data data confidence. And then, Anesuya has come in, and I like this one a lot. And I might, I might, take some of this and, and maybe hand some of this to you as well. Is how do you understand the integration if it's the first time it's happening? I think a lot of that comes back to understanding requirement. It's so frequently. I'll use this example a lot of time. We, we used to see, in tenders, you know, it needs to link to the HR system. I'm like, great. Why? What exactly is the information that you need to flow between this system and the HR system? And it couldn't it wasn't well articulated. It. And I think the key thing is, trying to take the software analytics. So if you, if you look at the, Adelaide example in a way, it doesn't matter which thing you've got doing, which process. It's like, well, what is the process flow? You know, I need to get this data, to, to be in these locations, but what but why and and how often. And so it's it if you haven't done it for the first time, there are lots of integrations that we did for the for the first time, it all came down to, business requirements. And I think one of the things that we're seeing in successful implementation is increased use of BA. So business analysts become quite key early on in the piece because they cannot help help the business articulate that environment. So the business can go, I think I want this to happen, but the BA's can kind of do a little bit of digging. And then I, you know, BA's can then talk to techies, and techies can kind of make things happen. That's usually the workflow. I don't know whether you agree with that, Kevin. Yeah. Absolutely. It sort of comes back to what I was trying to convey, which is around communication, around understanding the workflow. So understanding why you're doing it. So maybe my first slide, or second slide, which was when should I integrate? So you've established that you've got a strong case for it, which means that you've obviously put some effort into understanding, but what is that workflow. Once you've got that understanding, it might get a bit technical. So, I'm investigating at the moment. For example, an automation with, which we've never done before. From technical level, it's quite exciting for me. But basically, we've established at a high level what the workflow is and what we're trying to achieve. I've now met with the vendor or this other application and with, We've also had a chat around it and, I'm now actually testing out the APIs and actually looking at the at a feasibility level. So there is actually several steps. First step, what is it we're trying to achieve? What are the workflows who are the stakeholders, second step, proof of concept or high level technical analysis to understand what that what, how that can be delivered. And that then is the start of a process where we're then going back re engaging with the customer to to discuss, you know, what we've learned, what we what we, feel is the best way to move forward. And ultimately having a really clear scope, with with a supporting, technical definition of of how this integration is going to be achieved. So, yeah, there's there's often a first time for an integration. It's and I guess also just that ever changing landscape, as well. So, you know, Jim's Jim's first slide with all of those all of those different integration mechanisms that have, you know, become evident over time. Could mean that we with new new technologies, it might be that you're actually doing the same integration that was done ten years ago, but using new new technologies you've got better capabilities. You might be improving on those. So so I think, the CRM integration that we did five years ago, is different to the CRM integration that we did two years ago, which is different to the one that we'll do tomorrow because systems are always evolving. Our client base is always evolving. And it's one of, it's one of our roles is to stay is to stay abreast of all of those cha of all of that activity. So hopefully that answers Cool. Thanks. Thanks Kevin. Yeah. I think I got another one here, in terms of the RP environment. Sites from Jeff. It's like local government IT, would it be easy for them to manage security for a single ERP rather than a series of multiple integrated tools so it's a really, yeah, first of all, security is really important. I think one of the key things that when we're building any integration is to make sure it's up. It's one of the reasons why we use AWS and a lot of other, those well established tools to, to kind of, and make sure that those integrations are secure. I think there's a, there's a push pull here in, in between what's making IT's life easier and making the business's life easier to be brutally frank. It's kind of, yes. IT's job would be really easy if they had one system to maintain. But the business that necessarily doesn't find that that that's and can provide every minute. For example, an ERP doesn't sit in a bubble anyway, right? It doesn't integrate. It has to integrate to the GIS. It's gonna its job properly. It has to integrate to other systems, typically, even if it's just an ERP. So I, yeah, I, that's, don't know whether that, Jim. Yeah. I was also I was also wondering whether it relates to, to provision of of new logins and that kind of thing. So, so we're single sign on. And thermal authentication, those kind of mechanisms, then, we're able to we're able to allow access to our application, just through say, AD or like, yeah, Azure, Azure, sort of active directory. So if the question kind of relates to that, then yes. So, you can you can still provision if you've got multiple applications, many of those applications now are supporting single sign on. So so there are actually opportunities to to actually maintain your access to all of your applications just through your Active Directory. And then Moving on, just a clarification with the soil integration, you said let the finance system do what's good at EG based POs. So you didn't integrate maintenance to finance. No. No. We did. So, basically, when you raise a works order in our system to do work that requires a contractor, it then goes to the finance system and requests a PO. And so, only once that PO is authorized and stuff, you know, do that, that PO information comes back into the system for the Brooks order to then progress. So, yep, they are totally integrated. And it is about that workflow of kind of getting a purchase order raise, and then also kind of a, there's a whole close procedure as well in terms of getting that work. And I think they're fine. So, yeah, so I think that color flies four and five, in terms questions. A good question here from Ashley, though, do you see integration as live or, or through a regular date. And I do like that term live. Kevin, what do you what do you how do you interpret the word live in that question? Why I assume instantaneous. But, yeah, often often often it probably closer to, near near real time is probably, a more achievable time frame. So, and that's, and that's mainly just to do with the various applications that you're dealing with often don't have, any sort of mechanism to to publish changes to make them available to other, to other applications as part of workflow. So often your, what we use the word polling, you're polling for changes or the other application is is, doing sending out periodic notifications. You'll even notice, at a really technical level, if you look at a an application like, like a Zulu logic apps, even if you've got a trigger on a SharePoint file. So, a SharePoint sorry, a file gets uploaded to SharePoint, and you've got a a trigger that should notify your application straight away. There's always, there's always like a minute, up to say a minute delay or two minute delay, even with those theoretically instant triggers because, the applicant that Azure in this instance is is still actually only every now and then, like, two minutes, sending that notification. So I'm sorry. That was a long winded answer. Yes, we we tried We're we're so we're appropriate. It's something that's live. So customer service integration, you want that near real time, as opposed to, something that could be nightly, such as just a periodic refresh of, attribute information, to another application. It can take it can take up to a couple of weeks in terms of workflow process for a change to an asset to even get entered into the system. So if it takes that long for for it to go through all the various steps and things, then it doesn't matter that it takes that that that change doesn't go through until maybe that night. So I think it yeah. You kinda need to assess, depending on the workflow, the criticality of it as to how frequent it needs to be, because there's no point, constantly just filling the network with, messages about information that that very rarely changes or has a slow sort of, workflow anyway. So it comes there. So it's a quiet once again, right, in terms of, you know, what that frequency is driven by how immediate you need that And, yeah, I I figured with GIS, you know, special update to post it nightly, because that's more of a suspicion, in terms of of getting data through to the corporate JS. But CRM integration needs to be quite swift. So, you know, it is all about that business case and that use Thanks a lot, Kevin. So, that I don't see any more questions coming through. So I just want to take opportunity to thanks everyone for attending. If you've got any further questions, just, send them through, and we'll send them an email. A link to the recording will be sent out to all of you. And, keep an eye in your inboxes for any future webinars. We'll keep doing these, and, as long as, you want too. And, if you've got any suggestions for topics, reach out and let us know as well because it's always good to know what you want us to talk about.