Transcript: Chris Detzel (00:00:00):
All right. Well, hello everyone for another Reltio Community Show. My name is Chris Detzel and I'm Director of Customer Community and Engagement. And I would say special guest, but Dmitry and Yakov have been here for a little while over the last four or five episodes of Community so really appreciate their time and effort on doing these. Today's topic is Survivorship Strategies Interaction with Key MDM functions and Services. So as usual, please keep yourself on mute, ask your questions in chat. I'll make sure to ask those questions, the show will be recorded probably sometime this week and posted out on the community. And there's at least two more coming up that I haven't pushed out here yet that Dmitry, he's going to do one, but coming up, we do have a community show: Transform Dirty Data- Reltio Cleansers 101, that's on March 10th.
Chris Detzel (00:01:03):
And then we have one on the Enrich Your Data with the BvD Connector coming up on the 23rd. Founder and CTO Manish Sood, he's going to be doing an ask me anything. More to come on that one, but we will be giving away some first time community swag, shirts and hats. So I am super excited about that. And then the last thing, I'm going to stop sharing, but I'm going to post this in the chat, because this was kind of a fun exercise is what is MDM to you? And I posted this on the community so if you could go to that link and tell me what MDM means, we at Reltio kind of put what we thought it meant, and then some other people have thrown their ideas out there. So I just want to throw this out there to the group to feel free to go and put what you think MDM means. And so without further ado, I'm going to hand this over to Dmitry.
Dmitry Blinov (00:02:03):
Okay. Let me start sharing real quick and then open joining. So let me start sharing. Okay. Can you see my screen? I'm switching to the slideshow.
Chris Detzel (00:02:16):
Yep.
Dmitry Blinov (00:02:18):
Okay.
Chris Detzel (00:02:18):
Looks good.
Dmitry Blinov (00:02:20):
Good a time. Right. So this is the last show in the series of show related to survivorship strategies and operational value calculation. The goal for the whole series was to walk you through and do a deep dive into overall how I would say how the attribute values survive. But in reality, we are talking about how the consolidated profile is being consolidated and even how the entity resolution, it happens. Because again, OV calculation is in the core and is in the heart of all that.
Dmitry Blinov (00:03:07):
So in today's session, we will be wrapping up. We'll review again the consolidated profile logic regarding the operational value and data calculation and data model. And I added roles to its view as well. So that's called refresh summary. We'll just go through the details again of what we covered in these series of these shows. We'll talk more about operational value in other iterations like matching and search and cleanse and then we'll talk about roles. And actually for the roles, I didn't do a lot of slides. We'll do a demo so we'll demonstrate how it works and how it is configured. Yakov will just show you [inaudible 00:03:58] where it is configured. So he prepared that part and Yakov will be running the roles and demo part of today's presentation.
Dmitry Blinov (00:04:10):
Next slide. Again, as I keep repeating entity resolution is in the core of multidomain MGM, and this is why it is important topic and we are covering it in series of five shows.
Dmitry Blinov (00:04:21):
How entity resolution is happening on the calculation level. So you basically have two crosswalks with attribute values associated to both of them. You have your survivorship strategies, which define calculation of operational value. You have your resolved object as a result of calculation of the operational values from all existing sources and crosswalks. And basically we have a consolidated profile with operational values and nonoperational values for each of your attributes. Important note is operation value information never persist, never stored in the data storage. It always calculated on the fly and that's important across all functions, everything we talked in the previous shows and going to talk about on this one.
Dmitry Blinov (00:05:16):
So let's talk about data profile a little bit in the details here. This is a summary of everything we discussed and just, the goal of this picture is to create a holistic view for how it all works in general. You have our metadata defined and as part of metadata, we obviously have our data model with all the entity types, attribute types, crosswalk types and other types stuff defined. So this is a simplified, you can keep in mind I didn't put everything in here. You have your match rules and specifically we interested here in survivorship groups, survivorship mapping of the attributes where your specific attribute type is mapped to a specific survivorship strategy from the library of strategies in a specific role. And you can have groups with these rules, right?
Dmitry Blinov (00:06:12):
You have your data storage with a lot of different data here, but specifically you would have your key space where with entity IDs, attribute values, and sources. Again, as shown on the previous slide, attribute values tied to specific sources. And you'll have your user roles and groups defined. In operational value calculator, get the data from the data storage and based on the metadata and specifically on survivorship groups from types and strategies, will calculate on the fly and send to APIs and to UI, if you're doing this through UI, this information to consolidate an entity or consolidated profile, which is again, simplified view. A set of crosswalks with attribute values associated with them, or bind to them and operational value calculator which will define for each attribute which value become operational value, which you see in the profile view in UI.
Dmitry Blinov (00:07:15):
So this is to simplify how it all works. User roles and groups here. And we'll see to them, the demo will define on the API level how your operations like search will work. For example, whether you will be able to find a specific operational value if you search by operational value or not. And it's simplified to you, but it gives you an overall picture of what we discussed on four previous webinars, how it all works and how you get as a result of your metadata, your actual data consolidated into a single entity, we will get your profile view.
Dmitry Blinov (00:07:55):
So next. Again, we've been through the slide before. I'll not stop for long here but in the part of the metadata model, you have your survivorship roles and groups, right? It's a sample group, just copy it based on the actual group. So you will have your [inaudible 00:08:20] survivorship group. You will have your mapping inside of with where your attribute type is mapped to a specific strategy here as I said, right? And the hierarchy there, the strategies in the core of the rule and groups contains this rules, but strategies are taken from a static set of strategies. So group, rule, strategy, how you model this.
Dmitry Blinov (00:08:47):
You have next survivorship strategies split to two groups: data source based strategies, and data or attribute value based strategies. So your strategy is either based on source or the value itself. We've been through them multiple times. I'll just read them, last update date. Source based survivorship strategy, where you define your priority by source and type. Oldest value, difference from last update is last update date is last time you updated all this values, the last time you created this specific piece of data. Other attribute winner crosswalk, where one survivor for one crosswalk values defined from another survivor. WinnerEntityCrosswalk is applied only to the situations where two entities got merged so the winner gets it all, basically winner gets the entity, defines other survivors. And value based strategies. Frequency, most frequent means. Aggregation, everything wins. Minimal value wins, maximum value wins.
Dmitry Blinov (00:09:56):
The survivorship strategies are extended by fallback strategies. And we have two different behaviors in our operational value calculator at the same time. So this slide, it's enhanced slide from one of the previous shows, but basically it explains both, right. Behavior of operational value calculator can be controlled by a parameter in the physical tenant configuration. And for three specific strategies, it can switch between the default behavior and advanced behavior. And below is example of how it all works. So you have two different values. One came from crosswalk A, it's value 10 of some attribute, doesn't really matter. And value eight from another crosswalk for the same attribute. Crosswalks have two different update dates, right? So you will define, as shown on the previous slide you will define a group or a mapping where you map this specific attribute. This value has two specific strategy. Let's say you map it to a last update date strategy, right? So this strategy will define which attribute of the two from two different crosswalks will survive here.
Dmitry Blinov (00:11:16):
If you have a default behavior, in this specific case because it is last update date but update date is the same, both values will survive. In the default behavior, you cannot control anything further from that point forward. You have a hidden, call it hidden fallback strategy, which is really hard to put it in the platform and it works like the first pick. So basically, it'll pick one of the winners and will say well, that's a winner crosswalk and a winner value. And this is why I say here, random crosswalk. It's not random, there is some logic behind, but the key point is you cannot control it, something will win. In the advanced strategy, if you haven't enabled a new tenant, you will have your strategy defined. It will define both value, both winners but then you can define a fallback strategy, basically a next folded level, a strategy for these two winners, right? And finally define the winner which will, if you say my fallback strategy is the max value, obviously this value from crosswalk A wins. So advanced behavior gives you much more control and that's the primary goal to have this advanced behavior.
Dmitry Blinov (00:12:33):
We've been through the fallback strategies. Just to refresh, fallback strategy describes as you saw just on the previous slide, a mapping that will be used over results of the main initial strategy in case main strategy returns a number of winners, not a single winner, but a number of winners. And we have two types of fallback criteria. MORE_THAN_ONE, so basically if I had as in the previous example, two results, two values then MORE_THAN_ONE will definitely kick in the fallback strategy. If I use MORE_THAN_ONE for my max value fallback strategy, then it'll win and the cascade I showed on the previous slide will work. ZERO_OR_MORE is used if none of the values were defined as a survivor, then you basically, nothing was defined as a survivor, but fallback strategy will still work on top of it and define on a different logic now, the survivor for a specific attribute value.
Dmitry Blinov (00:13:37):
We also have other important things, parts of the survivorship metadata configuration. So sourcesForOv block, we talked about it on the very first webinar, but basically you can define this block, sourcesForOv, where you say I want to calculate my operational values only from these sources or these crosswalks. And I kind of narrowed down the calculation to these sources only for this specific group. So you can define this on a group level and in different groups for different attribute types, you can do calculation from different restricted lists of sources.
Chris Detzel (00:14:20):
A quick question Dmitry.
Dmitry Blinov (00:14:21):
Yep.
Chris Detzel (00:14:22):
Will there be new criterias available in the future? So for example, just fallback on zero winners.
Dmitry Blinov (00:14:29):
So we can add that. Obviously we enhance our product constantly. We can add that, so use idea portal, we review and we improve. I know that was some concerns in how we review our ideas, that we don't do it regularly enough, but we improve right now. So just feel free to post ideas on idea portal. Right, if we see the interest, obviously we'll add that. I don't see a lot of work there. So if there are specific use cases, we'll definitely add that, yeah.
Chris Detzel (00:14:58):
So another question. Can be asked at the end of the, oh, okay. I'll ask it then [Sandra 00:15:04], keep going.
Dmitry Blinov (00:15:05):
Okay. Filters is another type of configuration which is important. No but we covered it, I don't remember. I think maybe webinar number three or four. But basically filter splits all values from an attribute by specific filter criteria to different sets of values. So those sets of values can intersect with each other if value meets the condition for different filters. So basically to avoid long explanation, you can say that if my attribute value is this, then I want to apply this strategy for my other attribute value of this attribute value. If my license type exists, then for license number, I want to apply strategy maximum value. If my license type is different, so then for my license number, I want the minimal value to survive. Made up example, but gives you an idea why would you use filter. In red text here is an example of the definition of the filter in the metadata configuration.
Dmitry Blinov (00:16:22):
So again, repeating the same slide, but we've been through this part metadata and specifically this part in yellow here, which defines the entire logic of the operational value calculation, how you calculate each operational value. And then it's important to explain. So in here in these groups, you have the filters, the sources for OV list and mappings between attribute types and your strategies, right? And all that will define for a specific attribute how do I define many values to the specific attribute has which one is a survivor or a winner or an operational value as we call them, right? And then this is how my entity is being consolidated. My consolidated profile is being consolidated. It's really just a bunch of sources stored with attribute values, all of them tied to them.
Dmitry Blinov (00:17:16):
And in here on the data storage, we have no idea which one is winner, which one is loser. We don't have this concept here. We just have a bunch of values, resources, but when a key space kind of unify specific set of sources into an entity, given the unique ID of all the entity. But when we start to consolidate it on the fly, we define which sources will build a specific entity and which values for specific attributes will build operational values for this source. And then when you merge two entities, again, the way two entities got merged, basically all of their attributes consolidated. Attribute values consolidated into a single set of values and then the winner will be defined by the same logic exactly. We don't have any other logic by the same operational value logic.
Dmitry Blinov (00:18:11):
OV operations. Let me do a time check real quick and we are very good on time. I wish I do a better slide, but basically what I did here and instead I'll show something else. What I did here I just listed, I think we used the slide over in the first session, but I just listed all functions where it is important to know how operational value impacts these functions and how they operate. So first, this cleanse, right. In the cleanse definition you can, shown in bold here, define an OV only equals true parameter. And then the cleanse function work in this specific attribute will only consider operational values of this attribute to participate in cleanse. So they basically only operational values will be sent to [inaudible 00:19:04] database, and operational values will be considered to be cleansed and returned back with cleanse crosswalk. Yakov, if you'd like to add anything here, obviously feel free to chime in, maybe you know something I'm kind of missing here. But in a nutshell, that's how it works basically. If you say apply to operational values only, it'll be applied to operational values.
Yakov Goyman (00:19:28):
You're right so there's nothing to add.
Dmitry Blinov (00:19:30):
Okay. Thank you. Operation only search. I'll skip that one because Yakov prepared this as part of the demo, but basically in the UI, when you switch to the advanced search, let me show you. So if I go to this internal tenant and I'll just hope it'll not show anything be done and I'll just quickly switch to a search, it'll force me to log in.
Dmitry Blinov (00:20:10):
It's slightly slow because I'm sharing my screen, but so I switch to a search and I switch to the advanced search, right? As it pops up. Yeah, I'm already here. You see this check box, I can switch to operational values only. And if I do that, my search will be applied only to operational values basically, right? So that's as simple as that, but that's very powerful too, actually. So you'll see some of it in the demo as well.
Dmitry Blinov (00:20:46):
Same thing for operational value export. If you apply that, you will only export your operational values. Same as a search, but basically right now, the export function as we have it, as they call it, it's a saved search. So you do the search and then you save the result, you export the result. So the logic there is pretty much the same.
Dmitry Blinov (00:21:07):
OV-only matching. There is a parameter matchOvOnly, which defines that when you can apply matching logic only to operational values of the specific attributes. And actually for that, I have for this it's our internal documentation but it's a good set of examples built by our QA team. That's just a simple data here. So let's go through some example and steps, I found them very useful. I didn't put them in this separate slide because you can just show them from here. But precondition, I have the next metadata configuration. I can just say match fields URIs and this attribute to the match field. And I want this specific attribute to participate only its operational values in the matching, yeah. To be only operational values of this attribute to participate in the match.
Dmitry Blinov (00:22:06):
So steps in the example, I create an entity. Nested attribute has ignored true due to a nested value has operational value false. Basically I make some specific value to be operational value false given the ignored equals true parameter, which we reviewed in one of the previous sessions when we review UI functionality across operational values, right. Also, nested will become operational. So none of the values are operational in this nest attribute. I create next entity, entity 2 and I make a specific attribute to be operational value equals true there.
Dmitry Blinov (00:22:52):
Then I merge entity one and entity two. As a result in the result in entity after this merge, it'll have two nested attribute values because I used matchOvOnly parameter and nested that are not OV, so basically from entity one, they will not participate in the merge, even if they have the same values for email address attribute. So basically I had two entities with two nested email address. I made one of them OV false and I added parameter matchOvOnly. And as a result, my resulting entity instead of having these two nested, which have the same values so they should merge. Instead of merging, it'll have two separate attribute values, sets of attribute values for nest.
Dmitry Blinov (00:23:49):
I hope it's clear. It's clear to me. If it's not, feel free to ask questions. Yakov, if you see anything kind of useful can be added, feel free to chime in and add. Example two. So again, I said my-
Chris Detzel (00:24:02):
Dmitry. I'm going to ask this question before too many more questions come in, but so will there be future functionality that will allow you to drive survivorship based on the relationship that the given profile participates for the crosswalk? So for example, I would like to trust the values of a crosswalk more if the relationship was owner of a policy versus... I can't read that.
Dmitry Blinov (00:24:34):
No, I think I understand this. I understand this, yeah. So it's a good idea. And I think for when we talk about policies for industries like insurance, it may be even more so maybe this is why this question pops up. Yeah, it's a good idea. I like it. Again, the common answer to this is yes, we are going to keep evolving these library of survivorship strategies and logic for that. And ideas like this as we go deeper into industries like insurance, for example, we definitely need new survivorship strategies to be implemented. So we don't have a specific point in the timeline for that today. I mean, I have a roadmap for the core team between now and the end of this year pretty much, but we definitely are looking into enhancing our survivorship strategy library.
Chris Detzel (00:25:32):
Okay, thank you.
Dmitry Blinov (00:25:34):
Yep. Okay. So example two, matchOvOnly equals true (nested attributes are on the first level of depth / Both nested attributes are operational values). I have conditioned the same as before. Email address attribute, match review only set to true. I create entity one with everything, with all values operational. I create entity two with again, all values operational. I merge the two entities, which without an entity we'll have one nest. So it's an opposite example from the previous one, right? If I have everything operational from in both entities, operational values.
Dmitry Blinov (00:26:13):
And I said I apply matching to OV only, but everything is OV so they will participate in merge and they'll be merged and I will get a result in the one attribute with winning sub attributes and defined by my survivorship. We have examples of how nested survive. There is a special parameter for that as well in the configuration. I think in the webinar number two, we've been through the details of that. So all by the way, I received this question. So all the webinars, videos, and slide decks are shared in our community. So please feel free to refer back to them. And we'll be linking this one as well and sharing it as well.
Dmitry Blinov (00:27:08):
So let's go through example three, and then I'll just stop right there and we will see one more function and probably switch to the demo. So example three, I use the same parameter for matching. I have my nested attributes on second level of depth so basically sub attribute. One of the nested is ignored. So basically operational value equals false for this sub attribute, right? My precondition, I have attribute email and attribute type. Those are sub attributes of the email attribute. I'm not sure why it's not here in the list, anyways. And the same thing here, email and type. Yeah, I don't see any difference.
Dmitry Blinov (00:28:01):
I create entity one with operational values equal true and sub nested become all operational values as well. I create entity two, my first level is operational value. First level nested is operational level, but one of the sub nested is marked as ignored and basically forced to be non operational value, right? I merge the two entities. And as a result, I'll get an entity which has one nested attribute on level one. But there will be when I go to the sub nested level, I'll see two sub nested attributes inside this nested attribute because they didn't merge so I can control it on different level of nested attributes. So I have a single nested attribute again because it merged because everything was operational there. But when I go one level deeper, since I pinned one of the values to be ignored, that value and that attribute in general did not participate in the merge. So I ended up having two sub nested on the second level of the nest. That's how operational value for matching works. And you can see, you can have different variations through that.
Dmitry Blinov (00:29:22):
And last function I'll mention real quick is operational value only for bulk update. And this appeared only since latest release 22.1. You know how we have bulk update function right in our MGM, available right from our MGM UI, where we can select a bulk of entities and update them at once. So from now on, you can also apply operational value logic to this, and only your operational values will get the update. So basically it's like you pin your values pretty much the same logic. You say when I do a bulk update, do not apply calculation, just update my operational values. That was introduced in the latest release.
Dmitry Blinov (00:30:08):
So we'll switch to the demo. And apart from operational values for search in the demo, we'll talk about roles. We just wanted everyone to be on the same page. You know how in our Reltio console, you have user management application where you can define roles. These are my roles, this is my user, and these are basically my roles. So these are the roles we're talking about regarding the calculation of the operational values. I'll stop sharing and Yakov, you can start sharing now.
Yakov Goyman (00:30:49):
Okay. Hello guys. And good morning. I'm going to share my screen. Please make sure that you can see it. Okay. And I have, again, many windows opened, many browsers opened because we have three different roles and three different users which those roles belongs to. And I'm going to create some entity, update it twice. And it doesn't matter which role used to update, the result of how entity looks like with different preparation values because different roles has its own survivorship mapping. So previously we had some configuration where each attribute has its own attribute mapping, survivorship mapping. So it allow it to map some strategy to some attribute, how to calculate it.
Yakov Goyman (00:31:56):
Now I will show you how to map the set of rules to some role and role belong to some user. So here we have very simplified config. On the right side, we see the same config, but already predefined. And we see that in meta configuration of entity [type HCP 00:32:30] has survivorship groups. Often here's only one element of the [CRA 00:32:38] and now we have three. Please pay attention that for item number one, we have default equals true. It means that survivorship groups with URI blah, blah, blah, survivorship default is really default. And it's applied to any attribute, to any role.
Yakov Goyman (00:33:04):
But if you have some overrides of those mapping and you have to specify some special behavior for some user with some role, you have to specify another survivorship group mapping. So this is not small. The first one, because it's default, it used to customize mapping for all attributes, but for number one and number two, we have this mapping not default. You see it's false, and the name has role API. It doesn't matter what the name is. The makes sense, this thing inside this section roles. It's again array which roles those survivorship will be applied to. So one of them applied to role API and second applied to role workflow.
Yakov Goyman (00:34:21):
It's interesting what is inside this mapping. There's pretty small piece of configuration. One of them is attribute name. For role API, it calculated as min value. For role workflow, it calculated as max value. Again, our attribute is name, one role has max value, another role has min value. And the full behavior, it's difficult to find here because there are many lines and I will show you on the left.
Yakov Goyman (00:35:10):
On the left, the default behavior for name is [SRC_CSS 00:35:13], I derived with this example from our previous session, session number three. And there was some interesting thing how we can calculate SRC_CSS without providing sources [inaudible 00:35:30] right order. So I use it the same example. And if you have some time, I will show you some interesting scene. We will do some fallback strategy on the fly, but now we're speaking about role and mappings. So let's go back to our API. We have our clean talent, I deleted everything, and I have to be authorized as me. So sending request to authorize as me, I have my own role, which doesn't include any role API or old workflow.
Yakov Goyman (00:36:12):
And now I'm going to create the entity. We have prepared three different entities. All of them are very small and one of them has only name one [mic 00:36:24]. Second should be glued to first one by crosswalk, by data provider force to same crosswalk as in first one, it has some name nine Michael sending it. And as a result, we can see that we have two values and both of them, of it through, we will return to this later. I just want to send third one. And sending the suit will give us these latest two _mic as [inaudible 00:37:14] and both previous are losers.
Yakov Goyman (00:37:18):
So just remember that when I'm looking this entity under my talking, which is connected to my own role, which not of two of them listed in not default survivorship group mappings, I have these two _mic as winner, as operation value and both others are not operation values. Okay here, I have prepared also another authorization request. One of them return me authorization talking for user, which has role API. And second will return me authorization talking for role workflow. So sending it and trying to get exact this entity. So here I have some search and let's check which value is winner now. So you can see that when I use it role with name role API, it returns me name attribute with operation value, which started from one. I specifically, I intentionally made those name started with one, two, and nine in order to be easily sort it alphabetically. So here, because we have only one value alphabetical sort or lexicographical source is the same as numerical sort or mathematical.
Dmitry Blinov (00:39:10):
Yakov, I have a question. Would it make sense to explain or you plan to explain it later. When you first posted the three values, the source operational, source CSS or source system survivorship strategy was applied. And this is why two mic survived because of its crosswalk.
Yakov Goyman (00:39:32):
Yeah, because there was a number of crosswalk and I will return it to it later. You just need to remember that for my own role, which has default survivorship group mapping, the winner is two mic. But for another role, which I get in the same entity, which has all those three values, the winner value is one mic. So here I prepares the browser, which already connected to... Okay, here is my own. You see this is Y, because I'm Yakov. So let's get a entity ID and try to search it here in UI. Copying this, paste in here.
Dmitry Blinov (00:40:27):
And this is how search is applied operation wise, basically.
Yakov Goyman (00:40:31):
No, there's something different. So this is not a search because there's a-
Dmitry Blinov (00:40:35):
You're right. It's research by idea. You're right, yeah.
Yakov Goyman (00:40:38):
So again, I will you how the search is applied, but I will show not in UI, but in API calls because it's more understandable. So here's, again, we see my own profile and two mic, I have another browser which is incognito mode and I connected with you see A, A is auto blah, blah, blah. And the interesting here is, has user role workflow. Workflow has a maximum value. So let's search for same UI here.
Dmitry Blinov (00:41:20):
It's the same tenant, same entity, but different user.
Yakov Goyman (00:41:23):
Yes, and different user can see different operation value because the strategy mapping to this name attribute is different. For me, it was SRC CSS, for this role it has maximum value so maximum is win. So let's go to profile view, sources view to check other values which are losers. Why it's not appeared. Okay. Back and forth, switching back and forth again right here. Okay.
Dmitry Blinov (00:42:11):
I think maybe let it, give it a time. I don't know. No. you actually, you have click on the right side arrow in the right top corner. Right top corner there is a little arrow.
Yakov Goyman (00:42:24):
Ah, okay.
Dmitry Blinov (00:42:26):
Okay. Yeah, I'm not sure why you don't see results. I think it's not at this time may not be configured, but we see sources here, right?
Yakov Goyman (00:42:37):
Yeah. Basically see sources so there's the same entity. Okay, and I have third browser which is Firefox and here I configure connection by third user, which has raw API, which connected as min value. Okay, let's open again here same profile. Same profile as here and we can see that value with minimum lexicographical value is operation value.
Dmitry Blinov (00:43:15):
Yeah. So just to reiterate on what Yakov just showed and what we showed on the slide deck as well, you can tie a specific user role to a survivorship mapping group which basically says that if user has this role then calculate operational value using of this logic. User has that role, I calculate operation value with that logic. And if user has none of these roles calculate operational value by default logic, right. And what we show here is in the same tenant, the same consolidated profile is consolidated in three different ways, just based on the role of the user. So three different users will see three different profiles, at least three different values in the same profile. So for them, if it's name, the healthcare professional may have three different names even. It's an artificial example but basically if you... I mean, we have a lot of real use cases where based on the role, you would see different information in your profiles because well, it's your use case. You can do that. You can have flexibility and that is-
Yakov Goyman (00:44:29):
You even can restrict to see some information by role [crosstalk 00:44:33].
Dmitry Blinov (00:44:32):
That's even more [crosstalk 00:44:35].
Yakov Goyman (00:44:34):
Personal value.
Dmitry Blinov (00:44:35):
Yeah. And that's even more popular use case because you can basically restrict if your operator should see only part of the information. By region for example, you can create regional roles, you can assign them and basically restrict the visibility into profiles using the roles, right. And all this is possible because again, on the persistence layer in the database, we store only crosswalks and attributes. And we consolidate profile. We build the profile every time on the flight. So basically it is constructed based on the data from the data storage based on the metadata that defines the structure. And based on the role you have as a user, a calculator gets all these three pieces of information, do some magic and shows you the result profile. And this do some magic is what we've been through the five webinars so far, [crosstalk 00:45:35].
Yakov Goyman (00:45:35):
I should mention that it's very powerful functionality and it can be very flexible with all our flexible rules and with this role differentiation between mappings and users, it's very, very, very, very flexible. Even each user can have many roles, not only one. It's not tied to user, it's tied to role and many roles can be applied to one user. Yes, Chris.
Chris Detzel (00:46:02):
I think you might have answered one of the questions, but can the role based survivorship rules also be applied to security groups?
Dmitry Blinov (00:46:12):
[Mark 00:46:12], if you talk about security groups in regards to what I just showed before the demo right, these user management groups I had, then the answer is yes, they are tied to the group.
Speaker 4 (00:46:22):
[inaudible 00:46:22].
Yakov Goyman (00:46:26):
Okay. Let's continue.
Chris Detzel (00:46:28):
Couple more questions guys, sorry. Also, what happens if specific users, and you might have answered this, has multiple roles where more than one has different survivorship rules defined?
Dmitry Blinov (00:46:40):
I think Yakov, please answer this one.
Yakov Goyman (00:46:45):
I have to check how it would be calculated. But I think that first group which has condition with role of user. First group with [inaudible 00:46:59] found will be used as a role for operation value calculation.
Dmitry Blinov (00:47:06):
I think it's an overall logic we have. We had the same question when we were talking about filters because you can have the same filter conditions in two different groups, right? So the logic is always first one wins and it's logical because you have your list of groups or in this case, list of groups by filter, or in this case list of groups by roles and your task is to define operational value. So the first one that meets the condition and gives you the operational value basically gives you that and calculation stop right there. And you don't read the entire, the remaining part of the configuration.
Chris Detzel (00:47:47):
So another question, last one for now. Is there an API to retrieve an entity by specifying a survivorship group? So for use in an integration.
Dmitry Blinov (00:47:51):
Yeah. Question from Ashley, if you have to retrieve an entity by specifying, [crosstalk 00:47:54].
Yakov Goyman (00:47:54):
Answer is there is no explicit API. Yes. You have some token and implicitly you can use in this token type connected to some role. But you will see the same as you can see in UI. So you are not able provide the role, the survivorship group name, or UI of the group to calculate exactly with this survivorship.
Dmitry Blinov (00:48:34):
I'd like to understand more of the use case for that because it's an interesting question. I never thought about this, but I'd like to understand more the use case. Maybe we can take it offline if you can just let me know what type of.
Ashley Branham (00:48:47):
Just ping [inaudible 00:48:49], we can tab.
Dmitry Blinov (00:48:49):
It's interesting. Thank you.
Chris Detzel (00:48:51):
Thanks guys.
Yakov Goyman (00:48:51):
Okay. Can I continue?
Chris Detzel (00:48:56):
Please.
Yakov Goyman (00:48:57):
Okay. So go back to our Postman and again, make sure that we have authorized by some role. So again, I'm trying to authorize by some, okay. Let's move to left to right. We have three different authorization, token requests. So sending it as me, as you remember that two mic is winner and we want to search by OV. So how to search by OV, we have in our query parameter some different query parameter which change behavior, how the entity gets searched, options. I specifically has this mistake here. I removed this S to just ignore this option prior, because option is not familiar to a platform, but options with S on the end is familiar. And when options has search by OV and filter, it has some filter, where attribute name equals nine [Michael 00:50:17]. So we are trying to find with my own role where we remember from prerequisite, that I have two _mic as winner. Okay, let's search and it should return empty result. Yes. Okay.
Dmitry Blinov (00:50:39):
Nothing was found for-
Yakov Goyman (00:50:42):
Because my role has two _mic as of variation value and no others. Okay. I have copied all my values here. Let's check for one mic and it should also turn the result. And let's search for two mic. Yes and now it returned. And again, you see that it has operation will be true. And others is false, okay. Let's go fast to another authorization again.
Dmitry Blinov (00:51:23):
Can we do one trick before we go there? Yeah, can you go back to the search?
Yakov Goyman (00:51:26):
Mm-hmm (affirmative).
Dmitry Blinov (00:51:30):
Remove options or remove the S so it doesn't use, you only end use some other value like nine. Yeah. Nine [inaudible 00:51:44], yeah. So obviously if you search across all values, it will still find the record. Right? So because all operational and non operational values-
Yakov Goyman (00:51:54):
This [crosstalk 00:51:55] is just ignored because-
Dmitry Blinov (00:51:55):
But it's important to understand that always operational and non operation values are indexed. So again, to repeat all storages, we have contain only values. They don't contain the information which one is operational, which one not. Even for the index, it is calculated on the fly. So if you don't search by operational value only, you will obviously find your entity by any value of a specific attribute, operation or non operation, doesn't matter. Thank you. Please continue.
Yakov Goyman (00:52:27):
Okay. So continue to another oral API sent. So I am another user and again, engage an entity by ID. Put again, options with S. Sending request. So we have empty result because winner is one. I don't remember how it correctly spelled. Yes, this is winner and previous is one didn't one. I don't want to check third one. So we have some time and I want to show you some example which not related to roles, but it's related to fallbacks. Yeah, again-
Chris Detzel (00:53:15):
Can I ask a quick question? I don't know how quick it is, but when you using roles in survivorship, how does that affect match rules? So for example, if there's a match attribute where the OV value is based on a user's role, how does it impact matching? Does it show different population of consolidated profiles based on their user role?
Dmitry Blinov (00:53:40):
I think I'm not the subject matter expert in matching, but I think again, the matching itself. So how the matching, high level, I may skip a couple of important steps here, but how matching in general works, we have different types of matching. But to simplify, you can match and merge by crosswalk because crosswalk is unique or by match rule, right? And your match rule is again to simplify some logic risk, which says if I have these attribute values and that attribute values, then my two entities have the same, merges and merge them. So I don't think you apply operational values in the match rule. You basically, you don't. You just say which attributes to check for the matching and which logic to apply, like strict match or [inaudible 00:54:35] match or something like that. But then how the entities will be merged is completely defined by operational value calculator. And as a result by every single use we talk so matching is not impacted by this logic in roles as well but the merging logic is.
Yakov Goyman (00:54:54):
I think the merging logic of nest attributes, because other attributes is not affected by much of you only or not.
Dmitry Blinov (00:55:02):
Yeah, you're right. But anyways, my point was when you merge your entities, it is important that you use this match and we've been through examples, but when you match, you create a match token, right. Which will be stored in the secondary storage and will define the two entities, match and are merged, basically should be merged. You do not apply operational value logics there, you just define which attributes to check and how to define, to create much talking basically. Yeah.
Chris Detzel (00:55:32):
Great. So we got three minutes guys.
Yakov Goyman (00:55:34):
Okay. Very quick, brief example. So clean our tenant, delete entities by type, deleting it. Creating a task for deletion. Yeah, I think the task already executed and finished. And we again, going to create the same three items, even not three, two, because the example is really only for first of them. So I again authorized it, should be authorized as me and send entity one, okay. So that has only one which true and sending second entity and both of them are having OV true, so let's go back to our configuration here. We have a name, it should be name SRC CSS, I don't see it.
Dmitry Blinov (00:56:41):
Try to search the name.
Yakov Goyman (00:56:41):
Okay. Here is it. We have. so we have an now default profile name with SRC CSS strategy and no sources UI order. And the result of two OV values, because we have one source from [CRM soft 00:57:06] and second from [IMS plan 00:57:06], both of them has priority equal 10, which is equal priority and both values are winning. So it's not desired behavior for me. I always want to have only one winner. So let's go and check the rule. The rule is name for name is survivorship and no fallback provided. So here I have very simple snippet, which I going to add to configuration.
Dmitry Blinov (00:57:47):
So adding fallback strategy on top of survivorship strategy.
Yakov Goyman (00:57:50):
Yeah. So here we have some section for fallback strategies and we have a load as [LEDS 00:57:57]. So latest value should be in if parent strategy has more than one winner. Okay, copying it, posting it here. Changing configuration. Configuration got applied and getting entity again. So we have, they just pair the result. So now we have, again, those two values and the first one which I sent is OV false and second is OV true. So on first level of operation value calculation, we got by SRCC strategy two different winners. By fallback reason criteria, more than one criteria. We have more than one, obviously we have more than one winner and fallback strategies apply for work strategy is [LUD 00:59:11]. First I send one mic and is more recent is nine Michael, therefore nine Michael is win.
Dmitry Blinov (00:59:21):
Yeah. Thank you. Thank you, Yakov. That last one was kind of a wrap up example, not related specifically to the data [inaudible 00:59:31] roles, but basically again, reminder of how the survivorship groups can be structured and not usually as structured, right. And what gives them the power, all these fallback strategies. And then you can decorate them with filters, with source groups, with even sort groups with scores like Yakov showed again today where you can put a score again across each specific source. And it gives you a lot of flexibility on that level. Plus you can have additional layer of flexibility with roles. You can hide part of the data, you can show different data to different groups of users even with that. I think we have wrapping up set of shows for operational values, survivorship rules and everything, those kind. I think we covered 99.9%, I cannot think of anything we didn't cover here. We repeated a lot of examples. We've been through a lot of demos, I think. Well, again, sometimes it's hard to consume this demos because we go through a lot of little numbers and letters in the Jason file and it's hard, but this is really how you can and the flexibility of doing pretty much anything with your data, using our metadata model.
Dmitry Blinov (01:00:59):
That is it. Thank you all for your attention, staying late with us.
Chris Detzel (01:01:03):
Yep. All right. Thanks everyone. And Dmitry will be back at some point to do a host of other webinars or shows. So we'll see you on the community and we'll see you next week for the next show. So thank you everyone. Thank you, Dmitry and thank you Yakov. Really do appreciate the time and effort that you put into these demos.
Dmitry Blinov (01:01:26):
Thank you.
Yakov Goyman (01:01:26):
Okay. Bye.
#CommunityWebinar