Lightning Talk 8 – Never Drop Never Fail

Video Transcript

Hi, I’m Anne Ramey, and I’m here to talk about never drop never fail. You heard John mentioned this earlier today. So I want to talk just briefly first about, what are we talking about when we talk about never drop never fail?

What are we even trying to address. So what we’re trying to address is a challenge that all of our customers were trying to address when they brought us in. They’re trying to address the fact that they have processes that just weren’t working effectively.

Right, things were getting forgotten, things were getting dropped steps were getting missed. That’s generally, one of the primary reasons we get brought in, things aren’t talked, people aren’t talking to each other systems aren’t talking to each other things are stalled, things are failing. That’s why we come in.

So we want to make sure that when we do go in, we solve these problems. We don’t end up with stalled workflows, we address all of the single points of failures. We don’t want to make, we don’t want to set up a single approver and have things sit there unaddressed, we want to address the fact that even in our task application, if something fails, you then are dependent on a task admin to intervene in the process.

That’s a single point of failure, you’ve got your task administration team addressing all of the errors for every process in your system. So you’ve now got a single point of failure, trying to deal with all of your processes across every use, you have all of your integrations. So what do we do about this, I’m gonna address this in two parts never drop and never fail.

So first talking about never drop. What does that mean? Never drop. It addresses the processes, making sure steps don’t get missed things don’t get forgotten all that. And we can very easily do this by leveraging routines to make sure that all of the pieces of our processes have backups, and escalations, reminders, alternates real quick, a routine in our kinetic task application is a reusable tree, essentially, that gets dropped into other trees.

So if you have a routine, that’s just a reusable portion of code that you’re going to use in your other coding. So you want to build your escalations in, you want to build alternates reminders, you want to remove the error handling from the task admins, and give it to the appropriate people.

So never drop, you have your escalation of first approvals, right? You have reminding your customers to submit forgotten items, expiring non submitted items, cleaning up your system, handling alternate approvers. That’s often something that folks don’t think about first time round, right?

Okay, well, we’re gonna assign, we note the approvals go to the person’s manager, well, that manager is on vacation for two weeks. Now what? Well, you can have escalations, it goes up to their manager, you can have alternate approvers, you can have them set up alternates for themselves when they leave.

There’s a number of ways to address these. But these are important things that when you’re initially thinking about your processes, it’s really helpful to really think about how do we make sure these processes don’t drop. And this is something that we’ve done when we’ve built CONOPS. And actually, when we have folks get into their builder, the task builder and CONOPS, if people need to go that far, is we’ve built all these sub routines for them already.

So when they’re pulling in an approval, that approval has never dropped things built into it. So we have all of that workflow them for they’re already set that backwards.

So one example of this is hearsay, an example of an approval where it’s also checking to see if the alternates exist, and all of the alternates get an approval at the same time.

If the approver gets their approval, and then this routine would be dropped in every time you have an individual approver. So you’re just pulling over individual approval. But within that, is this logic.

So you don’t ever have to think about this logic, once you’ve done it that first time. But it’s always there protecting you in a never dropped scenario. And then we get into never fail.

So this is kind of the other half, they removing programmatic single points of failure, that removing the fact that that task admin becomes a single point of failure. And this is where you get into changing your error process and your data handling.

Because even if we made a process that is absolutely perfect from you know, this is exactly what the process is supposed to do. The process is perfect.

If somebody puts in values that are invalid, and wants to update the access for user, Joe, at kinetic data.com, if we get into the part of the process where we’re trying to find Joe and he doesn’t exist, we’re going to hit a problem. And that’s not a task problem, the process is fine, the data is bad, right?

So protecting yourself from that is important. And that’s really where this becomes very strong. And that is we allow the task handlers to return an error instead of raising an error. And that means that we can take that error, and we can do with it what we need to to get that error properly processed.

So if we know there’s a chance, for example, when we’re retrieving a team that that team might not yet exist, then we can catch that error and assign handling of that error to the person who manages teams, or the group, the team that handles administration of the system, instead of the person who is managing the task application. Right?

Your application managers are rarely your data managers. So here, we’ve got that process, you’re doing a team retrieve, you have one branch saying, Okay, well, I’ve got an error, I’m going here, I’ve got no error, I’m gonna just, I’m going to take a different path entirely. So but what happens on that error path?

What can we do there? Well, this is what we do in CONOPS, is that we assign that error out to the appropriate place. And say, Okay, well, here’s your error, here’s the run ID, here is the error message. And then you can go address that you can fix the data problem. And then you can retry the task right there. And this is in our queue application.

So this is the same place everybody else would be working their, their tasks. And so that this is what the whole tree would look like, is we’ve got our retrieve team. And then it drops into that error process, which really is the same error process for all errors, right? It’s just a matter of who gets it, who deals with it, you know, who were expecting to process that. And then we retry this whole thing over again.

So what we’re doing when we’re retrieving a team is actually this whole process. So that it can retry as many times as necessary, until it’s successful. And then we get the results of this process back. So we’ve we’ve got ourselves a kind of a cushion here. We’re protecting ourselves from failure. So we’re making sure that our errors are handled by the appropriate parties, and our workflows don’t help because of that. And we can also optionally expose this process to our customers.

We can make submission activity records and expose this to the customer if we desire. So perhaps we’re dealing with bad data.

We need to create the team we need to update somebody’s manager before a process can go forward. Anything like that we’ve escalated and approval something, we can expose these steps to the customer. So the customer isn’t sitting there wondering where their request is.

Because even if you’re dealing with an error, it’s going to take a little bit longer than the original process probably should have. So that’s a little bit about never drop never fail. If you have interest in any more I know John loves to talk about it. I am perfectly happy to talk about it.

And James is also pretty thrilled about it. So catch one of us and we’d be happy to talk to you about how to make this happen in your environment. Thank you.