Name: Integrating NetSuite and Data Warehouses
Uploaded: 2025-07-15T18:04:10.496Z
Duration: 45 min 27 s
Description: Integrating NetSuite and Data Warehouses

Transcript for "Integrating NetSuite and Data Warehouses": Hello, Everyone, thank you for joining us, in the ins and outs of integrating NetSuite and data warehouses, a very hot topic. And you'll see it'll spill over into several areas around databases, data lakes, AI. And, my name is Rico Andrade. I am general manager of commercial segments and also the head of partnerships here at Celigo. So good to see a lot of familiar faces joining in here. Today, we're gonna be joined by Tyler Lamparder. He's our product portfolio strategy on, our product team, and then also Nate Bryant, who's our senior solution consultant. They are both, deep deep experts in the topic at hand here and, folks who many of you have probably interacted with in the past. Just as a reminder, we are recording this. So we're gonna send out recording the presentation afterwards. We are also, taking questions as we go along. So please, you can use the q and a form, on the on the tabs on the right or, the chat itself to ask the questions. Some of them we'll take as we go. Some of them we'll respond in writing. Some of them we'll save for a q and a, at the end. But, excited to have you all here. So to get started, this is the agenda today. You know, we'll do a quick welcome and introduction. Then we're gonna go into a little bit of a a data warehouse one zero one, especially in the context of NetSuite to make sure that everyone is, understands the the the basics. And for those of you who are already pretty familiar, you know, just kinda hang on and we'll get to more advanced and, NetSuite specific questions, and topics. We will go through some of the our learnings and best practices from having done this, so much for so many years. And then we're actually gonna go into demonstration of how this applies, especially within this legal context. And at the end, we'll save to share some resources, and some q and a as well. We will have a survey coming up at the end, so, please stick around and and to be able to, answer those. Just so you understand, you know, we always have these themes that come up and often they're they're similar in terms of, the value of wanting to integrate your your applications and data together. Data warehousing, and peripheral, adjacent items, is very much about insight and visibility. It's about having the right data at the right place at the right time so you can make the right decisions for your organization. Scalability is also important, not just in terms of the volume and the complexity of the information, but also in terms of the, your ability to move quickly as your company grows, you know, without necessarily needing to, increase your your spend or your headcount, and then ultimately control. This is really important to be able to understand, you know, where your data is, have proper governance, and make sure that you you are doing the things, you know, to protect your business and make sure that avoiding mistakes and making sure that everything is running smoothly. We won't spend too much time on this, but for those of you who are not familiar with Celigo, Celigo is a, today, have has grown into becoming one of the biggest, most important iPaaS platforms, in the world. We, are number one, on g two, out of 200 and so, platforms that are, listed there for over six quarters in a row now, you know, visionary in the Gartner Metro quadrant. And, you know, with over well over 5,000 customers doing over 40,000,000,000 transactions a month, within our platform. So, we have a lot to share on these, topics based off of the experience of our thousands of customers. So with that, I am going to pass this on to Nate, our solution consultant, who will now take it over and, provide, an introduction as we speak into, more of the best practices of doing this all. So take it away, Nate. Thanks, Argo. So before we get into talking about architecture, the features of data warehousing, what are some of the reasons why an organization might want to integrate into a data warehouse? Right? So lots of organizations already have built or purchased applications that's that's storing data. So when you talk about NetSuite, it's got financial data, it's got order data, it's got product data, and you have CRMs that support, you know, quote data or even HR applications that have employee or hiring data. So so why do you need a data warehouse to to restore this data? Well well, actually, what I just described is kind of the initial problem that that organizations run into. Right? All that data is siloed in all these applications. So you can't really have a complete picture or an analysis of what's going on in the organization. So right off the bat, that's where data warehousing begins to provide value. So can you consolidate this data, perform an analysis, drive business decisions? Can you drive downstream processes? Can you take data out of these applications and perform businesses, form the needs for other users in the business? And can you do that with control? And across all that, can you support the data compliance requirements or the audit requirements from a financial perspective, if you don't have a data warehouse? So so that's the reason why you would need a data warehouse. And what does this look like on the ground? So, you know, at Celigo, we've seen these common use cases where the data warehouse is able to to fill in those gaps and and meet that need of organization. So the first we've we've kind of already talked about, right, mentioned is analytics and insights. So when you take this data from all your different applications and you're able to blend it, enrich it, and join it together, you're able to perform these analysis. You can aggregate the data. You can forecast the data, gain insights. And oftentimes, this is delivered out to business users. So decision makers in a c suite are able to look at reporting and understand what's happening across the organization, or individual contributors or teams are able to take these dashboards and monitor the performance of the business at a more granular level. So that's first thing gained is this analytics and insights for the data. Then the next use case, reverse ETO. So once you have the data, once you gain these insights or or or business understanding, you you can push this data out. Right? It doesn't have to just stay in the data warehouse. So, all these other applications that I I previously mentioned, they they they might need data from other applications directly or they need a more, a deeper understanding. Right? So this is where you can push that data to the finance system from the CRM data once insights been given by a about a customer. You can also control out this access. When all the data lands within the data warehouse, you then have the ability to point where you need that data to land, in a in a more controlled and compliant way, and then drive those business decisions on the applications. Another use case historical data. Right? Organizations are always, you know, changing applications or they have legacy applications that they've been using for a long time that they wanna transition off of. And this is where a data warehouse can immediately come in and store that data. So when you're transitioning to a new application or you wanna do long long term forecasting or trend analysis, if you have all of that data stored within the data warehouse, you're able to not worry about losing that. You can, again, begin to perform these analytics insights on that data and do that forecasting as well. And then across this, as I've kinda mentioned, is is data data governance. Right? So you wanna ensure that, you know, sensitive data is only accessible by the users that need it. Only giving the the the least access to users to perform their day to day, jobs, and and you can use the data warehouse as that broker that that data broker to to push and and pull the data as needed. So these are some of the use cases that are not exclusively to data warehousing, but these are the most common ones that we've seen here at Celigo. And all these use cases run across many different offerings in the marketplace. Right? So, these are just some of the logos of some of the offerings that we we have and that we've integrated with. But, really, amongst these is is choosing the right, data storage solution for the right use case that you might have. So although there's a lot of, you know, functionality that's shared across these different offerings, We kinda like to divide them into three rough categories, again, with a lot of a lot of overlap, between them. So the three categories, databases, data warehouses, data lakes, right, they're all data storage, devices used to manage and store data, but the use case and the architecture of them is specific to what business process you're you're trying to accomplish. Right? So if we start with databases, this is much more related to, high concurrency, high volume transactions, where you're trying to move data in and out very quickly. This can often be thought of as, like, the engine of your applications where you're having to do quick reads, writes at a high level, and and with a lot of transactions. You're able to enrich data and blend data in a database with with different tables, but, typically, it's very, you know, transaction. You know, CRM data coming out about orders or, specific, you know, details about a customer. When you transition more to the analytics, side of the house, that's that's where the data warehouse is starting to come in. Right? So you can consolidate data from from multiple places all within the data warehouse and oftentimes used for for analytics and reporting. This is because data warehouses typically allow for more advanced, reading. You could do complex queries on them. You can do, create reporting, push the Power BI dashboards or Tableau, and and give access to that data from the user. So this is typically where that analysis occurs is at the data warehouse level. And then the data lake is kind of the consolidation of multiple of these together. Right? So it's designed for, analysis and data storage at a higher scale. So it it's receiving both, you know, raw and unstructured, semi structured data, historical data coming in kind of unaltered, and that allows for, you know, geared more toward, like, data science or machine learning where you're taking this raw, unformatted data into the data lake at a higher scale, and then having to perform more advanced analysis on that. So this is where the medallion architecture, understanding what's happening in these different architectures starts starts to originate. Right? It originates from this concept of the data lake where you have lots of data in any format coming in. How do you make that usable to a business? So where all the data could be coming from, it could be any of these number of sources. Right? It could be applications, could be databases, files, event driven architecture, we have, like, web hooks, and you're loading all of that in into the the the data lake. Of course, this kind of a down architecture we're seeing more and more commonly even occurring in data warehouses. So this isn't this isn't exclusive to to a data lake, but this is originally where it kind of started. So I'm taking all this data. I put it into my bronze, level. Typically, the data is is appended here. You're not adjusting or updating records. You wanna capture everything and you want it to be as unaltered as possible. This is because this is where you want maybe a data scientist to come in and be able to analyze trends or or do some complex analysis that's not being obfuscated by, transformation you're doing down the line. So this bronze layer really is a catch all and grab for all the data within the organization. And then you start to push this up the the medallion layers to be usable to different teams. So the next being silver, typically, where you're joining, doing some transformation, applying a schema on that bronze level data, and making it usable from an analysis position. So maybe I can write, some simple queries or create some dashboards that specific user teams might be able to use, but this is at at a more defined level. And then goal level, often called business ready is where, you know, the standard users are are getting that data. So they're able to have a very, easy to understand analytics dashboard or gain business insights. This is where business users are taking the the the culmination of all that data into and creating those insights. Oftentimes, this is silver layer data that's been joined together with dimensional tables or back tables so that it's it's easy to understand the picture of what's happening to your data. And then you can actually see that's where this the gold, data drives, you know, reverse ETL or insights to businesses or back down to the applications. And we'll talk more about reverse ETL, but, with this medallion architecture, it's it's all about being able to intake data, make it useful, and then push where the business needs. So another, key topic here with data warehousing is is ETL versus ELT. Right? So the letters there stand for the the steps that occur on the data. So the first one being extract, transform, and load. This is where you're extracting the data from those applications. So it could be, SaaS application, a database, a legacy application, and you're doing a transformation along the way, basically, in flight in flight during the integration layer. So I I have my data coming out and whatever structure and I'm cleaning it, validating it, structuring it into a schema and then pushing it or loading it into a database or a data warehouse. We this is this is more common in a in a database structure or or sometimes these legacy BI pipelines where you want the data to arrive in a usable format, in a very structured format. With the advent of these more cloud based, in the data warehouses, you can see this ELT or extract, load, transform, start starts to become popular. So this is where you're extracting the data in the same way, but rather than transforming it before it lands, you're loading it into your data warehouse. And then the transformation is done within the data warehouse. So, again, it's optimized for these cloud native data warehouses, and it does provide more flexibility from an analysis perspective similar to how, when you talk about, like, a bronze layer where it's just receiving data as is, there can be immense value in in keeping it that way where I want to be able to manipulate the data and and and do an analysis from it in the data warehouse rather than worry that I've missed out on something, because I transformed it or or validated it before it landed in the data warehouse. Then I I kinda mentioned this with the medallion architecture, but this is this reverse, ETL. Right? So where I'm taking data from the data warehouse and pushing this out to the application. So this could be to any application, but really, you want to give access to this data according to to what's needed by the business. So a user can work from within their own application that's most common and not have to have access to the entire financial, application or have access to a CRM when really all they need is, you know, one additional field or one insight from the applications. So again, that data warehouse is acting as the data broker for the business. So someone who's working exclusively in NetSuite doesn't have to worry that, their the customer address, you know, is is populated correctly because the data warehouse is updating that from the CRM, as a as a common example. So this also doesn't have to be just field level integrations. It can be, you know, insights derived from the data itself. So something more complex like forecasting or the ICP profile of a customer, can be can be pushed out the application so you can make decisions like, do I need to, up upsell this customer based off of the insights we've you've given or what's the performance of my warehouse, my physical warehouse. I'm running to add more people to to pick packages because I I've noticed a a downward trend line in that data. So typical architecture here, you know, a lot of this kind of been described, but really what this is showing is that the data warehouse can sit at the center of all these applications. So when you're grabbing financial data out of out of NetSuite and you wanna drive, you know, more insights, you need all of these other applications that a organization might be using, to perform those insights. And then out of that, you can push this this business intelligence whether it's a dashboard or it's a reverse ETL back to the applications. That's kind of the architecture where a data warehouse sits. So I'm gonna go through three, you know, quick examples of of what we've seen, real world examples. So, common one is is a complete view of of organizations, customers, you know, or or often call out call 360, where, you have this concept of a customer or an account, but it exists across all these different applications. So maybe you're starting, originating in a marketing platform like a HubSpot where you're trying to generate leads from from organizations, and then they become, an opportunity in Salesforce and you create a quote with them. And then once they become a customer, it goes to financial ERP with NetSuite, and then you're supporting them through their life cycle with Zendesk or for tickets or customer success with Gainsight. Right? In each of these in, applications, there's this concept of the customer, but they're not all unified. So how would someone who works, within sales be able to know that, yes, my customer got invoiced or, maybe your customer success team knows that, hey, this customer is ready for an upsell. They've reached their, you know, requirements, that that we have from a business logic perspective. That's creating this entire profile, called Customer three sixty. Again, all similar architecture as as the slide before, but really it's showing that this is a very specific use case that that can help an organization, support their customers, grow their customers, expand their customers, whether it's a, you know, a software company or a product based ecommerce company. All of this has value in understanding, you know, what your customers are and where you can find value in them. Another example here is warehouse productivity. So just to be clear that there's two warehouses involved here. There's a physical warehouse storing goods for fulfillment as well as the data warehouse, which stores the data, that relates to the real world warehouse. So, another, example that we've seen where, you're trying to increase the productivity of fulfillment for physical products. So, when a customer makes an order on an ecommerce channel or a marketplace, how quickly can that order be fulfilled, how accurately can it be fulfilled. So the order data, the customer data, the financial data, the fulfillment data, all live in a separate application. So by combining them, you can see from the origination of an order being placed, how quickly it got fulfilled by a person in warehouse, who fulfilled it, how accurately did they they pick that package and then ship it. And then you can gather insights like, oh, these products are oftentimes ordered together. We should move them together in the warehouse, or we need more people on this pick line because these orders take the longest to get up. So that let's say, just, again, an example of of taking the insights from all these different applications and and leading to a real world decision making in the physical warehouse. And that I was gonna hop in on that one real quick, Nate, but I thought that another good example that I've I've used in the past, which was pretty interesting was and this was maybe a little bit more punitive, but, essentially being able to track down, like, support tickets to who ultimately picked or packed and shipped products. So if you basically had a support ticket later down the road that says, you know, I got the wrong item shipped to me or, maybe your package never arrived to you so it got shipped to the wrong place, Basically, you can track all that back to, you know, who picked it and then, you know, coach them on, you know, maybe you need process improvements to prevent those from happening or maybe you need to coach people on how to better pick or pack or ship. But those are some some use cases I've used in the past for aggregating all warehouse management data, combining it with customer support data, and NetSuite sales data. Yeah. That's a great example, Tyler, because it it goes across both that customer three sixty profile as well as the warehouse management. Because if you didn't have that data placed in the same warehouse, those are, you know, processes that oftentimes could be considered very separate from each other. Right? Taking an order to, you know, what does a customer profile look like. So, again, it's it's all about having it in a in a place where you can perform these actions and analysis on it. Final, example we have here is is AI, Retrieval Augmented Generation or RAG. So, right, AI is the hot topic these days. So this is actually something that that we do internally at Celigo. So, this is using a different type of database, a vector database. But essentially, you're using AI on on both ends of of this process where you're taking proprietary information from maybe, knowledge articles or internal, knowledge base, and you're creating these embeddings using AI. So they're storing this knowledge as vectors in the vector database. Again, using that same concept where you're late later able to query that data out of the vector database. So now that the data has been stored and is usable, a user can interact with it, through a different interface, whether it's Slack, whether it's a chatbot, whether it's an email, some sort of language based interface where a user is coming in requesting a they're querying the data, but they're querying it in plain language that they understand. The AI is then searching those embeddings, retrieving, based off of the rules that you provide the the best match and then presenting that back to the user in a language that they understand. So again, the concept of having a central place to store that database, in this case, it's a vector database. It it can provide them this value. And, and I'll add there as well the, that's great for, like, documentation or, like, you know, typically in the analytics world, when you had, you know, docs and you had Slack threads and team messages and stuff, right, that's hard data to parse out and analyze. But that's where, you know, recent AI has been great with. But on the flip side, recent AI is not great with, you know, actually getting real metrics, with data you've sent it. So in other cases, everything we've talked about before where we're migrating source application data to a warehouse, AI can also be used in that case to create queries that run against that warehouse and then return the results of that query. So in one case, you've got this vector store that's storing, you know, all this text data for Gong call, Slack. And in the other case, you're actually just generating queries against data warehouse data, and we're pitching those and returning those results to user. So you could say, like and we do this internally. We've got Slack channels created where we're basically, like, you know, tell me, you know, give me the last three opportunities for customer x y z or, you know, something like that. And then it basically fetches from Snowflake in our case and returns it back into that Slack thread for for users as opposed to having to go to the BI tool or or BI team having build a dashboard out for them completely. Absolutely. So now that I kinda turn a little bit more, toward NetSuite. Right? So a lot of this, both the customer three sixty, the, the warehouse productivity use case, even the rag, a lot of this does center on that financial data oftentimes because NetSuite, holds so much of the relevant data to organizations. So how do you get that data out of NetSuite, or back into NetSuite from a data warehouse so you can perform the the kind of business functions that you need. Right? So Solito, we connect, you know, basically anyway you want, starting with safe searches. Right? The UI friendly reporting tool that a lot of users are familiar with inside of NetSuite so you can kind of structure your extract and then we can go and grab that. You can use that as a source of of data for further integration directly into the warehouse. You can also do a bit driven, architecture where based off of events that occur within NetSuite. So a record creation, a record deletion, a record edit, We can grab that data and push that into the data warehouse for an Upsert or a PIN depending on how you wanna structure your data. You can also go direct to the NetSuite tables with the our JDBC connector, or you can interact with the standard rest APIs that NetSuite offers. You know, you can, query the actual objects or a suite QL API, you know, for a more traditional integration approach. So really it's it's user preference, user choice on on how you wanna get your data out of NetSuite into that data warehouse. Yeah. For, for mass amounts of data, JDBC would be would be the way to go. It's super fast. It's read only. Doesn't hit against your concurrency limits in NetSuite. So it's a great way to get all the data out and into a warehouse. Yeah. Absolutely. And another alternative to that, right, is you can't talk about NetSuite without talking about an SAW. Right? So this is this is the data warehousing offering for from Oracle NetSuite where they've stood up, an autonomous data warehouse. One of the huge advantages here is it's also got the business intelligence or reporting layer already built into it. Right? So you can create your dashboard, you can create reports, from within the same place. It also populates with that NetSuite data automatically. So you have a huge lag of your of your data already stood up in the data warehouse when you're using SAW. And then it's making sure that you can get all that other data from all your other applications or sources in SAW to perform that that meaningful analysis or push down requirements that you might have. So that's where you would use a a Celigo to be able to aggregate that data, outside of NetSuite back into the SAW. Some key considerations, from what we kinda talked about. So, Tyler already mentioned one which is great, which is that there's some performance considerations you wanna, evaluate when you're talking about integrating NetSuite and your data warehouses along with all your other applications. What's the most efficient way or the fastest way to to ensure that the data does land properly within your data warehouse? So maybe you're more concerned about performance. You can go j w JDC. Maybe you want it to be a little bit more user driven, so you're using, you know, the event driven listeners. These are all just considerations when you're talking about architecting your your data warehouse with with NetSuite. With JVC, of course, it does require a a a suite analytics. It's not required, but it is ideal. Right? It gives that performance. Another key consideration we like to call out here, you know, record deletions. Right? So not every application has a concept of a record deletion, and that's we it is one of them. So, you know, when once you've delivered data to your to your data warehouse, what happens if a user goes in and deletes that record? Right? It's not gonna show up, and, you know, future integrations. It's it's gonna be kind of a a question mark that's what's happening. So, you know, do you lock down the ability to delete in in NetSuite or do you have a flow, in Celigo that on a record deletion it goes and, you know, updates a flag, within the data warehouse? Just just a purely architectural strategy decision that is being made. It's it's how you choose to handle it. And then we talked about SAW and and again, this is a strategy decision. You do wanna decide if you wanna have your ERP or your data warehouse with within, you know, in your business intelligence layer from a single vendor or maybe you want to separate this out for for, you know, business purposes or or whatever you would need. So, these are more strategy decisions that that you talk about when you're architecting these these solutions. Great. I'll pass it over to Tyler now for, the demonstration of of Celigo. Awesome. Thanks, mate. Stop sharing here and share my screen. Alright. Hopefully, everybody can see this. Alright. So if you aren't familiar with Soligo, this is your home screen whenever you get into Soligo. These are all the integrations that you've got within the platform, of course. Right? You could have, you know, IT service management, customer three sixty. In our case, we're going to warehousing. So for all the flows that we put for NSAW and Snowflake in this case for demo purpose, we put it all into this data warehousing tile. When I hop into this tile, I've, segregated my flows into a few different options and it's kind of these relate to the use cases we went through earlier. One being ELT, where I'm extracting data from, in this case, Salesforce or, in this case, NetSuite. Another for reverse ETL, where I'm extracting out, customer insights from NSIW and then pushing it back into Salesforce. And then lastly, a historical sync for loading, historical data in. So a lot of times whenever you're maybe you're migrating to NetSuite or migrating maybe to Salesforce off of another CRM or something, you might need to store all that legacy data. So this would be an easy way to load all that. So I'll first hop into the ELT approach for, couple different options here. I'll go into n s a w n s a w to start. So So when I hop in here, you can see this is our flow canvas in Celigo. And on the left hand side, you've got your source data. In this case, we've got Salesforce. And on the right side, we are putting that data into NSAW. When I hop into the source or real quick show you if you were to add another source, you can you'll be presented with a list of all the applications that we can connect to. So we've got, right now, over 890 different applications we can connect to. And this varies, of course, between, you know, trading partners, databases, and then tons of different APIs as well. And then, of course, if you don't have your application listed here, there are universal connectors to connect to everything else. In this case, we just chose Salesforce, so we click Salesforce here and then went into the configuration. So if I hop into the configuration I've already got, there are a few ways to get data out of Salesforce. One being the traditional rest API from Salesforce, which, you know, is pretty good for most application app to app integrations, or good for kind of smaller volumes of data. But we also do have a bulk API support for Salesforce exports, which for data warehousing use cases is great. It's a lot faster, more performative when you're grabbing thousands, tens thousands, hundreds of thousand hundreds of thousands of records out of Salesforce and into a warehouse. But in this case, we've just chosen rest API. And from there, I can preview on the right hand side there. I can now see the record data coming out of Salesforce directly, and then all this data will eventually eventually be pushed into NSIW. And then one last field specifically, mainly for data warehousing, is this, checkbox to include archived and deleted records. So in Salesforce, you can, of course, archive or hard delete records, or soft delete records. And so in this case, a lot of times for analytics, you wanna capture, you know, when something was deleted. Because if you had previously synced that data over into your warehouse and you're reporting on deleted data, you know, that's not great because your data looks bad and analytics team looks bad at that point because their dashboards aren't up to date or the dashboards are not matching what users are seeing in Salesforce itself. So you'd really wanna check this box and handle deleted records for other source applications depending on how they handle it. So close out of there. And then lastly, all you need to do is go to your import step. So our I already have an n s a w step here created and we'll show you how easy it is to make an n s a w n s a w connection. We've made it super simple to just upload the credentials zip file that you've got, and choose the service name, enter your your username and password. So this is a lot simpler, especially when you compare it to some other offerings. And then next, you just choose, you know, which table in in s o w do I wanna go to. So here, I've got the Salesforce account table under my o a x user and then my primary key on the table is ID. So when I when I map to this table, it'll dedupe all of the incoming data based off ID. It'll just merge it directly into this, Salesforce account data table. And then lastly, you just need to go set up your mappings. So you've got various mappings to, you know, the ID field, sites, all these custom fields that you've got. And these would map directly to those columns that you have specified in in SAW. Okay. So that is ELT. So that's extracting out of, Salesforce and into NSAW. And then the other scenario, which I won't fully go through, but this would be exporting NetSuite data from the NetSuite JWBC driver and then going into Snowflake in this case at the data warehouse. So again, there's just multiple different ways you can do this. We're pretty application agnostic whether you're extracting from the, you know, 900 plus applicate sources and then going into the, you know, 12 plus, destination for Snowflake, Databricks, and SAW. It doesn't really matter what you choose. It's just it's ultimately up to you, but you can use Ligo in this case for any of those cases. Next up, I'll go into reverse ETL. And so like I was showing when I was adding a source, you can easily add any, any of those applications can be used on both the source side and the destination side. So here, I've got NSAW as the source application in this case, and I'm selecting from, Salesforce account table, joining it into some customer insights, and then bringing that data over into Celigo so that I can populate it downstream. So here, I can preview the results of that query. And, of course, this is a simple query, but, you know, it could be a lot more complex than this. Once I've extracted that data out of NSAW, I'm then going back to Salesforce to update the insight. So when I click on the insight the Salesforce import, I'm just choosing the API type, which object in Salesforce do I wanna go to. I wanna update that record only. I'll find that record based off the ID, and then I'll just map in that data into Salesforce. So I've got the account rating into the, or sorry, the quadrant from NSAW into the account rating field in Salesforce and then the ICP into a status field. And so and so from there, once you have that data in Salesforce, you can use it to drive lots of different decisions. Right? You can, update maybe routing for accounts or, you know, typically, you have, like, bands of, you know, higher tier accounts, maybe are a different set of reps, or maybe get separate attention based off of data that you've, gathered from your data warehouse. And then lastly, the historical data use case. Here we've we're just using our data loader tool, in which case you are just uploading a either a CSV file or JSON or XML or Excel file. So this would be if you're, you know, migrating to Salesforce or migrating to NetSuite and you've got legacy data, you can just use our data loader tool to load it directly to the warehouse. So if you've got that data extracted, you could just load it here. And then again, it's the same on the import side where you're specifying, you know, which table do you wanna go to, what are your primary keys in case you wanna do a merge operation as opposed to an insert, and then you're just mapping your your fields in. And so that is, day loader. And then again, you can just see, you know, all of your runs between everything. Connections can be shared across the platform, you know, full auto log. Everything else since we go is all the same. And with that, I'll pass it on back to Nate. I think, Nate, unless you have something else to add, you know, I can start jumping into, the resource q and a. Okay. So let let's jump in here. So, real quick, before we jump in q and a, do note that there's a survey, coming out. So I'd love to get a sense of how this is going. And I wanted to point to a couple of resources that might be, helpful too. We're doing our global, roadshow. We've already done multiple cities, and, so if you are a single partner, single customer, single interested, you know, come visit in one of these locations here, you know, or invite folks, your colleagues or customers who are in this this area. The next one is in Dallas in August 20. Looks like it will be, pretty big. You get to meet this legal team and go over, quite a few, individual details. These resources are available too on the on the docs tab here. We did, launch a NetSuite integration handbook. It is very detailed. You know, goes through so much about, the specifics of, how to integrate NetSuite to other applications. In addition to that, this is part of the large ins and outs NetSuite integration series. This is the seventh one in the series. We've already done Salesforce and Shopify and Amazon and so on, and we have a few more upcoming. We we, made one change for the next one. It was gonna be HubSpot, but we launched new Shopify b two b functionality. So the next one is gonna be about Shopify b two b, but then we'll cover Adobe Commerce spreadsheets, and advanced sales force to close out the year. We do have a couple additional webinars coming up. We have our global partner, Tom Hall, tomorrow. If you haven't signed up for that, and yours legal partner, we'd love to see you there. And we also have, an ADI webinar coming up on July 17. So busy week here of, webinars and presentations. And again, yeah, these are this is the ins and outs series. So with that, let's go back to q and a, and if there are questions. First question, what, what's the difference between traditional ETL tools and the Celigo? Why should I choose Celigo, for these integrations? Either I can I can take that unless you wanna jump in? Go for it. Go for it. Yeah. So the the great thing about Celigo, right, is is it's more than just the ETL tool. Right? So you don't have to learn a brand new tool to handle your data warehousing integration needs. Right? So many of our customers also start with those application to application integration use cases where maybe you're just syncing your financial data to your CRM at a very basic level. And then you could still leverage the same tool in a very efficient way to start delivering that to your data warehouse to drive those those insights or or drive a a business process in the CRM rather than just receiving the the kind of line level data across. So, again, we like to call it a single pane of glass for integration. It's also a single tool set. So it doesn't require, you know, multiple contracts to to have the same functionality. And Celigo also supports both the the intake, the ETL or ELT, as well as the reverse ETL coming out of the application. So again, just more efficient use of technology to accomplish multiple integration patterns. Great. Is there a limitation in terms of the volume that, Solito can handle? Nope. We don't we don't meet our data at all. There's no there's no limitation, associated, which is certainly the case with some other tools. So, again, again, when we talk about efficiency, it's both, in, infrastructure, efficiency as well as just a costing, efficiency since we're now worried about the number of transactions. So highly efficient when it comes to data warehousing. How does that impact pricing? It makes it very scalable and very, predictive. So you're not wondering at the end of the the quarter or end of the year, am I gonna get hit by a huge bill? It's easy to predict, which I know any business is is interested in that. No. I haven't got a CFO yet that doesn't wanna know what what's it gonna cost to to use a a solution. Okay. How do you handle on premise databases? I can let Tyler jump in here. Yep. So for on prem databases, we have a what we call an on prem agent, and you can attach that on prem agent to any of the databases or connectors that you saw on the drop down list. So, basically, you install the agent onto your local, machine or another machine in that same network, input your token that you get from Celigo generating, and then we create a reverse SSH tunnel back up to Celigo where we can then have access to those resources that are on that network. In this case, querying that on prem database or on prem API or or whatnot. Okay. Let's see. Any other final questions to join? I think that might be it. So thank you all for joining. Thank you, Nate and Tyler, for, the presentation. I hope this was helpful and useful for everyone. And remember, if you, you can sign up for the, upcoming webinars directly, you know, from the docs link over here. But unless we have any questions that come up to last seconds, I think this is it for this, presentation. And, we hope to see you either tomorrow, for the partner town hall or some, other upcoming webinar in the near future. Look forward to hearing from you all. Thank you. Thanks.