 Okay, going live. Okay, hello everyone. Welcome back on Sanjay Gupta Tech School. So today we are having episode number three for this Salesforce Homeless Studio Bootcamp. And as you all know, in this bootcamp, we are actually focusing on the scenario implementation so that you have a complete playlist where only we are solving scenarios one by one with respect to each topic. So initially like there will be total four sessions targeting data adapter. So this is the third session in that series. And I have Abhishek with me once again. So welcome Abhishek on the platform. So he will be solving three scenarios in front of you. And through those scenarios, you will be learning like how you can implement data adapter. And all these scenarios that he's actually implementing. So those we gave you as an assignment in the season one where we like explained you the concepts, right? So if you were unable to solve those scenarios, so this is the great opportunity for you. So here one by one each scenarios, Abhishek is solving so that you can follow those. And in your org you can implement their solutions also. Okay, so with this note over to you Abhishek. Yeah. Thank you Sanjay. So hi everyone myself Abhishek and I'm working as a Salesforce and Velocity developer in Salesforce domain since five plus years now. And I have done some certifications around Velocity slash Omni Studio. So which is one of them is Omni Studio developer and some industry specific certification also I have done. Like first is industry CPQN and there is a health coding developer which is from the Velocity. And there are some Salesforce certifications as well. And yeah, that's all about it. Okay, thank you for this Abhishek. And thank you for sharing your knowledge with the community. And if you guys want to become part of the group where lots of freshers and experienced professionals those are from different background or want to jump into Salesforce ecosystem. So they are learning. So you can also become part of this group. And once you join this group, so like if you have any question or you want to share any knowledge so you can utilize this group. And going forward on the next slide. So if you want to share some review or feedback about the bootcamp, so that is welcome. Okay, so I think now we can jump on to the scenarios. So these are the three scenarios that Abhishek will be solving and all three scenarios are different. So let's start with the session. Yeah, first of all, we're gonna solve we're gonna implement one scenario where we want to fetch some account and contact records with the specific record types, right? So we'll go to our org and I only just told you the application. Come there, we'll create a new data rector. Create one data rector. So let's say I'm gonna call it data rector extract account records with record type. So for this guys prerequisite will be like you need to make sure you have record types already created. Yep, so if I go to account object and if I check if I have any record types or not, I should be having one record type on an account object which is, I think SGT is here. So I have created one record type and let's go back to the data rector. So fetching records specific to any record type, there are multiple ways of doing it. So first of all, we're gonna implement one scenario where the record type ID will be the hard-coded ID. So let's say I'm gonna say account here accounts and here I'm gonna say record type ID and it should be equals to the record type ID that we want. So what I'm gonna do, I'm gonna just query the record type ID. This is my record type ID for SGT S. And I'm gonna hard-code the record type ID over here and simply we'll just create one mapping or two mappings so that we'll get some results. So first mapping is accounts, colon, accounts, colon name. Second would be we're gonna get the record type name as well. So if you remember from the previous session, if you want to go to parent record, right, from the child record, you can use the relationship name with the dot operator. So in that case, I'm gonna say record type, which is the relationship name. And this is the relationship that we do not create on any object. This will be created by Salesforce itself. And that's, I'm gonna say, give me the record type name. Okay, here I want the record type name. And if I go to preview and click execute, it will give me all the accounts whose record type is SGT S. Right? But with this data actor, there is a limitation. If I deploy this data actor into the upper environment or the broad environment, then this hard-code ID, we need to change it, right? So that is not a good example. So for, I mean, this is one way of doing it, but we can optimize it more or we can improve the data actor. So for that, what we're gonna do is, we're gonna query the record type, record type ID. So for that one, we're gonna query on the record type object and let's say I'm gonna call it ECC record type. So one thing I want to add here, guys. So record type is a setup object. So in object manager, you won't find this object, but record type itself is an object. So in this list, you will be able to find it. So if you try to find record type object in the object manager, so it might be missing there because few setup objects are not available in the object manager. So here it is available and all the fields also you can see. So I mean, this is the object that we're querying. This is that set output path. And here we're gonna say the name should be equals to, now we can hard code it, which will be SGTS. One more thing. In the filters, in the filter option pick list, so all these are the field API names for that record type object. Yeah, so. So I mean, with this where clause or the filter criteria, we will add the filter criteria on the SGTS record type. So because the name will be similar into each and every environment, that will not gonna change. And it could be possible, like if you have worked upon on the data modeling of Salesforce, we can create the same record type name on different objects. So let's say SGTS, we have it on the account as well as we can have the same name on the contact. So for that, we, oh, sorry. We will add one more filter criteria. So that will be, that will be gonna say, as object type, there is a field on record type object, which should be account, okay? Or, can we prefer developer name? Yeah, but developer name can also be the same. Yeah, okay. Right? So, and we're gonna drag and drag this, expect step before the account, and we're gonna use it over here. We will say, ECC record type ID, colon ID. So basically, now this will give us the record type ID with the help of this query and that result of this query, we're gonna use it into the second step. Okay? And if I go to preview and click execute, again, I'm getting the same records. But on the right-hand side, you can see there is another query which have been implemented. Select ID name as object type from record type where name is equals to SGTS and as object equals to account. And whatever result we are receiving from here, we are using that record type ID into the second query or the second extract step, which is now dynamic. Yeah, right. Right? And there is, we can further improve this data actor because as you all can see, we can reach out to parent object record with the help of child record, right? So if I'm, what I'm gonna do, I'm gonna clone this one so that we will have the working copy of this. So now what I'm gonna do here, instead of typing record type ID, I'm gonna directly say here record type.name because the fields that we were able to get it in the output tab from child to parent, we can also have it into the filter criteria as well. And here we are, I'm gonna say SGTS. So now if I delete this first step, this is no longer required. If I go to preview and click execute, I'm gonna get the same results. Okay, so. This is another improved version of this data record. Okay, so unnecessary, we don't need to write like two blocks, two extract steps in one step only we can query, right? Correct. Okay, so this is the best version, like you explained three scenarios, so this is the best case. Correct. So here, like that ID change won't be impacted because we are using name and it is like, if we deploy, so from one environment to another, like name won't be changing, so it will work in that case. Right. Perfect. So moving on to the another example, which is the second where we are seeing fetch all the account records where rating is hot, also apply below formula to filter the extracted list. So basically here what we are doing is, we are not adding a filter criteria on active field, we are just adding the filter criteria on rating field and we want to filter all the accounts where active is equals to no, but with the help of formula tab, not with the help of filter criteria, right? So in this example, we're gonna see how formula tab works. I'm gonna create a new data rector again and again we're gonna call it accounts records formula. This is simple, here we're gonna say rating is equals to hot and if I go to output, I'm gonna get the fetch the accounts I mean like the name field as well as the hot, sorry, that active field, also we're gonna fetch the rating field as well, so that, okay, go to preview, click execute. So this is giving me all the accounts whose rating is hot, but it is mixed right now. Some of, for some of the accounts active is no and for some of the accounts active is yes. So I mean again, there are two ways of doing it. First is we can simply add the filter criteria over here, but we don't want to do it, we're gonna do it with the help of formula. So here we will use one function which is mentioned into the slides as well. So here what we are saying, filter, so whatever result we are getting in the accounts, accounts extract JSON path, just filter out them and then these same codes we need to write again. Yeah, yeah, so and for filtering the list what we want to do is just give me all the accounts where active is equals to no. Let's say I'm gonna fetch the same records, I mean like according to the result we're gonna get now, one, two and three. We will be getting three results. So those three results we can fetch it into the new node as well as the same node because the original output is coming into the accounts node and whatever data we are filtering, we can keep the same name as well as we can keep the new name. So let's say I'm gonna call it as a new name, accounts new and if I go to preview and click execute, it will still give me the same output because we are having the new name over here. So what I'm gonna do, I'm gonna say accounts new colon new. So all the mappings we need to modify, right? No, I mean that filter function gave us the new list as a result. So if I go to preview and click execute, yeah, I mean like for accounts new we have to create all the mappings. Yeah, that's what I'm saying, yeah. Yeah, yeah. But right now like if I see where account is, account activity equals to now, first is United Oil, second is Edge Communication and third is Test Ability. So these three accounts coming into the accounting. Right. So a new node is created and it is having different results, yeah. Correct. So if you want the rating output as well for the new, so you can do this. You have to create a new mapping for all of them. Click execute, now you will get the rating as well. So in this case, Right. In this case we can delete that accounts list also and we can keep this accounts new list because it is actually having all the results. Correct. By any chance we can have the same name, like it will update or what? I mean, it should update. So if I keep the same name. Yeah, maybe if we can give it a try, so let's see what happens. So I'm gonna disable the new mapping because now it's not required. Right. And if I go to preview and click execute, it should give me the, okay. Yeah, so maybe. So basically. That is not editable in that case. Yeah. Okay. So, Because what it is doing, it is kind of multiplying all the results. Okay. So you see, when United Oil is coming for four times that's communication, then test to be. So basically it is filtering out all the results. And so, as you can see all the active is no, but that is getting multiplied by the number of records. So it would be better if we create a new name. Correct. Yeah. Right. Okay. Yep. Let's go to the final scenario where we are seeing which account records we are rating not equals to null and apply the below formula to populate yes or no. And the below formula is name is not blank and annual revenue is greater than equals to one lakh than populate yes, otherwise populate no in the active. So it doesn't matter what actual value we have onto the record. We want to modify it within the data rector formula like that. Right. Correct. So we're going to use the same data rector. I'm going to add the new mapping again so that it should be modified and that whenever I go to print them, it is given in the correct result. Now, according to the question, we want to fetch all the records where rating is equals to not equals to null. So here we're going to say not equals to a blank value. So now it will give me all the results. Active is not active is no because we have still had this formula, right? Yeah. And according to formula, what we need to do is if name is not blank and animal revenue is greater than greater than equals to one lakh, then populate yes into the active, otherwise populate no into the active. So we're going to modify this formula by saying let's say if, so we are getting our results into the accounts note, accounts colon name not equals to blank and accounts colon let me pick up the VPN name for this one. If the animal revenue is greater than equals to one lakh, then give me a yes value. So it will basically override the field value that is available on the record. Correct. For that one, what we're going to do is we will say accounts colon active. Okay. So now what will happen, I'll explain you. So first of all, original results is going to come into the accounts note, right? And in the formula, we are saying if accounts colon name not equals to null and accounts colon animal revenue is greater than equals to one lakh, then give me a yes or no value, right? Right. And even we have to keep it in double quotes because it's a string value. So this will just give us yes or no. Now it's onto us whether we want to save it into in which field we want to save it. Okay. So what I'm saying, let's say originally for this current account, active is coming as yes. Okay. But with this condition, it is becoming no. So for that account, it is going to change the value from yes to no. So basically data rector is working like a loop. Right. Right. And so whatever number of records are there. So for each record, this will execute. Right. So I think we don't need this new one here. This is active, new that we already have. And here we are going to remove the new. And for the last one, we are going to delete it. And if I go to prego and click execute. So as you can see, wherever the value is greater than one lakh, the value is yes. So for example, let's say for this grand hotels and resort limited, I'm going to change it, change it manually, less than one lakh. Okay. So that we will be able to identify. Maybe we can check the active value, whether it is. Yeah. Okay. Yeah. So this is, yeah. This is no. And into the, sorry. Into the results, we are having the values yes. Yeah. It means the actual field values being overridden and whatever we are setting from the formula, it is working. Correct. So if I, if I reiterate this one just for the, more understanding purpose, the original result is coming over here. Now one by one, the data rector is executing a loop onto the account list. And it is checking if this condition is getting fulfilled, then give me a yes value or no value. And on that particular record, whatever value it was having before, whether it is yes or no, it is going to replace with this formula. And then we are having the simple mappings for them and in the output we are receiving the results. Right. And one more thing, whatever actor value we are getting through the formula, this will be displayed in the data rector itself. It won't be updated actual record. This also we need to keep in mind. Okay, and here one observation. So in previous example, we used accounts new, but here in this example, we are using the same name. So in case of loop, if we are iterating on all the records, it means we can use the same name because we are referencing particular field. But yeah, if you are storing it into the, into the form of list, so then we need to use the new name. Correct. I mean, like for that, there is a reason also because here it is execute, we are executing the loop onto the same list, right? But with the help of filter formula, the filter formula will always give you a new list. Right. That is why we use the new list name and here we are just update. So basically here we are just updating the list value for this account list. We are not creating any sort of new list. Right, got it. Yep. So I think these are the scenarios that we were supposed to cover. Yep. Exactly. Yep. I think all the scenarios were very interesting and like different things you explained. So in our previous season one, like those who were facing any issue in solving these, sorry, so now they will be having all the solutions with them so that if anybody is getting stuck in the understanding the concept. So this was the basic idea, like we discussed earlier, like if people are facing difficulty in solving scenarios, so we need to share them solutions and like in Omni studio, we cannot create a document because we need to provide lots of screenshots. So it is better to explain in form of video so that anybody can watch it again and again and understand. So that is the best way of learning nowadays. Okay. And also like the examples that we are explaining in the videos in these sessions, they are on a good level. These are not sort of beginners example. These are some sort of advanced level example. So it would be good. If you all guys will practice by yourself at your end. Yeah, perfectly. So I'm sure like if you watch all the concept related videos and then you follow all these scenario implementation, so you will be having enough knowledge end to end about the Omni studio. So once all the scenarios will be completed, so we have planned some end to end scenarios also. We're starting from like data rector, IP, flex card and Omni script. Everything will be implemented together in one scenario itself. So those sessions will be called like project implementation. So we will do that as well. So let's see how long these sessions will go. So we will be having one more session on data rector then we will jump onto the IP and other stuff. Okay. So I think this is it for today guys. Thank you Abhishek for sharing your knowledge. And I think next session you will be delivering from Australia. So soon Abhishek is moving to Australia. So I'm trying to map the time because it is like five or 30 minutes different. So different. So I think next week onwards we'll be having sessions little earlier. So it will be like five, 30 PM IST. So, okay. So thank you so much Abhishek for sharing all the knowledge. So as you are traveling, so let's have session next week then. Okay. Okay. Thank you. Bye everyone.