Data Connectors for Procedures

Okay. So at this point, we've got a solid understanding of how procedures work and how to map them out. Now we need to talk about the data that powers them. So when we have an external API and we want Fin to be able to talk to it, a data connector is what we use. They're how we give Fin superpowers, like the ability to pull in external data, check statuses, and actually take action. Now you might have some existing API endpoints that you want Fin to be able to use, or you might be scoping out ones that you want to build. However, there's one thing that often happens when people connect Fin to external systems is that they tend to take all their data and do this. Oh, what the hell? What am I supposed to do with this? Now the two main issues here are, one, people just give Finn too much data, way more than it actually needs. And two, they hand Fin messy or confusing data and expect it to just figure things out. Now these issues can increase latency and make your procedures brittle and unreliable, which overall is gonna contribute to a poor end user experience. And at the end of the day, it doesn't really matter how well you design your procedure if the data that you're feeding it is a mess. But the good news is even if you have messy and unstructured data coming in, you can clean it up inside the data connector. So when it gets passed on, it's clear and easy for Fin to understand. Before we take a look, let's bring this to life with an example. Let's pretend that I'm running a physiotherapy clinic, and I'm creating a procedure to help me manage my client bookings. And if we jump into the product, you can see that I've already created a data connector for this. And you can see that I've added my API endpoint here. And if I click test response and live response, I can see exactly what information is available. Now, as we look at this response, a couple of things stand out to me. First, Fin probably doesn't need all of this data to do the job. And second, it looks like this API was created a couple of years ago, and it was only ever supposed to be for internal use. So some of the names of the data points are a bit outdated, they might not make sense in a customer facing conversation. But that's okay. We can use data transformation to clean a lot of this up. If I click into the data transformation tab, you can see right now it's set to full access, which means Finn has access to everything that the API endpoint returns. All of it, internal codes, the clinical notes, marketing data, everything. So let's change that. The first option here is to manually restrict. I can just go through the list and turn off things that Fin doesn't need. And I can also relabel fields too. For example, renaming this one to gold monthly plan, which is a lot more user friendly. And if we want even more flexibility, I can make these changes by using code two. You'll find that option underneath the manual restrict button. So here we can use code to reshape the data, convert formats, or add logic. Think of this like a safe editing step between your API and Fin. And look, even if you're not technical, you can use an LLM to help you write the necessary code. Okay. Let's take a closer look at some of the ways I can transform this data to make it easier for Fin to use. So right now, the field for next appointment and next treatment session look like this. This is ISO date time format, which is useful for machines, but it isn't really how a human talks. And if Finn reads this out directly, it's not gonna be easy for our customers to understand. So let's transform these into something clean and readable. Let me paste in a few lines of code here to transform the format. And if we hit test again, instead of those long timestamps, the date and time is much easier to read. Okay. Let's look at another thing we could fix. If we take a look at some of these values, you can see that they aren't very specific or clear, and that's because they were made a while ago and they were only ever intended to be used internally. So they're not gonna mean anything to a customer. Let's transform these terms into something that makes more sense. So let me paste in a couple of more lines of code here. And if we hit test again, instead of those internal codes, we get positive progress and stable no change. Terms written in plain English, which are gonna be so much easier for Finn to use in a conversation. Okay. One last transformation that can be useful is if the response contains a lot of sensitive data. Right now, you can see it contains things like internal IDs, clinical notes, payment references, and system metadata. These are things we definitely don't want Fin sharing, so let's strip all of this out. Let me paste in a few lines of code here. And if we hit test again, all of our internal and sensitive data is gone. We're left with just the information that's actually useful in the conversation. Okay. So if you think back to what we started with, we had messy raw data with timestamps, internal codes, and extra fields. We've now shaped that into something that's clean, clear, and easy to understand. So when we hand this to Fin. Thank you! It's so well organized. There's no ambiguity, no extra processing, and no guesswork. Fin is able to use the data straight away. Now in our next lesson, we're gonna show you how to use data connectors in a procedure and how to design clear, reliable flows that Fin can follow.