Enhanced Error Management: Celigo Error Management 2.0

Welcome, everyone, and thank you for joining us today. I am Kristie Conner, director of product marketing for our platform Celigo Integrator.io, and today we have guests from our product management team here to introduce our new error management framework. Our new framework is designed to help our customers streamline error management, making it easier to manage and monitor your enterprise integration. So Leo is going to kick off with an overview of Error Management 2.0 tools and highlight new features along with a live demonstration so that you can see them in action. He’s also going to do a tutorial on how to turn this new feature on. Praveen is here as well to speak to the specific features for our integration app. This presentation is going to be recorded so you will receive an on-demand link. We are also going to be hosting a live Q&A at the end of the presentation so you can start asking your questions at any time using the chat box. Before I hand it over to our product management team, I want to share some good news. Next slide, please. In February, we were named a winner of G2 best software awards for 2021, and we were also ranked the highest iPad in the category of IT cloud management software. These G2 awards and badges are all based on our customer reviews so I just wanted to say we just wanted to give you a big thank you to all of our customers on this call. We really appreciate you. So now with that, I’m going to turn it over to our product management team to share our new error management framework. Thank you, Kristie. Hi, everyone, my name is Viliandy Leonardo. I am part of the Celigo product team and I focus on enhancing all features that are at the platform level. So what means that the features that I’m focusing on a lot are the ones that are available for do-it-yourself flow or that are also applicable for pre-built flow, right. And error management toolsets are such functionality that are applicable for both types of flows. With that, I’m very excited to announce that the new error management is now available for all our customers. We made significant changes both on the platform engine and on the user experience. In this webinar, I’ll demonstrate major changes in the new error management. I’ll start with the new error handling. Then we’ll look at the new dashboard to help you make data-driven decisions. The third one is enhancements to the error email. Then we’ll talk about what is auto-resolve. Next, we’ll talk about the new error API to help you manage your error programmatically. Again, all these changes that I’ll talk and demonstrate will apply to both custom flow and pre built integrations and later, Praveen, my colleague will go over specific changes for integration app. First, let’s look at the new error handling experience. So when you migrate your account to the new error management, the current job dashboard that you have will be deprecated. So this view of reviewing errors by job run via this dashboard will no longer be there. But you now have various many, many tools to quickly find errors and manage a large list of errors more effectively. You can search for errors. You can retry open errors and a very popular request from customer is the ability to retry, resolve errors. You can also view errors while the flow is in progress. And now, I’m going to show you these tools in the product. So this is my account that is already upgraded to EM 2.0. When you click on the tile, the first thing that you’ll notice that on the flow tab, on the flow list, you now have the information of how many open errors each flow has. And you can click on the count and it will show you the drill down of the errors. And it breaks down by the cut off error per integration step. And when you click into it, it will open up what I call an error table. So this shows you all the open errors for that particular step from all the runs. So it’s no longer grouped by its job run. You also have a view to look at resolve errors. What is also new on this view is that in additions to look at the retried data or the payload of the data, you have this field called– I call it an error field. This is the information that you can search the error by, right. You can search by the informations or strings in the message, by timestamp error ID or even a trace key. You can filter by timestamp when the error was created, you can’t filter by the source. And like I said, you can search for the error space on the error fields. You still cannot search by the payload or the retried data, only by the error fields. Next, I want to talk about the download functions. So unlike the current error management where you download– if you want to download the errors, you have to download per job run, here, you download– you can download everything or you can specify that the time range that you are interested and with one click, you’ll have the errors information that you need. Again, the informations that I downloaded is not the the payload, but the error field’s informations. Next, I’m going to show you the experience of retrying an error. So multiple records that you want to retry, just like the old ones and then you can go here and if to say you want to retry two errors or it allows a maximum of 1000 retryable errors with a single click. So I’m going to do two. What’s going to happen is the system is going to mark those two errors as resolved, so they will be in the resolved sections. So these are the two areas that I chose to retry. And then you’ll see that the system is giving you a signal that it’s in the process of retrying the error. And when it retries complete, it will tell you it’s done and if the retry fails, then when you refresh, you’ll see that, hey, those two retry fail and we put the label, retry failed. This way, then it’s easier for you to tell if these are the errors that comes from as a result of a failed retry actions. We keep a count of how many tries you have. Also, keep in mind that the Retry fail label will be there during your log in sessions. So if you log out and log back in, this Retry label will not be persistent or it will go away. The other one I want to mention is the fact that with the new error management, you now have the ability to retry Resolve errors. So this is a very popular request because sometimes a customer feels not sure if the errors can be resolved, so they tend to keep it open and not sure about it. So with the EM 2.0, don’t be afraid to resolve the errors. Once you resolve the errors, the errors are still here. If you decide later, “You know what? This is not really fixed,” you can always select them, retry it, and then if it’s not fixed, it’ll come up as a new error here. Keep in mind that retry data is still available for 30 days, right? So just keep that in mind that any errors that you have here can only be retried either open or resolve errors within the 30 days of the time it was created. Now I want to show you the new run console table. So if you navigate to the flow, you have a run console here. The rund console show you the most recent result of the run. So it shows that this flow last run about 44 minutes ago and this is the result. It shows you the number of success, ignores, errors, and resolve, and a number of pages that are created in the run. The nice thing about the new run console and this change is that I’m going to run this flow. When the flow is running and it creates the error as it’s running, you cannot access the errors even before the flow run is completed. So they are three steps here. Here, there is nothing. Everything is, I guess, Resolve or there’s no data here. And pay attention to the Select step. I designed the flow so that it will always fail here and it already creates 80 or now 100 errors. So you can drill into it and look at the old open errors. And as soon as the error is available for you to view, you’ll see this pattern will turn blue. You can click and you’ll start seeing the new errors available for you to review as the flow is running. We’ll give it some time for the system to make the information available for us to view. Let’s take a look where we are in the run, still early in the run. As you can see, these are all the error just being created, right? The timestamp says just now. And the flow is still running. So this is nice because then you can– if you’re building a flow or there’s a flow that you want to see what are the errors and then you can stop it in time. So I’m going to stop this flow. I’ll cancel the run. And you can go to the run history tab. It shows you the result, the snapshots from all other runs. So unlike the run console– the run console shows you the last, most recent run result. The run history shows you the historical snapshots of the run and when you resolve the errors. So I’m going to, let’s say, resolve. That’s like 50 or 1,000 errors. And the count will go down by 1,000 but the count of errors in your run history will not change because, again, the run history will show you the snapshot or what happens when the run runs and this is the number of errors that happen in that run. Okay, so back to the next topic. The second new feature that you have is a dashboard that shows the run results over time. So it’s a different dashboard that you are familiar with. So this graph shows the metrics of the run up to one year. Again, we continue to keep the error details that appeared for 30 days but we do keep the metrics such as the kind of success, errors, and ignores for one year. So this dashboard is a great tool to help it digest a large set of data over time, right, to enable you to do some trend analysis. When you look at the data, you can see a pattern, get some insight, and take some actions. So what I have here is the screenshot of our own integration that runs in our production system. So we use our own product to sync the data into Gainsight applications. So until I had these graphical tools, I never realized that when I am syncing the data into Gainsight, there’s a pattern in the number of volumes. So on the top here, is the number of successes and in the graph below, which shows average processing time for its success record that it processes. So one insight I see from here looks like the data is going down on the weekends. So that means if I need to do additional flow run maybe, I should schedule it during the weekend time. And another interesting thing for me in my flow here is that there are two flows that I’m quoting here. The greenest color here is an update flow and then the blue here is the record flow. As you can see relative to the number of records they update, the ad count is really low here. It’s almost close to 0. But the time it takes to add the flow is actually above the update, right? So it triggers similar questions. Is the ad operations always takes more time? Is it the way I built my flow of adding that is not efficient or is there a conflict in the connections they have– like the connection is running– that’s a lot of cue in the connections to do updates. So that triggers questions that I want to investigate further. So let’s take a look at this board in the product. There are two types of dashboard. The first one is at the tile level. So at the top level, it shows you the number of these metrics at the flow level. Right. So you have the kind of success, processing time, the number of errors, a number of records that are ignored in the run. And you can change by which flow that you want to take a look. The integration level means that I am plotting this matrix by aggregating the result from every flow. So the integration level, as you can see when I hover over, it’s obviously the highest one up here. You can change to the time window, and the bucketing will change depending on the time horizon. So when I choose the last 24 hours, it will bucket the metrics at hourly bucket here. So the way to look at these numbers is– let me pick one flow just to keep it clean. So it shows here 9,000 success records from my flow number three at 9:00 AM. So the way to read this graph is that because it’s bucket from at an hourly level here. So between 8:00 AM and 9:00 AM, the flow three, successive process 9,000 record. So it’s not reading it that at 9:00 AM, you have 9,000 successful records. But from 8:00 to 9:00. And similarly from here, from 7:00 to 8:00, you have 3,000 successful records. Now at the flow level, you also have the dashboard. And at this level, at the flow level, you can actually analyze the results of the run at each integration’s step at the flow step, right. So it helps you to drill down from the flow to first step. So if I just want to look at my slack notifications that I can tell, that’s not successful. That’s by design. And the number of errors is just there. The next topic I want to talk about is the error email notifications improvement. So the first enhancement that we made is the timing of the error email. In EM 2.0, the platform will run every 15 minutes and it will check if there are any new errors or any newly resolve errors in the past 15 minutes. And if they are any, it will send an error email to anyone who subscribe to that flow error. So for comparison, in the current error management, the system will only send an email if a flow runs and at the end of the flow, it the flow produces some errors, only then it will send you an error notification. So this change will help to bring forth the error message to you sooner by telling you, “Hey, the flow running and it’s already producing an error.” So if your flow runs a lot longer, you’ll get a notification sooner. Another enhancement is that we bring the error message forward into the email itself. So this is an example of the new email notifications. It tells you the name of the flow and it gives you the summary that it has three new errors and how many open errors that you have. And then it breaks down those three new errors based on the stuff in that flow. And then it tells you what those errors are by showing you the error message. The error email will show you up to 25. And if there are more than 25 new errors, it will not show it in the email because then the email gets really long. But you can click on the icon here and it will take you to the platform. You log in and you will see the error tables and you can review the rest of all error messages in the platform. And finally, the changes with regards to notification is that with the right permissions, you can manage other user subscriptions. So everyone who subscribes to the email will receive that one email message. So you no longer have to forward the email to your colleagues to troubleshoot or to share the message. Everyone who subscribes to that flow error notification will receive one email, and it’s easier for it to collaborate and communicate. Now, I’m going to go into the system just to show you quickly the changes. So one new change is that on the flow itself, you can manage your notifications, yes or no. And to manage somebody else subscriptions, you’ll go to the users. And here you can add, for example, Steve. You can turn on the notification for Steve. And I can do this because I’m the owner of the account, and if you are the administrator role or someone with a manager role, you can also manage someone else notifications, right? I can add mine or I can remove those notifications, which I will do. So he will not get our emails from this demo account. Next, I want to talk about auto-resolve functionality. With the new era management framework, we introduced the concept of auto-resolve. The auto-resolve will resolve duplicate errors in these two scenarios. If there are duplicate errors created during a run, the system is now smart enough to know that this is duplicate. So I’m not going to keep all these duplicate errors for you, but I’m just going to keep the most recent one for you. As a result, the number of errors that you have to review is lower. The second scenario is that when the flow runs, it’s going to check if there are already existing open errors for the same record. If it already has one, it will resolve the duplicate ones. And again, will only give you an open unique error for that record, right? So, again, the end goal of this auto-resolve is to reduce the number of errors that you need to review. And you can tell if the errors are auto-resolved. When you go to the resolve error sections, you’ll see the resolve by autopilot. We will soon change the terminology from autopilot to auto-resolve as part of our rebranding of the feature itself. I’m going to show you the demonstration, how it works, because it’s a lot easier to relate to how or what these duplicate errors mean. So here’s an example of the first scenario. It’s a very simple flow. You have a flow that reads the data from a file in my Google Drive and the sample of the data is very simple, is a student data, has an ID, the role as TA, the name, and the age. So the ID, this is how the system will tell that this is a unique record or not. This is also known as a trace key. I’m going to show you the content of the file. So here’s the content of the file, and I intentionally create duplicate records, right? So there are a couple of duplicate records here. And all it does is rates and send it to Slack and upload the data. But I designed it so that it will fail at Slack step. Going to run this. So my file only has eight records, and then you’ll see that all of these eight records will fail. But since there are some duplicate records in there, you’ll see the other result in actions by seeing that as it runs, there are a number of records that result for me. So it creates eight errors. and for automatically resolved, so if I click into– there are four, so this is the one that has the duplicate records. If you go to resolve errors, I’ll see– and there are four errors that are resolved for me auto-resolved functions. The second scenario that I think is more common is resolving existing duplicate records. So it’s again, a similar flow. It’s reading a different set of data. It’s actually a large data set here, and I don’t remember if I have a duplicate dataset in here or not, but I’m going to run it to produce the first set of records. So the flow-to scenario, this scenario, I think is more common. So imagine that if you have a flow that processes an order and that runs every 15 or 30 minutes. Yeah. And the first run, the flow errors of, let’s say on order number one, two, three. And at the end of the first round, you have one error for order one, two, three, and before you get the chance to fix the error, the flow runs again. And at the end of the second 15 minutes, you have the duplicate errors, basically the second error for order, one, two, three. So, as you imagine, within an hour, you have four errors for the same record. Three of them are duplicates. With auto-resolve, what’s going to happen is that it’s going to resolve three of them and you’ll only need to review one open error for that order, one, two, three. So I’m going to demonstrate that this is the first run, and then when it runs the second time, the kind of errors are not going to increase. It’s going to stay the same because, in these demonstrations, I use the same set of data and with the same conditions that force the errors to happen. So it produces all the errors now. So this run produces 30 errors, so these are all the 30 errors. I’m going to run it one more time. Pay attentions that now, without the auto-resolve functions, my count will be 69 and so forth. Right? But with these auto-resolve functions, these 30 errors will be resolved as the system produced the errors. And then the system recognizes it’s the same unique record, which is identified by that ID that’s risky. So let’s take a look at what happens to those 11 new errors. So it’s still being processed. 30 of them are produced in the second run. So you’ll see that there are 30 new errors, and the duplicate errors from the previous– on the first run, they all were auto resolved, and as a result, I have these 30 errors. Even though I run this every 15 minutes, the number of errors that I’ll see will still be 30 because of the auto-resolve functionality. The last feature is the new error API. So with the EM 2.0, you now have a set of API that you can use to programmatically get all the open errors, then take action such as retry an error or resolve the errors. You will need to use the full access scope, so you go API token to invoke this API successfully. Here’s an example of how to formulate these APIs. When you look at the error tables, if you look at URL up here, next to the path flow builder is actually the flow ID, and at the end is the import ID or the export ID, depending on the step that you’re looking at. With these two informations, you can build the API to make a get-call post and put calls to the errors in this step, so in this example, in this import step. Right? So when you get a get call, it returns the errors. If you recognize, this is the error information from the error field: so the message, the code, the source. Again, it does not give you the payload data. There are two pieces of information here that are needed to do the actions, retry – so you have to retry directly – and the error ID. If you go into automate retrying based on certain informations, you will need to extract the retry data key, and when you make a post-call, provide that in a body request, and if you want to automatically resolve some of them based on certain conditions, I don’t know, in a message, for example, you need to have the error ID and make sure you do a put-call with forward/ resolved and provide that error ID in the body request and the system will automatically or programmatically resolve the error for you. So now I’m going to hand it over to Praveen, who will then go over specific changes that apply to integration applications. Thank you, Fali. Hello, everyone, this is Praveen. I am one of the product managers here in the Celigo for the prebuilt integration team, and I’ve been part of Celigo for the last five years and I’ve been handling multiple integration apps in the previous segment. I’m on the banking and e-commerce side. So I’ll be talking a little bit about the specific changes that we have done as part of our integration app’s functionality that is going to help users who will be migrating to Error Management 2.0. So to start with, there are a few new flows that you would be seeing as part of the integration app going forward, precisely added to add a little better functionality for the users that are migrating to Error Management 2.0. So these new flows are flows that are going to add a better visibility for the users, starting to show the errors on the flow section itself as Fali demonstrated for the– not platform flows, it would be similar to what you see for the integration process. The important things to note here is these flows cannot be triggered on schedule by the users. And the reason for that is being these flows are mostly solving the purpose which was used to do in the backend all these days. And now we have brought these flows into the UI to make sure that the users have the better visibility, as I mentioned. And also another aspect for this is that we cannot edit the mappings and settings as well. There’s no visibility as you can see here in the screenshot. The second flow is the additional flow that we have started to show on the UI. And as you can see, there’s no mapping icon which is not available there. And also the run button that you see there is completely disabled. So these flows are mostly the ones that are either triggered by an action performed on a different flow or something that we run in the backend whenever there is a unique requirement that’s necessary for a specific icon and user. Next slide, please. And coming to the next feature that is added to the integration apps for Error Management 2.0, there’s a new all-store view which is available for all the multistore integration apps that we have. A lot of the e-commerce and the banking applications as you all know are multi store where you can configure multiple stores and we can link the multiple stores to the accounts. And now the feasibility that we have provided for the users is to have a holistic view of all the flows belonging to a specific category under one page, which will give you a better viewability in terms of the number of errors that you are seeing on the each category. As you can see, if you have selected– here, as you can see in the example, if you have selected all eBay accounts as the option and consider selecting the order category under the Flow section towards the left, you will be seeing all the flows that belong to order category for the multiple stores you have in the Integration App. As you can see, I have two stores available here, and the number of flows that you see here are four. Two belong to one icon, and the other two belong to a different store. And the better advantage I was talking about is you can see errors in case if there are any in the left panel in the holistic level where you can modify the total number of errors that you have received for a specific category on any given time. And also, once you drill down a little bit, you can also see the differentiation of those errors based on each store. As you can see here in the Flow section, there’s one error item for the eBay US1 store and the other is for the eBay US2 store. So this will give you a better reliability and advantage in terms of understanding how these errors are being seen in your stores so that you can focus more on the store that you actually are seeing more errors in. Next pitch. And another important change that you would start noticing once you migrate to Error Management 2.0 is the dashboard. And as fully demonstrated, there will be a graphic representation of how your flows have performed in any specific time period that you select. And the only change that you’ll see here for the Integration App most precisely is the category that you can select. As I was talking about category view in the last slide, this is also similar to what we have here. Instead of you looking at all the available categories and the flows that are on the integration level, in case if you have multi stores, we would just pick– we are actually giving you feasibility to select a category and filter the flows that are available only in that category. So this would be very advantageous for the customers with multiple stores configured where you don’t have to scroll through a lot of available flows that are there in the Integration App. And instead, filter them using the specific category and select the flows that you would want to see, only the flows that you would want to see. And with that, I think these are the major changes that we have added as part of the Integration Apps. And along with these changes, like I initially mentioned, every feature that Philip talked about is also applicable to the Integration App users. So there’s a lot of advantages as you look at it. Thank you, Praveen. So let’s talk about how you go about migrating your IO account to the new error management. The new error management framework is part of your existing license, so there’s no additional cost from the license standpoint to uptake these functionalities. This new framework is being rolled out as we speak as an opt-in process. What it means that if you want to do it today, you can navigate to our knowledge base website, and I’ll show you how to go about doing that. And then at some point, towards the end of Q2, we plan to deprecate the current error functionality, and we will start moving or turning it on for the accounts for the customers. So the next item is, how do I migrate? It’s really a simple self-service migration function. You will have to go to the knowledge base and click the Get Started button and one thing I want to point out, you must use the account owner ID to access and complete the migrations. So what happens after you migrate is that all users share the account will be on the new Aromasin framework. So it’s not like you’re upgrading per user. The account owner is going to upgrade per account, and when that migration happens, we convert the error records from the old framework to the new one. And as the process of the migrations, we are also going to resolve the duplicate aerostat, be fine, and what happens, you may end up with a lower count of open errors, and because of the whole migration process that’s usually heavy on the back end, once you migrate to the new management, you cannot say like, “Oh, I’m going to go back to the old era management.” You cannot revert to the current error management feature. So let me show you what it entails too. So this is the knowledge base, and in the knowledge base, there’s a video on how to get started. So I’ll play a little bit, so there are two ways to get to the migration page. The first one is if you receive the product announcement news about the new era management and if you’re the account owner, you can click the get started button, which will then take you to the migration page. The second way will be to navigate to the knowledge base article, click the get started button, then you have to log in using your account owner access, and only then you’ll see this page. You’ll know that you are the account owner when you hover over the profile, it says you’re the account owner. I am going to play and see what happens when you click get started and then click that button. So I’m showing the path to get to the knowledge base. So on our website go to the resources and knowledge base. So that’s the get started button. Here I log in using my email account owner ID. Again, here it’s just to let you know that you are in the process of upgrading. Once you upgrade, you cannot switch back and also to remind that we may resolve some errors that we find as duplicates and therefore your error count’s going to be, or could be lower. And that’s it, that’s the whole experience of migrating your accounts to the new EM 2.0. So with that, I’m passing it back to you, Christine. Great, thank you both Viliandi and Praveen, we have some questions. We’re going to do a Q&A and any question that is not answered during the Q&A, we will follow up with you to make sure your questions are all answered. So with that, the first question we have is, will I need to set my slow air management notifications when my account is migrated to EM 2.0? Yeah, that’s that’s a great question. So when you migrate from the current error management, you go through that process of clicking the Get Started button, we do not change any of your existing configurations. Nothing will change. So your notification setup will remain as it is. You just receive the new email message format. Great. Thank you. And the next question is in the new error management, can I see error records that are more than 30 days old? Yeah. So going to go into the system. So first, I want to mention that there are two types of errors here. There’s open errors and resolved errors. So just like what you have in the current error management, the open errors is available for 30 days from the time the error is created. So that is also the window for you to retry the open error because, again, we only keep or retain the record’s detail for 30 days. Now, once you resolve the open error, the resolve error is again available for 30 days. So the resolve error will live for another 30 days. So then you’ll have your open errors for 30 days. And if you resolve it, then the resolve errors will live for another 30 days. So, again, the maximum that you can think about is 60 days for that life cycle of the errors. But the retrying window is only available within the 30 days from the time the error was created. Okay, great. Thank you. We have a question, what is trace key? The trace key represents a unique identifier of a record. So in my example here is pretty simplistic. So each record has an ID. And the platform is going to populate what it identifies as a unique ID for that record, right. It goes by stringed ID, some unique identifier that we’ve built the logic for. So if it were a Netsuite sales order, that always has an internal ID. Or it can be based on a sales order number. And this ID is what identifies as a unique record and what is going to be the key for the system to do the auto resolved functionality. Although we populate or we auto-populate this trace key functionality, when you upgrade, if you don’t like it – you want to change it – you can use the API to update its trace key value. And in the next release, I believe, in mid-May, we are actually opening it up so that on the UI for the each– on UI on the export step, you can enter the trace key value to override the default definitions that we provided. Thank you, Sulay. Next question is can I search errors based on error payload detail? Yeah. So the search functionality is not based on the– so by payload is the actual record details. It is actually what you can search is based on information that you see in this arrowfield here, including the trace key. So if the trace key– if you redefine your trace key to include the first name or the last name of the data, then you can search by that name. Let me see if I can find an example where I set it up. I did not. But let’s say you want to search by this error ID just to show the search functionality, then it will return you that one specific record. Okay. So I’m just going to open up for a couple more questions, and then we will be doing a wrap-up. Next question, how many error records can a step hold? Great. So the step can hold– at most, it will have the last or the most recent 20,000 error records. Again, it also observes that 30 days rules that I talk about earlier, right. So if I say within a run that you produce 25,000 errors, for example, then the error table here will show you only the last, or the most recent 20,000 records. Okay. We’re going to take one last question. I just want to remind everybody you’ve asked really great questions, and we will be following up to answer all of your questions directly. And the last question before we move to the next slide is, is the Shopify IA ready? So I think that would go to Praveen. Yes. So, yes, the Shopify IA is ready. We have stated the Shopify IA. And the Amazon IA would be available a little later. But we have made sure all the IAs that we have Support Error Management 2.0 right now. And, yeah, not just Shopify IA, but all the other IAs are also ready to be integrated to the error management 2.0. Great. Thank you, Praveen. So just to recap, all the IA are ready to be migrated. So I’d like to highlight a few webinars that are going to be coming up soon. You can always go to our website, to resources webinars, and this is just a list of the next few webinars coming up. So we’d like to share that out with everybody. And then the last slide is a thank you. Thank you for taking your time and joining us today. And we look forward to reaching out to each of you and answering your questions. Thank you, Praveen and Sulay for a great educational webinar. Thank you all. Thanks, everyone.