Find the PPT Here: Achieving Real-Time Data Quality With Custom Reltio UI PDF
Reltio helps organizations to connect and unify all their core data from multiple sources into a single source of trusted information.
Reltio supports a standard user interface within the Reltio UI which allows navigating and authoring data. Although the standard Reltio UI provides that capability very well, some of the integration use cases of the Reltio platform may require customization beyond its current capabilities. Some examples include a custom user experience and real-time data quality at the time of entry.
In this community show we will show you how to implement a custom Reltio UI using React which has built in data quality at the time of entry. The data quality checks we will demonstrate are:
Address verification
Phone verification
Email verification
Duplicates detection
Data validation
Find the transcript here:
Chris: All right. It is time to go ahead and get started on another Reltio community show. I'm excited. Today I've been talking to ULPIA TECH for a little while now to do this show. And this call is called, or the show is called achieving real time data quality with the custom Reltio UI.
Chris: So Michael Petrov, he's the head of software engineering at ULPIA TECH. He's been doing this for a long time. Welcome, Michael. How are you?
Mihail: Welcome, Chris. I am perfect.
Chris: Beautiful. Much
Mihail: appreciated. Yeah, it's going to be fun.
Chris: It's going to be fun. And I see you have the hat on. So that's [00:12:00] really awesome. Yes, that's great.
Sophia: Exactly.
Chris: All right. The rules of the show is normal. So please keep yourself on mute. Ask all questions in the chat or please take yourself off of mute and ask. We do have some folks here that from ULPIA TECH or. Ulpia, sorry, that can help answer some of those questions. It is going to be recorded So I’ll be sending this out in the next day or so for this group Lastly, or not lastly, but we do have a few shows coming up today's show.
Chris: And as a matter of fact, we have another show coming up this week, discovering Reltio's AI ML powered fern for data unification, then we have a nut and that one's kind of more of a business focused oriented and then we have another show unlocking entity resolution with AI, how fern is revelation.
Chris: revolutionizing data matching a little bit more technical, but that one's going to be a lot of fun. And then we have a new [00:13:00] product called Reltio customer 360 data products. So powering AI driven data unification for enhanced CX. So that's a lot of stuff around AI. So we're really excited to show that and share that out.
Chris: And then lastly. If you're in life sciences, we do have an event coming up May 9th. That's a half day. So a lot of great speakers. We have several customers that are going to do like a fireside chat. We have Manish Sud, our CEO founder that will be doing the keynote. And then we'll also do a deep dive into the life sciences product roadmap.
Chris: All right. It looks like. Michael, it's your turn. I'm going to hand it over to you. Okay. Thanks, Chris. Welcome.
Mihail: Can you share my screen?
Chris: Not yet. There we go.
Mihail: Perfect.
Mihail: Just to be absolutely [00:14:00] sure. What is visible at the
Chris: moment? I see the main slides achieving real time data quality. Oh, yeah. Your face and everything.
Mihail: Just a second to share the entire screen.
Mihail: Absolutely. Sure. Okay. My windows
Mihail: portion of the screen, oops, and we are here. Okay. Yep. All right. There you go. I assume everything is visible. It is.
Chris: You're good. Thank you.
Mihail: Yeah. Achieving. Yeah. This is the main slide needs to be visible at the moment. Okay. So thank you very much, Chris, for the presentation. I am extremely glad to be on this community [00:15:00] show and to present a very valid topic related to real time data quality. A topic which is absolutely detrimental for every single system that we are using on a daily basis. First, a word about myself.
Mihail: My name is Mikhail Petrov or Michael, if you wish shortly, I'm currently a PhD in computer science, extremely interested in the topic of development and business integration. And currently I'm holding the position of head of front end development. On the screen, you can see my social media addresses.
Mihail: So if you wish to chat a little bit more about this topic, you can go and find me after this presentation. In this show, I am with my colleagues from OOPIA. I am not [00:16:00] alone. We are always together during those events. I'm going to tell you a few words about our team. We are a team of data and analytics people.
Mihail: We are a data analytics company. And we have a lot of experience dealing with integration of services related not only to master data management, but with data in general. So some of our customers are located in Europe and United States, and we are dealing with all sorts of different industries like retail tailing.
Mihail: Energy, pharmaceutical, et cetera. We're specializing in data analytics services, route partner of Reltio, and we're doing a lot of development with some of the classic programming languages. Last but [00:17:00] not least on the screen, you can see some pretty interesting addresses. For example, our blog, blogopia.
Mihail: tech can serve you with a lot of recipes, tips and tricks and solutions to tough problems that we faced on a daily basis. We've also provide you with a link to one of our repositories, MDM Utilities, master data Reltio Metadata Security Management, which is extremely interesting tool for management of security policies.
Mihail: So if you're interested in those topics Chris is going to provide you with the links in the page of this particular community show. Thank you. And I'm going to be extremely interested if you follow us after this show to share some of your ideas. Let's dive in directly in [00:18:00] this topic. The agenda for this show is going to be split in a very balanced mix between business and development topics.
Mihail: First, I'm going to introduce you the business case. And the problem that we faced when we've dealt with real time data quality, some of our problems some of our customers faced those problems on a daily basis. And we're going to share with you some of the possible solutions and how we solve them.
Mihail: Their issues for this particular talk, I've prepared a demo application, which is inspired by a real application that we've introduced for our customer. And last but not least for the people who are interested in the whole topic of development, engineering, and technical talk. [00:19:00] I am going to go through this application in a little bit more in depth manner.
Mihail: So I'm going to talk about source code. Okay. First main question is what is the business case? Let's explore what is the problem with the real data quality and why we need to consider this on a first place. That we have that medical clinic for this particular scenario, this that medical clinic is using a bunch of systems, which are acting as a source for different data processes in order to run the business.
Mihail: We can have. SAP HANA, Microsoft Dynamics, or Salesforce doing their stuff behind the scene. Of course, at some point, this [00:20:00] business is going to introduce Reltio as a master data management system in order to ensure that all the customer information Is accurate and consistent across every single system across Salesforce, Dynamics, and HANA.
Mihail: And from this perspective, everything is fine and dandy. We don't have any problem because Railtel is doing the job perfectly behind the scene, and everything is going to be extremely well done. But there is always a but. What is the problem with this particular set up? In the ideal world where every single operator, which is a member of different department interested in inputting, updating or working with data.
Mihail: Of all of those different systems, everything is going to be perfectly low [00:21:00] oriented and real Q is going to apply all the necessary data quality rules of the survivorship rules in order to introduce the golden record. And the world is going to be a peace and fine place. But the problem is the operators always make mistakes.
Mihail: Some of the mistakes are tiny, the other are going to be huge. And those mistakes usually result in Some data quality issues they can arrange from incomplete profiles of the customers or related objects, name mismatch, invalid phone numbers or email addresses that looks valid but are not recognizable as valid.
Mihail: So when we face this operation on a daily basis, What is the practical solution? We are usually [00:22:00] introducing the data steward in this mix. And the data steward is supposed to fix this issue. But the whole shtick that he needs to go, all the hoops that he needs to jump, usually involved in finding the already flagged data issue by RLQ, opening a case for something in the past.
Mihail: Invalid email, incomplete profile, et cetera, to the operator who is actually involved in this particular problem. And from this point on, this is supposed to be fixed somewhere in the future. Of course, if we have a busy system, this is going to be an use case, which is going to be repeated numerous time on a daily basis.
Mihail: So the main problem that we've introduced. Is that we need to require the data steward to [00:23:00] always be on on alert, always observing the issues and always trying to communicate back and forth with the different operators. But this. As you can imagine, is expensive, time consuming, and most important, prone to repeatable error.
Mihail: So it can happen again and again. So how to potentially fix this problem? We can introduce a possible solution, but not very good. This is an intuitive solution, but at the end of the day. Not something that we need to consider in the long run. What is the possible solution? Every single time when we create a new record inside those sort systems, we can apply.
Mihail: A different data quality rule set that are related to the fields that we need to check in the [00:24:00] long run. But the problem with this scenario is that every single system have their own specific set of rules, their own specific specs, and from system to system, we need to have in mind different APIs, different UI and different processes.
Mihail: We are going to communicate with Reltio in terms of possible data quality rule set that is actually undergone after a particular new record involvement. But the problem with this, yeah, it's better. Yeah, it's workable. We have initial data quality. But it's hard to scale. So every single time when we introduce a new source system for relative to work, we need to apply the same kind of initial data quality to the other system.[00:25:00]
Mihail: And think about this. If at some point we need to introduce a new rule, we need to go system by system in order to actually check all of the boxes if every single system have the same data quality rules. This is problematic, of course, because it doesn't scale, it's expensive in a long run. So how did we solve this?
Mihail: This is the issue that majority of our customer faced on a daily basis. So we've introduced the following solution first and foremost, those operators that are busy with inserting new records are going to Completely lose their ability to create new records. We are going to cut them from this possibility.
Mihail: So it's not possible for direct access to the [00:26:00] system no matter from which system, Salesforce, dynamic or HANA, this is going to be completely cut. So when we cut their opportunity to implement new records, to insert new records, how they are going to actually. Add new information to the customer. This is the custom component inside this lecture.
Mihail: The custom UI. So the custom UI that we've introduced is going to be a custom application form for managing all the record creation. This custom form is going to have the looking field appropriate for this specific business. So we've talked about a vet. Veterinarian clinic. So we're going to create something that is applicable for their business needs.
Mihail: In this case, this vet manager. This particular application is going to integrate A lot [00:27:00] of different validations, for example, validation for customer name, validation for a specific document that this customer need, validation for phone, email. So not only basic validation rules, but some of them are specific for this particular use case.
Mihail: Finally, for example, when you need to actually go in this direction, I need to add new record. We're going to introduce this new button inside the source system that needs to provide you with the ability to actually record something. And when you click on the new button, you're going to be redirected.
Mihail: directly to the to the form in order to actually input your data. So the whole flow is going to look like [00:28:00] this. We have the source system. In this case, Salesforce. When we need to create new record, we're going our customer. In this case, the operator is going to be redirected to the custom form. The custom form is going to have a pre built quality set.
Mihail: With every single data quality rule that we need to impose the email, phone, et cetera, the phone is going to be responsible of creation of the end rail to object that needs to be sent. To the real Q system. So in this case, every single time when we introduce a new system source system, no matter if it's Salesforce dynamics, Hannah, et cetera, the only thing that we are going to be concerned is the data.
Mihail: So the whole data is going to be validated in [00:29:00] this particular custom form. So the scaling issue is solved the data quality issue. It's so this application is easy to deploy and scale, and it's also extremely fast, cheap, and very accessible in the long run. So the initial cost is. Related to develop, we need to develop our form initially, but in a long run, we need, we are going to save a lot of time in this operation, trying to achieve data quality for every single system.
Mihail: And of course, The most important value that we're receiving is the prevention of possible validation mistakes and repeatable validation mistake. If we make a little bit of comparison between the previous scenario and this scenario. We're not only removing the [00:30:00] cost, but we are also preventing every single repeatable error that a particular particular operator can introduce because it it does not have enough knowledge in working with this particular system.
Mihail: One more thing that I wish to share with you, which is also a extension of this particular scenario is how to make this form into a customer portal. So if we get this customer form, which is just a way to validate new information, Or way to validate existing information. What about creating a whole customer portal with a bunch of validation related to multiple objects?
Mihail: For example, if I get this scenario that we have a veterinary clinic that have a different kind of [00:31:00] data, why not? Creating a whole custom application that is going to show information about the recent patients, their owner, the medical records, et cetera. So by introducing this custom component in our rail to scenario, we not only managed to make the validation for a particular customer, but we can introduce validation for all sorts of different processes, which is.
Mihail: Absolutely. Amazing. In the long run. Okay. So, talk, talk is cheap. I'm going to show you how this is working. In a little bit more practical manner before diving a little bit deeper into the technical aspect. So the demo application that I'm going to show you is called vet manager. And this application completely related to customer validation.
Mihail: This application [00:32:00] relies on the idea that in our real tool, we have a different profile of customers, which are pet owners. Pets and medical records. So this information is organized in hierarchical manner. So every single customer, every single pet owner have some kind of pet, which is a patient in the clinic.
Mihail: And every single patient that have some kind of medical record, which needs to be checked. To be addressed from the vet clinic stuff. Okay, so let's dive into the demo. I have this form, which as I already stated is the form to which I'm redirected. Every single time when I wish to make some kind of change or some kind of new record creation [00:33:00] operation, in order to access this form, I need to provide credentials that are related to the source system or
Mihail: So I'm going to dive. In this particular form using my credential, Michael Petrov and the password. So in this case, the form is very simple. I can search for customer or I can search for patient. So I have previously integrated some. Patient, some persons in this particular system. I have my trustee test around you environment, and I can go in one of two directions, create new record or find the existing record and try to actually update.
Mihail: So if I try to find Nadja Rico or John Smith or Helena Park, I can go in this direction. For example [00:34:00] let's type Helena and the system is going to provide me with the information about this particular user. So yeah, I can see information about Helena. I can see her document ID, a phone number and email address.
Mihail: But the majority of mistakes that happened are actually happening during the creation of new user. So if I wish to go in the direction to, for example, create new customer, I'm going to add Peter Norton, for example, and Peter Norton is not in the system at the moment. So the customer the custom form is going to check against.
Mihail: The real Q database. That this particular user is not integrated at the moment, so let's add this new user. I'm getting the first name and the last [00:35:00] name directly from the search form. The system is going to generate the appropriate document ID and the only operation that is left for me as operator is to add the phone and the email in this case.
Mihail: We have validation on several different aspects. For example, if I go in this direction, change this username to something weird, something awkward, like Peter1 the system is going to provide me with information, no, something just wrong, definitely this name is not valid according to the rules that I have.
Mihail: The document ID is not editable because we implemented the flow of no touchability. Instead, the system is going to consult with the service responsible for providing the necessary document ID, and we're going to receive this. [00:36:00] So it's up to me as an operator to only input the phone and the email.
Mihail: So I am very destructible person. So I'm not going to to input any particular phone. No, this phone is not valid. It's required by the system. I need to input it. If I input some jibber jabber, I'm going to receive the same result. If I input a valid phone. This phone is going to be validated and I'm going to receive a green mark of approval with the email.
Mihail: It's a little bit more interesting because if I provide email with fight pattern, for example, nail and the valid domain. I'm going to receive a red cross of debt. Why? Because this looks like a valid email, but actually it's not recorded in any particular service [00:37:00] provider. So this custom form is not going to be reliable in terms of, yeah, this looks very nice.
Mihail: This looks familiar. This is a pattern that I can recognize. But it's going to check against an actual service that is responsible for validating if those phones or those email addresses actually exist. So I need to add an existing email. So I'm going to add my email, my OPA email. It's valid, I hope, and yeah, it's actually valid.
Mihail: In the next part, when I dive a little bit deeper into the technical aspect, I'm going to show you how this is communicating behind the scene with actually the system. So when I go in terms of create new pet donor. When I actually put this form into the good [00:38:00] use, I'm going to receive a message. Yep, customer created successfully.
Mihail: The whole communication flow, it's a little bit slower at the moment, but after a while, I'm going to receive my new customer directly in this form. Let's try my work. Maybe I can see the result right away. Or maybe we can wait a little bit to see okay. At some point, yep. Peter Norton is here and Peter Norton have my email addresses.
Mihail: Of course the whole process is done because we are creating a very nice match between the real tube capabilities and And the custom validation that the developers and the business owner required for this particular flow input. [00:39:00] Okay. So the question is how to build this solution. I've show it.
Mihail: Let's talk technical stuff. If you wish to follow along in terms of source code, you can I'm going to direct you to our GitHub repository, github. com. ULPIA TECH. Inside this repository, you're going to find not only the source code of this portal, Community Show React. js portal and Community Show Angular portal, but you can also find additional open source projects that we've created in the past.
Mihail: I'm saying this for all the tech geeks If you wish to understand a little bit more about the process, okay. So how to build this board and [00:40:00]
Sophia: any
Mihail: custom customer related portal. First and foremost, we need some kind of front end technologies. Of course, we can always bet on the trusty HTML5, but we can decorate this with some of the most popular front end frameworks at the moment, Angular, React, or Vue.
Mihail: It doesn't matter. It works for every single type of scenario. In this case, I'm using React, but also Angular in order to demonstrate you the differences. For the validation service. This is a little bit more interesting at the moment for this particular demo, we are partnering with the locate GBG, which is actually the services used behind the scene by rail tube.
Mihail: So the whole validation stick is happening because this application [00:41:00] is integrated as a third party validation service. And this validation service is specializing in binding. Information about actual data records. So not only patterns. Not only patterns for emails, not only patterns for phones, but also if they're registered somewhere.
Mihail: Why we chose to locate for this particular demonstration and in our businesses in general, because around you actually trust walking. Let's introduce a scenario when the validation are absolutely consistent, not only in Reltio, but in our custom form. So this is absolutely applicable in a long run.
Mihail: So how the. Single page application, our customer form is communicating with the Reltio in order to [00:42:00] provide the whole information set. So we are using the API provided by Reltio. Reltio is, generally speaking, API first, API centered platform. It provides amazingly documented API. And it's a backend as a service in this particular scenario, so we can send information back and forth is if something is wrong or if something is not complying with the initial data quality rule set from the single page application.
Mihail: In this case, the customer form and the master data management system. From this point on, the master data management system is going to be responsible to upstream the necessary data changes for all of the systems that are currently integrated as a source system. Reltio [00:43:00] is acting as a single source of true.
Mihail: For the golden record, but our single page application, the customer validation form is acting as just another gateway for data quality rules. In this case, we're enhancing the capabilities of Reltio because from this point on, Reltio can decide to add additional validation, which are related to more specific.
Mihail: crosswalk scenarios. Okay, from this point on, we need to talk about what kind of validation we can implement in our custom form. So the three different groups that we actually flagged are regular expression validations, Which are just basic buttons. This is the most popular type of validation that you can find on the internet.
Mihail: [00:44:00] You're recognizing something like name, like email, like phone, like country code. And you're saying, yeah, this looks familiar. Maybe it's right. Maybe it's not right. The most interesting part is the service validation, which is extremely complex check. We are going to check not only the pattern, but also if this particular record is actually provided by service level provider.
Mihail: In this case, the locate service, and we can check addresses. We can check advanced document IDs, phone numbers, and email addresses. And we can also receive a more complex data output. For example, if this email is inside a wishing list, if this. Is this number phone number is part of some kind of shady scheme.
Mihail: So in this case, we are going to know more about our customers. And [00:45:00] last but not least, it's very important, the workflow validation. So in the scenario that I've mentioned with the veterinary clinic. It's not possible to do a particular data creation without first to have a data about some another object or another profile.
Mihail: For example, it's not possible to open a medical record for a particular pet. If we don't have enough information about the owner, so the idea behind the workflow validation is that we're actually requiring different steps before something is going to go to the system only on the validation custom form level.
Mihail: So in a little bit more detail, a regular expression validation, as I mentioned, is a bottom. Based on which we're going to validate [00:46:00] some string, some text information usually is correct or incorrect. But if at some point the children of Elon Musk come to your businesses and they require special kinds of service.
Mihail: Maybe at some point we need to reconsider. Our validation pattern. So at some point, maybe special characters and the numbers inside the person name are not going to be so strange or unusual in terms of services. I've already mentioned That using third party service like locate can bring us enough additional information about the validity of those records like phone and email, as I mentioned, shady schemes, phishing emails, or phone numbers that are disabled or part of different roaming services.
Mihail: And last but not least, [00:47:00] the workflow validation consists of the whole steps by step scenario in which we need to travel along in order to achieve something with our data. In this case, I'm just going to show you the application that I mentioned earlier. Customer portal with different records that can be edited or created on a record by record basis.
Mihail: Not only addressing the customer, but addressing a whole relation between the different profiles. So let's dive little bit. Deeper inside the cold. I'm going to open my application in order to showcase some of the ideas behind this. So you can see that the whole source code is just. A bunch of JavaScript files, if you're scared by a programming [00:48:00] language, don't be the whole application structure is pretty well organized.
Mihail: So in the whole the core of the form are those inputs. So those inputs are going to validate different aspects of our of our validation data rule set. So for example, we can introduce an address input, email input, phone input, search input, et cetera. So no matter what kind of validation you wish.
Mihail: To implement, you can just put another JavaScript file, which is responsible for this particular validation. In terms of in terms of actual validation, let's open the file with the validations. So let's check the email validity. So the email validity is asking information from this API addressee, which is the locate [00:49:00] service.
Mihail: I have some key which require for me the information that I'm currently checking and I'm receiving the end result in a JSON format data that I can further Organize, check notify different service or visualize a particular message. So for example, if I open a form of let's go to Peter Norton, the guy who I already added to the system and let's open the browser tool.
Mihail: In order to show you the whole date of validation, so I'm going to change my email. I'm going to change it to Upia T Tech. So this email is not valid, but the pattern is valid. It looks valid. [00:50:00] Why it's not valid. I am sending a request. To the locate service and response code it. Sorry, sadly it's not valid, but what is the reason no MX record found for domain will be attacked.
Mihail: So this is a valid pattern, but without a valid. A record for this particular domain. So in this case, we can go a little bit deeper in terms of understanding how this information is processed. You can see that the service provide that with a lot of extra information that we can get and actually add a little bit of extra risk analysis.
Mihail: So what is the risk for this email? It's high risk. So maybe this is a phishing email, or maybe this is something that the user incorrectly provided to us, or maybe something that our [00:51:00] our operator mistaken by accident. Those are valid questions that we can analyze and analyze further. So if we have a trustworthy customer, which always.
Mihail: Provide us with a track record for for his own or his or her own businesses. And we need to provide information about him. This extra steps are very viable, valuable in giving us information about, yes, we've made a mistake or no, we didn't make a mistake. Something is very fishy in terms of the information that is provided by the customer.
Mihail: So yeah, in this case, the service is extremely valuable in this case. So we're getting the information, we're processing the necessary data and we're returning back the object that is going to be responsible for [00:52:00] managing the whole information infrastructure. Visualization of messages, visualization of styles, et cetera.
Mihail: Also we need to add that. The whole source code is organized in terms of reusable components. So if at some point you wish to create a form that dynamically going to organize itself, you need to just provide the necessary validation input or a specific. Input that is responsible for something like validation of email or validation for country, city, et cetera.
Mihail: So for this example, in comparison of this example, we can have a solid, consistent and straightforward input to JavaScript functions that are going to be only responsible for email or phone or [00:53:00] search validation or a general. Input field, input component, which is going to receive an information direction from the system and is going to act according to a specific rule set.
Mihail: For example, if we wish to create a dynamic forms, we can just Read the L3 configuration from Reltio. And from this point on, we can generate a custom validation form. The most important end step is, of course, the creation of the Reltio protocol object. So we need to get all the information about our field and send it to Reltio in a specific.
Mihail: Object protocol way, so we need to make the whole address, value, country, et cetera, [00:54:00] field, the names. Properly organized in order to remove any suspicious of extra mistake or some problems during the whole computation in terms of relative validation rules. Of course, in order to actually create a genuine API call.
Mihail: We need to familiarize ourself with the rail to API and the rail to back end. But if we done, if we actually successfully complete a custom form, we're not going, we're not going to only achieve this. Communication between the forum and the rail to, but we are also going to effectively connect all of the source system in terms of data source wall and data source output.
Mihail: So this is another valuable aspect of this particular solution in terms of organization. I [00:55:00] wish to just show you some ideas how, for example, if you don't wish any additional checks in your business, you can just go with the simple pattern matching, regular expression, pattern matching in order to say, If a particular record data is valid or invalid in the scenario that I've linked to you in our GitHub profiles, you can see a variation of this use case in which we're using a third party application services, so everything is on the table.
Mihail: The validity of the email, for example, happens with the third party service, but the validity of of the names happens with a regular expression pattern that currently is responsible for validating a names in Latin alphabet. So this is going to yield a very [00:56:00] appropriate result in terms of your name is not weird enough in this case.
Mihail: Okay. So when we do the whole 365 in this customer developed form, we can actually achieve a pretty nice. And sustainable long term validation and general data rules set list that is going to serve not only a specific customer, but a plethora of different customers. So the only issue that we need to solve is this initial investment.
Mihail: You need to write the code initially. You need to write the code. That is going to communicate with the source system and then to write the necessary validation rules that your business requires in terms of customizability. It's a [00:57:00] hundred percent customizable. So for example, if we go in this direction, the document ID, this is something that our customer specifically required.
Mihail: They have a service and this service is going to provide the customers with a special numbers, special document That are necessary for them to access the establishment. And this document ID is going to be different based on majority of ruleset. For example, in which year of the establishment of this particular company, you become a customer.
Mihail: So are you an early adopter? Or are you late in the game or what kind of service we are going to provide you in the long term. So this is not something that a particular [00:58:00] system is going to be interested to provide you. But this particular form, this vet manager can integrate the necessary computation API calls in order to access this document ID from external service.
Mihail: And to put it directly in the system. And from this point on directly to the rail queue, it's zero chance. Some operator to actually make a mistake and to change this document ID, even by trying to copy paste it from a differences. So with custom validations form, we're actually making the chance of mistakes.
Mihail: Near zero, we're removing the costs in the long run. We are improving the data quality sets and by this making the whole operation of our end customers a little bit more, it's cheap, it's scalable, and you're not [00:59:00] going to waste your time with any stupid mistake validation. If you wish to read more about our real world research and development experience and to see more about our tools and what kind of scenarios we are facing on a daily basis, our company, again, I'm going to repeat myself.
Mihail: Provide you with some very useful links that if you follow, you're going to understand a little bit more interesting recipes and interesting approach to different problems like this. In our core, we are an engineering company and we're trying to solve problems. So this particular presentation was hands on demonstration of one of the problem that we solve.
Mihail: And right now, I believe it's time for your [01:00:00] question. I am here with With my team. So if you have any particular ideas, discussions, or questions, we are going to try
Chris: to answer. So thank you very much. A lot of the, yeah, great job, Neil. And a lot of great stuff here. There's a ton of questions.
Chris: A lot of 'em have been answered, but let's go to the ones that have not been answered. Six. Is it possible to access this custom form using API calls.
Mihail: Yes. Okay. So I'm going to repeat myself, but the whole idea of customer form is to sit between systems. So the only way to actually see this form is by creating the necessary API calls.
Mihail: You need to create an API call to the real you back end in order to actually do the whole communication object transfer. Yeah, that's the easiest.
Chris: And this is probably what everybody's wanting to [01:01:00] know. Does this functionality of having custom forms and connecting with Realtio incur additional costs?
Chris: Because I do know that, you can use our Realtio's locate capabilities for address cleansing via API. That makes sense. Yep.
Mihail: Okay. So the extra cost is in terms of. Initial development, you need to actually build this for initially, but the whole idea of those kinds of in the middle solution is scalability.
Mihail: So the initial cost of development is going to be absolutely diminished in the long run because you're not going to make any mistakes. All of those mistakes are going to be initially filtered by this custom form, and they're going to be directed to the rail queue. Of course, we are viewing this solution as an extension of the capabilities of the different source systems and [01:02:00] rail queue in general.
Mihail: This is going to provide more value in the long run. Rather than cost in the long run, because you don't need to support this. You're writing once. Building ones, deploying ones, and from this point on, only when you implement additional data rule, you need to go to this form to add the necessary rule and forget.
Mihail: So no matter dynamics, HANA, SAP, et cetera, some other system in the long run, they are going to have the same kind of validation provided for you as a end customer.
Kos: Maybe the credits. Maybe consider the credits you're gonna consume when you do the validations that you have to purchase from ade.
Kos: Yeah, because this one , that's the only thing that I can think of.
Mihail: Thanks,
Chris: Carlos.
Mihail: Of course. If you wish for example to add the capabilities of any external service, you need to [01:03:00] familiarize yourself with the necessary API quotas, additional costs, et cetera. But of course, we are talking about customer custom scenarios.
Chris: Might have answered this, but let's make sure I don't see it replied to. So I believe these forms are for data ingestions via the UI. What about batch loads, ingestions? Can these forms be called via API?
Mihail: The main idea is to provide the capability for the operator. So usually the operators are using UIs.
Mihail: But if we go strictly in terms of API, I'm going to advise the viewer to actually explore the API of Reltio in general, because the API of Reltio provides you with the capability of batch processing. So in this case, when we are dealing with batches, I'm going to completely circumvent the form and I'm going to go [01:04:00] 100 percent API first.
Mihail: So it's different use cases.
Kos: Yeah, this one is for real time data entry. And the other one is patching for batch, depending on what's the use case. If the use case is, you wanna pre validate your data before it goes into . Yeah you better explore the API if that doesn't provide sufficient capabilities go to locate, submit your data to locate, get back the results.
Chris: And then another
Mihail: solution that I can actually suggest. Is for example, if you have a CSV or Excel file with a lot of customer information that you exported from, for example, from Salesforce or some other service it's absolutely possible to create some kind of form, which is going to do the same, but behind the scene, there is going to be a lot of extra route, your API calls.
Mihail: So this makes. [01:05:00] Completely different use case.
Chris: Perfect. It looks like most of the other questions were answered, thanks to Kos and team. Any other questions before we wrap it up?
Chris: Let's see, does the data loader functionality validate the form?
Mihail: Sorry, can you repeat a little? Again, I didn't catch
Kos: it. Yeah, I didn't answer that. No, the data loader functionality does not validate the form. The form. Has its own validation rules built in, and once the data complies with all the rules, it will be submitted to Railtu using Railtu API. So data loader is for bulk loading of records, and it's not being used.
Chris: All right. Other question and then we'll let it go. Can you provide a concept diagram we can share with our business partners? [01:06:00] Maybe when you share the presentation, I don't know if that's possible or.
Mihail: Yes I believe you can use all the diagrams that I've created. For this particular talk they are on a conceptual level showing the whole idea with a pretty nice data flow diagrams.
Mihail: But for this particular use of your, if you wish I can provide you with some extra visualization. If you contact me or directly on the email of the company in full, we can provide additional concept for the business users that are interested in this particular scenario. So don't be shy. You can follow us on info, Pia tech, and we can talk additionally about different scenarios, custom scenarios, and how can we [01:07:00] apply our knowledge in order to solve your problems.
Chris: Great. Thank you so much to the ULPIA TECH team, tech team. This was really great. What a good information. Wow. Great job, Mihael. And thanks for everybody for showing up today. Please give your feedback after the call, whenever you hit end you'll get a Zoom pop up that gives us just three questions to, for the feedback.
Chris: So we we have a show in a couple of days. I hope to see a lot of you guys there to talk a little bit more about our fern technology and AI kind of stuff. So till then, thank you everyone. And we will see you soon. Thank you everyone.
About the presenter:
Mihail Petrov is a full-stack software developer with extensive experience in building front-office applications for large business organizations. He strongly believes that the UI is usually the problem, but UX is the solution.