Get the PPT and Recipe here: Advanced Data Enrichment with Reltio Integration Hub PPT and Recipe
Join our expert, Dan Gage, Principal Solutions Consultant, in a focused webinar on enhancing data management with the Reltio Integration Hub. Discover how to integrate third-party APIs for advanced data validation and enrichment.
Key Features:
Seamless API Integration: Step-by-step guidance on integrating a third-party email verification service within Reltio to ensure email accuracy.
Data Enrichment Best Practices: Insights on segmenting enriched data into separate crosswalks for clear lineage and compliance.
Business Outcomes:
Enhanced Data Reliability: Reduce email bounce rates and improve communication success.
Richer Customer Profiles: Build detailed profiles for personalized customer interactions.
Transparent Data Management: Effective tracking and segmentation of enriched data.
This session provides actionable insights to leverage third-party services through the Reltio Integration Hub, enhancing your data management capabilities and improving customer engagement.
Transcript:
Chris Detzel: All right. Why don't we go ahead and get started. So thank you everyone for attending today's session on advanced data enrichment with Reltio integration hub. So this is our second Reltio integration hub in the last two weeks. Dan Gage is back. He's the principal solution consultant here at Reltio.
Chris Detzel: Welcome Dan. Thank you. Next slide. So just as an FYI as usual, keep yourself on mute. All questions should be asked in chat or feel free to take yourself off mute and you can ask. So that's the rules. And as usual, we will record this session and push it out to community as, as I always send out a follow up to the PowerPoint and to the video.
Chris Detzel: So next slide. We have a few [00:01:00] shows coming up from this week all the way until mid July. I am looking at trying to get another show on the books for the DMV connector. We'll see if we can get that done by the end of July. But coming up is another Reltio Integration Hub, Tasks and Best Practices to Optimize Task Utilization next week.
Chris Detzel: Then we have one if you're life sciences around. On the 26th patient centricity. One of our partners actually is helping or, providing the speakers and some thought leadership there. And then on July 9th, right after the holidays for the people in the U S we have unlocking the potential of Reltio business critical addition, enhanced security and resilience.
Chris Detzel: It's a new feature that Reltio has. And then we have the Databricks. Data pipeline for Reltio coming out on the 11th. And then we have the Calibra integration as well on the 18th. So some really [00:02:00] exciting things going on with Reltio. So next slide and my last slide. We have a data driven conference coming out in October.
Chris Detzel: We have lots of, some of our customers and some thought leaders that are speaking and giving, talking about their journey. So make sure you register today. And we can give you 200 bucks off if you just, if you register and then you put in, make sure you uppercase community to when you register for the data driven conference in October, by the way, it's in Orlando, so bring your family, it's going to be at Disney world.
Chris Detzel: So how fun is that? And Dan, that's all I have.
Dan Gage: Hey, thanks, Chris. So today we're going to be talking about data enrichment using the Reltio integration hub. And there's a number of different techniques that can be used to bring third party data into Reltio. So in the life science space, we have prebuilt connectors for things like MedPro and NPI, DEA [00:03:00] data and more of the commercial business world.
Dan Gage: We have prebuilt connectors to Dun Bradstreet, Bureau Van Dyck we have bi directional application synchronization with applications like Salesforce. But when you look at some of the niche vendors, and today I'm going to be working with a vendor called People Data Labs and another one called Quick Email Verification.
Dan Gage: And they're both pretty simple to get to. It's just peopledatalabs. com and quickemailverification. com. I just want to state that Reltios does not formally endorse either of these companies, they are not officially partners, but it's definitely services that I have personally leveraged because I found them very easy to deal with.
Dan Gage: They have very very friendly pricing models for testing and getting up and running very quickly. And as you'll see in the demonstrations here they have REST APIs using best practice around API keys that make it very simple and easy to integrate, especially when you've got a flexible technology like the Reltio Integration Hub.
Dan Gage: We're going to show two demonstrations using two [00:04:00] different methodologies to integrate with these two different vendors. The purpose is going to be a little bit different. People Data Labs is a company that mines data from various social media and other aspects. Of real world data to give you enrichment around a single individual.
Dan Gage: So it's going to tell you what their social media site is, what their most likely email addresses, phone numbers, addresses. There's a lot of data that they can provide for demonstration purposes. We're really going to be focusing just around phone and email. And we're only gonna be passing over to them the name and the organization that an individual is affiliated with.
Dan Gage: But again, like Dun Bradstreet and other companies, the more information you pass over to some of these data services, the more accurate and the more information they can give you back. But again, for our demonstration purposes today, we're primarily going to be focusing on the integration between Reltio and any third party data service.
Dan Gage: So we're going to stick with a relatively minimal data transmissions over and back. But to [00:05:00] extend that to passing more data over or receiving more data back is just utilizing the standard best practices that we'll introduce you here to today. 1 of the other things we'll focus on is the different methodologies for integrating with these various different services.
Dan Gage: On the left, we're going to be focusing with people data labs to run on a scheduled basis. And on the right, we're going to be triggering that from a an application event. That happens inside of Reltio. To highlight that, I've broken those down into a couple different categories that are typical approaches to data enrichment.
Dan Gage: The first is really just on demand. And Chris mentioned that we're going to be adding a session later this summer for Reltio's integration with Dun Bradstreet. Reltio's Dun Bradstreet integration with Bureau Van Dyck and some of our other sources, does use this on demand approach. It basically puts a user interface button.
Dan Gage: Into the relative application where a user can simply click that button and the record that they're currently on will get [00:06:00] enriched. We will not be demonstrating that method today, but you will see that through some of our other connectors it obviously in order to customize the relative user interface to add that button and to put the appropriate APIs in place that is a little bit more complex method, but it does provide a very nice user experience.
Dan Gage: That's one option. The first, second and third will be demonstrating live. I mentioned the scheduled approach and that's basically where you have a periodic job that is going to pull the system for records that meet some enrichment criteria. And that enrichment criteria could be just any newly created record, any record that hasn't been enriched, or you can put a flag in there where you specifically request enrichment for individual records.
Dan Gage: So that's what we're going to be doing in our demonstration today is we've added an attribute that says, yes, I want to enrich this record. And when you set that attribute to true, it's going to go out and make an effort to enrich that record. In the third scenario here, we're going to pull from the Reltio event [00:07:00] queue.
Dan Gage: So Reltio has a platform. Anytime you make a change to a record. We're going to generate events. Those events can be record created, record was changed, record was merged record was unmerged. So there's a number of different times where you would want to revalidate the enrichment of a record because whether you're merging or unmerging record, you're changing the profile and you're changing the aspect of data that you have about it.
Dan Gage: So re enriching that record is potentially viable for our demonstration purposes. We're just going to be focusing on the create and change events. But again, based upon your business needs, you could go into a broader set. Of criteria there. So what you're going to see here is the idea that first scenario where a schedule enrichment by an attribute and with the people data labs, we're updating and enriching the entire profile.
Dan Gage: The enrichment criteria is at the profile level. So I've just added a profile level, simple attribute called enrich. I've set it to be a Boolean attribute. [00:08:00] And I'm going to periodically have a process that's going to wake up every five minutes, and you could set that to every hour, every day, however often you feel is appropriate for your business.
Dan Gage: And it's going to look for records that need to be enriched, but you'll see on the right hand side here, once I enrich the record, I'm going to add an enrichment date to that record. So therefore, in the future, We're not going to re enrich records that have already been enriched because typically there's a cost associated with each enrichment.
Dan Gage: But by storing that enrichment date, it also gives you the ability that if you want to periodically go back and say, Hey, if the enrichment is more than six months old, I want to re enrich this record. So a good example of that is I used to previously work at Oracle. So if you did enrichments at a time, 14 years ago, when I worked at Oracle.
Dan Gage: You would have gotten a dan. gage at oracle. com. But if you re enrich that record today, it's going to say that Dan Gage now works for Reltio. And it's going to give you dan. gage at reltio. com, even though my phone [00:09:00] number has been the same across that period of time. So just taking in consideration based upon your business requirements, the enrichment pattern that you use is going to be specific to your needs.
Dan Gage: What we're going to focus on here today is the actual methodology for building that enrichment.
Dan Gage: So as I mentioned for the first scenario, we're going to run on a schedule. So when you go into relative integration hub and you say that you want to create a new recipe, the first thing it's going to ask you is how you want to trigger that recipe. So you can say, I want to run it on a periodic schedule.
Dan Gage: I want to run it when an event happens in an external application. Or you could say, I want to build this integration as a web hook or an API. And by building it as an API, that would give you the opportunity to hook that into a Reltio user interface button, similar to that first scenario that we discussed with the Reltio DMV connector.
Dan Gage: So again, you'll be seeing that session here hopefully in July. But it's consistent with our applications that it gives today. If you go to youtube. com slash Reltio and [00:10:00] look for our Dun Bradstreet enrichment videos, our Bureau Van Dyken enrichment videos, you'll see that methodology represented from an end user perspective.
Dan Gage: And the difference would be the integration instead of running on a schedule or running from a triggered application, it would be building that integration based as an API event. That would be invoked from that API, but
Dan Gage: so again, I mentioned for our scenario, we're going to wake up every 5 minutes. We're going to go out and we're going to search for individuals. And in my scenario, I'm just looking for records where the enrichment attribute is true and we are missing the enrichment date. As I mentioned, you may want to put a more complex scenario in here where it says.
Dan Gage: The enrichment attribute is true, and it's missing the enrichment date, or if the enrichment date exists, and it's greater than 90 days, 180 days, 360 days, whatever your threshold is that you may want to re enrich records, by just adjusting that in your filter parameter, the idea is that [00:11:00] only the records that meet the criteria of needing enrichment or needing re enrichment We'll fall into this for each loop that falls on step three.
Dan Gage: That's going to go through the process of calling that API on step five of getting that new enrichment or refreshing that enrichment for those records. Also notice in the first scenario, I'm doing more of what we would call a proof of concept, which is just a quick and dirty, get the integration working.
Dan Gage: In the second scenario, where we're connecting to the queue, we've got a little bit more error handling and monitoring, attempting to adjust for different conditions. So again, that's something you want to take into consideration when building a production grade code, you want to make sure you have error handling and potentially retry methodology.
Dan Gage: We're making sure that nothing's falling through the cracks. Again, that's going to be part of your relative integration methodology. What we're focusing on here today is just the general framework. So one of the key things is when you're bringing back [00:12:00] enriched data, you want to make sure that rich data is being augmented or added to the existing profile.
Dan Gage: And, but typically we strongly recommend that when new data comes in, you don't want to change the crosswalk that shows where that data originated. If the data is coming in from a new source, we advocate that new source is represented by a new crosswalk. So for anybody that's not familiar with relative crosswalks, the crosswalk is basically the lineage of where that data came from.
Dan Gage: Therefore, it's important that when new data comes in from people, data labs or email verification services that you'll want to associate that new data with the that service. And 1 of the nice ways that you can do that with is by using what's called a data provider and contributor provider flags. If you're not familiar with these, basically, what it allows you to do is.
Dan Gage: To indicate what is my relative crosswalk that I want to tie the record to. And by setting the flags to say, I am not providing new [00:13:00] data for that relative crosswalk. Instead, this is my contributor crosswalk. It's contributing that merge tree. So when you look at the sources tree inside of relative on that right hand side that has those many crosswalks coming together.
Dan Gage: What we're basically saying is we don't want to have to go through any matching and merging process. We explicitly know that this new piece of data should be tied to that existing tree. By giving it the existing tree on the left hand side, as the contributor provider, and then on the right hand side, sending any new data is going to be associated with this people data labs.
Dan Gage: New crosswalk, it will automatically stitch that data together. So this is an important factor when doing enrichment. And what that's going to allow you to do here is you'll see that in our demonstration, we're going to create a new record. It's just going to be created from the Reltio UI. So the existing data that we're going to tie in is going to go onto that Reltio crosswalk.
Dan Gage: In this case, it has a a Reltio ID that ends in seven Y [00:14:00] H, and we're just going to tie into that and we're going to add that people data labs. So you'll see that enrichment data, you see that email and phone number that has come back. is going to be associated with that new crosswalk, but it will automatically be aligned with the existing Reltio crosswalk.
Dan Gage: So again, using that data provider and contributor provider parameters allows you to bypass the matching and merging process, which creates no ambiguity with regard to whether or not a match or merge would take place or whether data could inadvertently be tied to the wrong record. So it explicitly says this is the record I'm enriching, and I want to add this new crosswalk of data to that existing record. The second method that we're going to use here is tying into the event queues. Depending upon where your Reltio software is deployed, you can leverage the SQS environment within Amazon, within AWS, the PubSub services within Google, or the Service Bus within the Azure platform. And there's actually [00:15:00] no restriction as far as, If you've deployed on Google or Azure, and you still want to use an SQS queue to manage this process.
Dan Gage: I personally have found that the SQS queues are a little bit easier to work with, but it is 100 percent a an architectural decision made by your organization. The methodology that we're using here is simply a matter of saying, how do I want to trigger this process to run? And we've indicated that we want to listen to new messages on an SQS.
Dan Gage: If you say, I want to listen for new messages on pub sub or new messages on the Azure service bus. Everything else would be exactly the same. It's just a matter of how this process gets started. So the previous example,
Chris Detzel: sure. Go ahead, Chris. How many enrichment buttons can you have? Is it just one or more?
Chris Detzel: Can you do no, there's
Dan Gage: definitely no limit from the standpoint of when you're doing extensions to the relative user interface, adding those buttons and then associating those buttons with different tasks. So if you wanted to put one button there to say, I want to enrich with people, data labs, another button to say, I [00:16:00] want to enrich the email.
Dan Gage: And then potentially another button that says I want to enrich with zoom info or axiom or another, you could certainly just stack, a half dozen buttons on there, as long as they're all performing different tasks. It's really how you integrate the action of those buttons. Thank you.
Dan Gage: So again, just to wrap up here, the the idea is that, Reltio integration hub doesn't necessarily have to exist in a vacuum. It can exist by connecting into a different application. Likewise, you can connect into applications like Salesforce and say, I want to listen when a record is created in Salesforce, I want to bring that record into Reltio.
Dan Gage: But before I bring it into Reltio, I want to call out to one of these enrichment services, and I want to add some additional data. And then bring that data in using a Salesforce crosswalk and a relative crosswalk that's completely viable. So how you trigger this event. Is again, completely at your discretion.
Dan Gage: For our purposes, we're going to be triggering it when a new event [00:17:00] comes into the SQS queue. One thing to emphasize when you've got these processes running with the scheduled job that we mentioned first, because I've got it set to a five minute interval, It's going to wake up every five minutes and it's going to do a query into the relative system to see if there's records that are in need of enrichment.
Dan Gage: And with that approach, it's going to run every five minutes, even if it doesn't find any records, there's not any incremental process where you can say if you don't find records, wait 10 minutes next time, and then 20 minutes, and then 30 minutes it's just going to run every five minutes. So it is going to utilize.
Dan Gage: It's a very small number of relative integration hub tasks and a small number of relative API tasks. But it's pretty minimal in the grand scheme of things when you've got a well defined process there that's encapsulating the actual task utilization and the logic and applying it only to records where it's relevant.
Dan Gage: So likewise, with the queue, you've got a little bit more granular [00:18:00] control with that. So instead of saying that you want to take action for every event that happens in a queue, here, we're saying we want to filter that queue using the RelQO queue management to only the create or change events. And again, I mentioned earlier, you may want to also add in the merge and split events.
Dan Gage: And in this case, we're also saying we only want to do this when the attribute email actually exists. For profiles that are created that don't have an email address obviously, we don't need to do an email verification if there's no email to verify. And you could certainly get more sophisticated on this to try and optimize that further so that you're only generating events.
Dan Gage: Now, again, this also takes into configuration consideration that this queue is dedicated to this enrichment process. If you have an existing queue that's being used for other enrichment processes as well, you may or may not want to change these filter events. You could have one queue that's generating events for multiple different processes and then just deciding how they're going to be processed and what [00:19:00] action is going to be taken, whether you're subscribing directly to the queue or to whether an SNS topic.
Dan Gage: Is again, completely your discretion. We're focusing today primarily on the methodology. The other thing we're going to emphasize here is that for our demonstration, the payload type Relative does give you three options. The first is a snapshot where all the data from that record is going to get sent.
Dan Gage: And I apologize when I move the mouse, it's advancing my slides. First option is to send a snapshot where all fields of data are passed into that queue. The second option is where you can explicitly tell Reltio I only want to pass a subset of those fields, such as the email attributes. But by choosing the Delta type, it does give me a little bit more control of saying I now I'm going to send Delta events where Reltio is going to explicitly tell the queue what attribute has changed.
Dan Gage: And because it's telling Reltio what attribute has changed, I can pick up on that, and I can only worry about trying to do enrichment if the [00:20:00] email address has been created or changed. So again, we'll see that in the the next sections. So what we're going to start off with is just creating a single contact with a single email address.
Dan Gage: So you see down here, we've got the email address on the right hand side. We've got the lineage that's just showing that Reltio record. In this case we onboarded this record from an external source called sales connect. And it brought in that email record. The email record. I actually added via the relative interface here, but the relative data cleanser is still going to pick up and apply its functionality.
Dan Gage: But you see here at the bottom of the verification status and the the verified status are not yet populated. So that's 1 of the things we're going to trigger off of. So in our recipe, we're starting from a triggered event in that application. We mentioned that earlier we're listening to that SQS queue.
Dan Gage: We're going to loop through all the messages that are coming into the queue. And remember that. We're only queuing on create and change events, and then [00:21:00] we're only queuing on the create and change events when an email address actually exists on the profile. In this case, we're creating a variable that says, has the email changed and we're doing some some logic in there.
Dan Gage: To calculate whether it's a create record that has an email or whether or not the attribute that's being impacted is an email attribute. And if it is, then the email changed is going to be set to true, and we're going to do some continuous processing. So again, things that we're doing here to optimize the task utilization, and we have a session next week that's going to go into a little bit more detail.
Dan Gage: Around these types of filters, as well as the ability to use what's called a data pill to batch process multiple records at the same time. That session will be next week and very helpful. You'll also notice that I'm using a monitor air handling here. So for any of you that have written code that have seen a concept called try catch where it's looking to catch errors, and it's going [00:22:00] to perform some air handling task.
Dan Gage: If an error is discovered, you'll see that I've inserted that monitoring function of the relative integration hub into this process to make it a little bit more resilient, where if it's processing multiple events from the queue. If one of those events fails to be processed successfully, it's just going to skip over that one event and it's going to continue to process the rest.
Dan Gage: So again, the relative integration hub does give you the ability to create some of that resiliency into your process. And to move on.
Dan Gage: So one of the things that I wanted to focus on here is when connecting to these third party services Reltio does give you the ability to create what's called a connection object. It will automatically create any of the connection parameters such as the API key that's needed to connect into these, and it will allow it to be stored separately from the recipe.
Dan Gage: So when you're building it and using that [00:23:00] HTTP connector to connect to this REST API by putting the API key into the connection parameters, it is going to store that information separately from the recipe. And where that becomes important is when you migrate this recipe from your dev to your test to your production environment, you may have different API keys that you use in each of those environments.
Dan Gage: And by having that information stored in the connection object, you can promote just the recipe without promoting the connection object, and it allows you to preserve that abstraction or maintain the integrity of those keys. That is definitely something that we advocate as best practices is to store any of your credentials in the connection object and not hard code them directly into the recipe itself.
Dan Gage: Um, again, I have a question about this part, please. So in terms of, if you're calling an API and there's a token that you want to save here, do you have another method to maybe not store that information here, but maybe pull from [00:24:00] the customers, let's say, secrets manager? Yeah, so the connection object, when you look at the authentication type here, I've chosen the query parameters.
Dan Gage: There's an additional type in here that would be an OAuth 2 or other connection methodologies. And that's definitely going to give you the ability to manage and store that connection separately from the recipe itself.
Chris Detzel: All right.
Dan Gage: Thank you. Yeah,
Chris Detzel: Dan, there was a similar question there. So thanks for answering that.
Dan Gage: Yeah, definitely. And again here on the inside the recipe itself we're checking to see if the email has not been enriched. So here were the value in step nine that we're looking to be present is that email enriched date in. If the enrichment date is not present meaning the present is not true.
Dan Gage: So it's not present. Then we're going to go ahead and do this processing where we're going to grab the email and they type it. And we want to keep those because they're going to be important to send back into the recipe here when we after we've done the enrichment. [00:25:00] And the left hand side inside the red box is where we're calling that API.
Dan Gage: And again, we'll be providing these recipes in a zip file that you can import into your Relative Integration Hub environment. But basically what we will do is just if you're doing this from scratch, When you're setting up that recipe and walking through the wizard in this case, each A. P. I.
Dan Gage: that you use from different services may accept data via different methods. It could be a get. It could be a put. It could be a post and you'll need to adjust the configuration of that A. P. I. Call again. We do recommend that the the A. P. I. Keys are stored in the connection object. So here we're only storing the email value.
Dan Gage: In the in the record, you'll see here that I do have the full URL in here. I actually did get a warning. I've corrected that in the the recipe since I took the screenshot. But, um, the idea here is just that we're doing a get to the quick email verification version one of their [00:26:00] verify service.
Dan Gage: We're passing the email over as a value, and then that API key is going to get appended from the connection object. So it's not actually stored in the recipe. It's inherited from the connection. Again, as we mentioned earlier, when you're bringing this enrichment data in, you're going to want to tie that data to your existing profile. In this case I did highlight here when you're building out your crosswalk typically, you would only have a single crosswalk when you're bringing new data into the system.
Dan Gage: But because we're using this data provider methodology, we do want to have two crosswalks that we're going to pass into the record. And that does require us to change the input mode from the crosswalks from a dynamic list into a fixed list because we're fixing it to be exactly two items. On the left here is item 1, the Reltio crosswalk.
Dan Gage: That is not a data provider. It's contributing the merge tree that we're going to tie into. And then item two, the second crosswalk is going to be the new email verification where it is [00:27:00] contributing the the data. You also note here that in the previous scenario, the value that we used for the crosswalk was just a key that was coming back from the people data lab service.
Dan Gage: And it was allowing us to uniquely represent a single crosswalk for the entire profile. But in this case, because a single profile could have multiple email addresses. We're going to want to be a little bit more granular in the email verification crosswalks that we create. So here you'll notice that I'm taking the full URI, which is going to be entities slash and then the number.
Dan Gage: So we're doing a split on that beast of slash, and we're just taking the entity ID. And then we're concatenating that with a hyphen and the actual email address itself. So you'll see that in the next example. Where if there's multiple email addresses, each email address will actually generate its own crosswalk.
Dan Gage: So this doesn't have any impact on your relative licensing perspective, but it does give you a much more granular lineage of the [00:28:00] fact that each email verification that is done. is storing its own data on its own crossword. We'll see an example of that here. You'll see that we brought in a first dan.
Dan Gage: gage at oracle. com, and then we're later going to bring in a dan. gage at reltio. com. You can see it's grayed out right below there. But the first one we're using the entity ID for this record and then concatenating that email address, which allows you to see that the service recognizes that I no longer work at Oracle.
Dan Gage: So therefore Oracle is going to reject any emails you try to send to me there. So it's flagging that address as invalid. And that is associated with the Dan dot gauge at Oracle crosswalk. And then the Dan dot gauge at Reltio crosswalk will reflect the verification status. For that record. So again, the best practice would be each time you're enriching a record to store that enriched data on its own crosswalk where that data applies to the entire profile.
Dan Gage: You can use a single key, but where it [00:29:00] affects sub portions of a record. And you see this today with locate with your address correction and standardization is each address is going to have its own crosswalk. To the enrichment of that address. So very similar with a standard best practices.
Dan Gage: And we'll stop for a second, see if there's any questions and we'll jump in and take a look at this in the live software.
Chris Detzel: There's not any questions that I, that people have posted. So I think.
Dan Gage: All right. So we're going to start off with the the people data labs. So I'm just going to come in here and again, how the data gets ingested into Reltio is really irrelevant to this process. In our case, we're just going to come in here and say, I'm Dan Gage, and I have an employer who is Reltio, and that's all the information we're going to provide. When we save that information, it's coming into the system, and in this scenario, because we're using a scheduled job, and to [00:30:00] see, I've got some email validations here, no email, missing some other information.
Dan Gage: But this process in the background here, if we look at it, because it is a scheduled process. Now, in a production environment, you would have this running consistently for demonstration purposes here. I have not started the recipe, but you can see that it's just going to wake up. It's going to do a search and as we saw earlier, it's looking for the enriched value is true and it's missing that enrichment date.
Dan Gage: And then for each of the records that are found in step 2. It's going to loop through those records. We're pulling out some of this data, and this is primarily for debug purposes, just putting it in some intermediate variables, the first name, last name, the company, and then here's where we're calling that API.
Dan Gage: And as I mentioned earlier being able to store the key separate so that key is stored in the connection object. So this is the recipe. These are the parameters that are being built and defined within the recipe. But if I click back to the connection [00:31:00] object and look at the details here, you'll see that API key is stored with the connection, so it will be inherited and passed down into the recipe itself.
Dan Gage: So not only will it pass over the first name, the last name of the company, it will also pass over that that API key, but that is encapsulated in the connection object and therefore secured from the the recipe process. Again, these parameters and the methodology that's used, whether in this case, we're using a get, whether you're using a post or anything else, that's going to be specific to the API that you're invoking.
Dan Gage: But in our purposes, we're just going to grab the email address. That came back from that result set and one other thing to focus on, and we covered this last week in our data enrichment for using locate the response message that you're going to get back. We did import this, so you can see here the structure of the status and the likelihood and the data that's being passed back.
Dan Gage: You'll see that there's a wealth of data that's [00:32:00] coming back from this service. It is giving a work email. It's got a personal email. Array, and then there's another array down here at the bottom of there, just all of the emails that are available. So what we're doing in our purpose is that we're trying to grab that work email.
Dan Gage: And if that work email is not present, we're going to loop through those other email addresses, and we're just going to grab one of them from that just to make sure we're getting something. So again, just showing that the data that's coming back. In some cases, you'll get a lot of data back or a little bit of data back and you may need to conditionally decide.
Dan Gage: What is the right field to bring into Reltio? So we're just highlighting that ability to say, if we're not getting a work email field, if there are other emails, you can select that. In this case, we're just putting it into that email parameter. And the end result is that we're going to write that data back into Reltio.
Dan Gage: So as I mentioned earlier, I've switched this over to a fixed list. For the crosswalks, we're passing in the Reltio [00:33:00] crosswalk as a non data provider. It's providing the contributing merge tree, and then the People Data Labs is using that identifier that came back from the enrichment as the the key, and it is providing the data.
Dan Gage: And then we simply use the the drag and drop here. We're bringing in that loyalty I. D. As the universal I. D. And then most importantly, we're bringing in that phone number. And again, we're checking to see, is the type of phone number present? If so, make it a mobile and bring in the mobile number.
Dan Gage: And then is the email present? So if so, it's a work email and bring that in. And again, there's a lot more information that could be out there, but if we simply just test this recipe. It's just going to run through, and
Dan Gage: I omitted the fact that we are looking for records that have the enrichment flag set to true, and I forgot to set that enrichment flag to true, so therefore we weren't doing anything. So by adding that [00:34:00] enrichment flag and setting it to yes,
Dan Gage: we now meet the criteria. So nice demonstration, not intentional. So you'll see it's going to take a little bit longer because it now finds a record that meets the criteria where the enrichment flag was true, and the enrichment date is not present. So it's going to go through, it's going to grab some of that data out.
Dan Gage: Dan Gage works at Reltio. It's going to pass that data over to the the API, passing that information over. And the data that it gets back, you'll see that there's a wealth of information. It tells you all the companies I previously worked at, what my role is at those organizations. There's my personal email address.
Dan Gage: I used to work at Informatica. I now work at Reltio. All that those rich details that are coming back from the enrichment service. Again I am being very selective in what I choose to bring back here. We did get a work email address, so we're not having to parse through those other [00:35:00] emails.
Dan Gage: And we're just grabbing the data that we're going to push over, which is the the work email, the mobile email, the enrichment date. We're now setting. So in the future, it will be there. And then using that data provider and contributor provider, we're passing over those 2 crosswalks for that record. When we look at the sources again, this is before we refresh.
Dan Gage: All the data is coming from Reltio when we refresh now that the enrichment has taken place. It's now added that people data labs has added that email and phone number and because we've added an email, we now have an opportunity for the relative data cleanser to go in there and enrich that phone and email address. You can see here that we now have that enrichment date. So if we run that process again, this record will no longer meet that criteria. And we now have additional data. And one of the really nice things about data enrichment is as you start enriching the profile and bringing more data in, you'll see that you now have the ability to [00:36:00] have potential matches against other records in the system. That concludes this section. We're going to go to the next section where we're going to look at the event based. And if there's any questions, we can have those on this section and then we can. Yeah, there is
Chris Detzel: one. When does it make sense to use an enrichment button when it seems to me we always want to create a scheduled approach for Reltio integration of integrations?
Dan Gage: Yeah, and that's a great question, but it's really going to come down to your business users. Because there's a cost with this enrichment approach, if you're dealing with a B2B environment and you're dealing with business contacts, and you feel that all of your contacts need to be enriched, then using the second methodology of just any time a contact is created, we want to enrich them, or not even looking for this enrichment flag, simply looking at have they been enriched before and if they haven't, calling that enrichment.
Dan Gage: Or putting the button on there to let a business user selectively choose of all the contacts in our [00:37:00] system. Maybe you're getting good data from your salespeople that's being collected through Salesforce and coming into Reltio and there's not a need to do further enrichment. But where you have data that's missing.
Dan Gage: So that could be a key example is if you go into your relative integration hub recipe here. And instead of looking for records where the I think it's a higher. Instead of looking for records where it's missing the enrichment date, you could perhaps look at records where it's missing an email or missing a phone number or missing some critical piece of information that you feel you can get from the enrichment process, and therefore you're only enriching records where you're missing what you feel is critical business data.
Dan Gage: And again, whether you're doing that through this recipe or whether you're putting a button on the screen to allow a business user to manually invoke that process, it's really the business decision on what is the right integration pattern to trigger this event. Whether it's through an on demand [00:38:00] button, whether it's through a scheduled enrichment or whether it's based upon a queue.
Dan Gage: Thanks, Dan. That's all the questions for now. All right, great. So we're going to switch over to a different window here. Where we're going to create a record, and we're going to create in this case, I contact
Dan Gage: myself. And I'll put in my obsolete email here, Dan not gauge at. Oracle. com.
Dan Gage: So a couple things to note. First thing that's going to happen, of course, is the Reltio cleanser is going to do its job to check the validity of that email address, but it's just saying that is a well formed email. It doesn't guarantee that an email sent to that address is actually going to be received.
Dan Gage: So in this [00:39:00] case, our process is going to be triggered by listening to events on that queue. And I showed you the screenshots earlier where we'd set that queue up to listen to a change in create events. We're gonna process through all those events. We're checking for errors here. We're gonna parse out that that JSON structure that came in from that message queue.
Dan Gage: And we're gonna look at the whether or not the email has changed. And I mentioned here that I'm looking at the type of attribute, whether it includes the email. So attribute type is gonna be part of the message here. So because we're using that Delta payload, This is just a sample message that we brought in for that JSON parsing.
Dan Gage: If the attribute changed is the email address, that's what we're triggering off of. So if I change the name, then there's no need for me to do an email enrichment. So again, just a small optimization that we're trying to do to say How do I know if the email has changed? With the event created, [00:40:00] it's not going to tell you specifically what each attribute that changed is.
Dan Gage: It's just going to give you the entire payload. But because in our event filters, we're saying only create events into the queue if there is an email address present. So if a record has been created, we know that we're only getting an event for created records that have an email present. So therefore, it's indicating that we want to do this enrichment.
Dan Gage: So again, the business requirement in this scenario is that all new emails or all changed emails are going to get re enriched. So again, we're going to come in here if the email has changed. We're gonna go out, we're gonna get that record from Reltio. We're gonna loop through the records. We're gonna look at multiple emails 'cause there can be multiple emails.
Dan Gage: And you're gonna see that here in a second. Checking to see is the the verification date. On that record, has it already been verified? If it has, then we don't need to re verify it. So if there's multiple email addresses, which again, you'll see here in a moment, this is again, just a more production grade [00:41:00] optimization where it's not re verifying email addresses that have already been verified.
Dan Gage: And in that case, it's just going to call that event. And again, this is very similar to the previous, and in this case, you'll notice I'm only putting the the request URL intermediate path here. And in the connection object I'm defining the base URL. So quick email verification. com. We're passing in that API key and that information is abstracted in the connection object.
Dan Gage: And then in the recipe itself, Relative does allow you to specify which URL path should be appended to that base URL. So again, this is a little bit better methodology, especially if you're going to be calling multiple APIs, maybe you're calling an API to enrich the contact. You're calling an additional API to enrich the organization that this individual is associated with.
Dan Gage: So by using that variable path here, it allows me to share that connection object. Across those various different records. So here we're just passing that email over [00:42:00] and the response data that's coming back is going to give us a result. The reason is it a disposable email and so forth. So we're again, just going to take that data, map it into a relative object.
Dan Gage: So very similar. We're using the data provider and contributor provider. And we're going to pass the type and email and this is how we're going to regain the alignment to make sure that the enrichment on in this case, my Oracle email address, the enrichment for the Oracle email address gets applied to the Oracle.
Dan Gage: My enrichment for the relative email address gets associated with the relative address. In this scenario, rather than running this a single time, because we are looking for those events. I'm just going to start this recipe and I'm going to allow it to run in the background here. So it's going to run and it's going to kick off here fairly quickly because there's already a vent out there For that initial record that we created and we'll give it a sec to to find that event
Chris Detzel: quick question does then richer [00:43:00] provide company level phone numbers emails or
Dan Gage: So this service does And it's totally going to depend upon the third party service that you choose.
Dan Gage: Again, rest Reltio as an organization does not officially verify endorse people data labs, but I've had very good experience with them and the the quality of data that they produce. But again, that's a business decision for your organization to decide who you partner with for your data enrichment services.
Dan Gage: Reltio does have formal integration with Zoom Info coming out later this year, where we're going to provide a recipe very similar to what you're seeing that I've pre built here. But a couple of things to point out too is I mentioned with the People Data Labs, I put the enrichment attribute at the base level.
Dan Gage: Here I am extending the definition for the Reltio email nested attribute. So relative out of the box provides the type, the email, the domain and validation status. So I've added the verified status, the verified reason in the enrichment date. So I've just [00:44:00] extended these three attributes. And that's important because as you see here, when we refresh this record and see the enrichment, In this case, we only had a single email on there.
Dan Gage: So we're only getting a single email verification record. And again, it's using the dan. gage at oracle. com to segment the information that's being added here. The fact that this is an invalid email because it was rejected by the service and it was done on today's date. So running again, it's not going to reprocess this record.
Dan Gage: So instead I'm going to come back over and I'm going to edit. Okay. And I will add another email to the same profile.
Dan Gage: And I now have that in there. So what you're going to see is that Oracle record still has its verification [00:45:00] status. But the Reltio record does not have a verification status yet. And because that Reltio integration hub is running in the background it's going to periodically check for new events coming in from the queue.
Dan Gage: But I can just force that, let it come in and process that job. It does say one job found. So within another second here, it'll be done processing and see if we're there yet. So we
Dan Gage: still just have the one that queue is still waiting to pick up that other event.
Dan Gage: And we now have the 2nd. So there's the 1st enrichment that was associated. That orange dot is only being associated with the Oracle record that verification is [00:46:00] only relevant for this record. And the second one in the the turquoise green here is being associated with the RELTIO record, and you'll see that it's specifically referencing the RELTIO record.
Dan Gage: And in this case, it is a valid email address. It was accepted. Emails sent to me at this address will be received, so we've now stitched in that additional information. And that process is continuing to run, so if I was to go out and create a new record with an email address, it would automatically get enriched, again, within a few moments.
Dan Gage: Thanks. Of the creation it will come back and it will stitch in that additional profile details So that concludes the demo. I think we've got a few minutes left here We can certainly open it up to questions. We can be with specific regard to this scenario or we can talk more broadly about other services.
Chris Detzel: All right if you do have some questions, please either pop them up in the chat real quick or take yourself off mute ask Because there's nothing there as of [00:47:00] yeah, I
Dan Gage: will mention that the quick email verification service that I'm using again similar to the people data labs. I found them to be very economical, very reliable.
Dan Gage: There are other services out there, such as Melissa data. Locate actually offers a email verification service, I believe. So there's other vendors that can provide this. It's just a business decision. And each of those vendors can give you pros and cons of why they feel their services better than others or more economical than others.
Dan Gage: But this is just one that I chose to use because of the the cost to Reltio for us to demonstrate this capability and the fact that it met my needs.
Chris Detzel: Yeah, that's a good point.
Dan Gage: All right. Chris, if there's anybody that's got additional questions out there I would encourage anybody to come back into the relative community and certainly post your questions out there and Chris will make sure that if for some reason I don't see them he'll give me a little tug on the chain and make sure that I'm responding back to you.
Dan Gage: But we're happy to help you in this regard, whether you're enriching with [00:48:00] services like this or others. We're happy to help point you in the right direction.
Chris Detzel: Great. And Dan, thanks so much. And everyone, thank you so much for coming to another show. We do have one next week. And pretty much every week, except for the July 4th week, which is the holiday in the U S please take the survey at the end, whenever you leave, you'll get a pop up, just your your help is always needed.