CHRIS: Absolutely. One of the most common workflows that we see, for example, with eCommerce integrations is there will be category data, product data, inventory price data. We may have customer specific pricing and then for the products themselves and the categories, there may be meta information on the side. And all of this data needs to be appropriately up to date and it needs to be accurate. And it tends to have different source of record between the ERP, possibly other external sources and then the eCommerce application. And so just in a very simple hypothetical scenario, the ERP may be the source of record for the SKU, for the product title, for probably the product name. The SKU, the pricing, the inventory, the cut customer specific pricing. And let's say that, that's it.
Then the eCommerce system, if it doesn't already have the record, so you can see this in the workflow diagram on the right, doesn't already have the record, then it's just going to take all the data from the ERP. The connector is running and it goes through business logic. Then in this bidirectional concept, it's going to say, "hey, do you already have the record in the eCommerce? Nope. Okay. Here's all the data from the ERP." We don't want to not bring in data that's available in the ERP. Okay, great. Then one of the marketing team members goes through and many times we'll have a custom workflow that's in place that says, "Hey, marketing team members, we've imported these records. They're marked as not published because we're waiting for you to put the marketing content in there." And so they're new items that got added to the eCommerce platform by the integration.
The marketing team will go in and they'll update the meta titles, meta descriptions, add really nice pictures and maybe do other things to customize them, give them custom URL, etc. Well, we don't want to lose that data next time the integration runs and some connectors will do that. The workflow would then run again after this marketing content has been pushed, and it would say, "aha! I see the data has been updated in the eCommerce system. Maybe a certain status has changed. And so now I want to respect these fields that are in the eCommerce system. And possibly depending on the business, maybe even bring this data back into the ERP." There, you would have a situation where some of the fields, not all of them, some of them would be in the eCommerce as essentially a source of record in the eCommerce for some of the marketing content. And that might get pulled back to the ERP so it can be used within the enterprise for other sources.
And then the data that's in the ERP may have also been updated recently with new pricing. Or maybe there's a new product name and that needs to come in. And so these are just some examples of things that the integration platform needs to be able to handle bringing in updates from the ERP while respecting updates that have been made in the eCommerce platfom and vice versa. So bidirectional on a field level and being able to follow business logic. There may actually be a status change with an order. And based on the status change, we need to respect fields whenever they're in a certain status level, in a different system as the source of record, which is really, really cool. I mean, you can do some really cool things whenever you have this bidirectional multi-field based workflow. But hopefully, that's a good example, just very high-level example there.
RON: Yeah. It makes perfect sense because most of the time business, are taking care of pricing and inventory and things about their products in their ERP configuration. But on the other hand, the customers are initiating invoice payments, requests for quotes, refunds, warranty repairs, and orders, they're initiated on the other side. There's a significant amount of data on both sides that the master sources of truth originates from the opposite end, but that data has to flow back and forth. Especially, I mean, you look at some eCom, it starts as a quote in the eCom and then goes into a quote in the ERP where the sales team then has to set a price, generate a quote, approve a quote, which gets then sent back to the UI where the user gets notified, and then they can convert that quote to an order.
And then the order goes back to the ERP for fulfillment, which then turns back into a ship status and then goes back. And then let's say the product shows up damaged. Then they have to go into that UI and initiate a replacement, which might initiate an RMA workflow. I mean, we've seen some really in-depth workflows, and that's just one piece of one product being purchased that generated all of that integration work.
CHRIS: That's right. Yeah. Fundamentally, that's where the value is, is getting these rather brittle and precise workflows with key sequencing that has to occur to be as automated as possible. I mean, really, is it such that the business has the full automation that makes sense for the business?
RON: Right.
CHRIS: A lot of times there needs to be a manual step, but if the technical side of things is the limitation, that's a problem. If it's just a business workflow that it makes sense from a business perspective for something to be manual, no problem. But you really want to understand, is the partner you're working with, are they able to implement these really granular aspects? And that's a great segue into customization ongoing maintenance.