CHRIS: In addition to that, we typically are looking for some form of scheduling and periodic schedule on what's commonly referred to as essentially an atomic level or kind of per task that's running. Every type of task or workflow that needs to run, it can be discreetly set for a particular schedule. And the schedule can follow some very advanced rules. It can queue based off of changes to records. Essentially, it can run on demand in real time or it can run on a periodic schedule. Think of a cron job as an example, and be able to run on a very specific schedule. And Ron, and if you want, feel free to share any examples that you might have on that.
RON: Sure. Yeah. I mean, on the queuing one, I loved how you talked about the queuing one. And for me thinking about that, it's like if I had 10 sales orders that came in and I had some kind of network hiccup and I didn't put those sales orders into the ERP configuration for fulfillment and those blow up, I don't want those sales orders gone. I mean, that's literally money straight out of my pocket. The queuing mechanism for Connect can take all those and do reties. It literally moves it into a queue that, as Chris said, is persisted, so it can literally retry until it reconnects or allows you to go fix what that area is and then invoke and trigger the sending of those things as they're in this queue, basically ensuring you don't lose any data. I think that's a huge important one for the queue. And I love that.
The scheduling one, when I typically see my clients use this, a simple example would be, what if in your ERP you've got 700,000 SKUs and you're trying to pull all those products back into the storefront? And that takes, I don't know, let's make it fast 15 minutes to run 700,000 product updates. Well, you're obviously not going to run that in the middle of the day and clog up your whole entire integration. You might want to create unique, independent integration tasks and have all products sync at maybe 2:00 AM every day. On the other hand, if you're customizing pricing or you're changing inventory counts as you're fulfilling throughout the day, you might want to run inventory every 10 minutes. So it says, "Hey, just get my inventory, that's all I need to be on the website." Pricing and inventory has to be really accurate and really fast. The scheduling allows us to create individual integration queries and then schedule them to run at different intervals or they could be called in real time, as well, right?
CHRIS: That's right. That's exactly right. And what you were talking about there with this large amount of data is a great example of where data storage and caching and possibly data manipulation really makes sense. And we'll get into this as we go. But basically, one of the things that you want to look at with your integration platform is, is it going to mechanically be able to deal with large amounts of data and is it going to be intelligent so that it can deal with scenarios where you have a master record, but you have updates coming in from different sources and maybe there are field level master delineation. You could say for a product record, the SKU and the price and the inventory data is coming from an ERP, but the marketing metadata is actually living as a master inside of an eCommerce system.
And so we need to be able to have this powerful kind of delineation between the source of record, if you will, as well as things like when an order goes through a certain status, we need to be able to manage with business logic that is easy to configure and easy to set up within the integration platform. If it's in this status, this is the source of record. The eCommerce is the source of record. When it's a new order, that's a web order, for example. And then once it goes into fulfillment status, now the ERP is the source of record. And so these are just some examples, but does the system you're using have this capability? And so just in general, I would love to hear, Ron, if you have other examples on that as well.
RON: Yeah. The master data management is great. For example, we have this with a lot of clients. Let's say Clarity signs up as one of your customers and Clarity can purchase on account. Now Ron and Chris, are contacts at Clarity. Ron and Chris may be able to log intothe portal's eCom storefront, and they can change my name, my phone number, my email address, etc. But Clarity filled out a contract and the sales rep put that contract and that relationship in the ERP so Ron doesn't have rights to change that. In the master data management model, Ron can edit the fields about his personal contact information, but he can't go in and edit and muck up any of the fields that were set up at the contractual level in the ERP. Like you said, some of the entities source of truth is the configuration in ERP while others live inside the storefront. Yeah. That makes a lot of sense. I love that.
CHRIS: Agreed.