 Hello everyone. I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So today we are having day 7 of Salesforce Omni Studio Bootcamp. And I have Abhishek with me. So welcome Abhishek on the channel. And before proceeding further, I can see like lots of folks are liking the sessions which we are delivering. I can see the comments in the YouTube and with the help of scenarios, we are trying to explain each and every concept of Salesforce Omni Studio. So I hope till now whatever sessions we have delivered, you have practiced them. And for your reference, I have created session exercise sheet as well. So if you go to the session tracker, there you will find that link. So you can follow those questions and scenarios. So do practice for those scenarios so that you can understand Omni Studio well. And so far like we have covered data raptor. And in today's session Abhishek will deep dive into IP. So he will be explaining what IP is. IP is basically integration procedure. So today we will be discussing about those and then few hands on will be doing on IP so that you can understand. So this is the agenda for today's session. So now I just hand over Mike to Abhishek so that he can introduce himself. Because I know in every session, lots of new folks are joining. So Abhishek, please go ahead and please introduce yourself. Thank you, Sanjay for giving this opportunity. So hi everyone. I hope you all are doing well. So myself Abhishek and I'm working as a Salesforce and velocity developer in Salesforce community. And I have overall of five plus years of experience and I am at trailer double star ranger. And I have done some certifications around on Salesforce like Omni Studio developers, CPQ specialist, service cloud consultant, PD-1 and administrator. And I have done several projects around Salesforce and velocity and velocity industries as well like health insurance, telecommunication industry, CPQ. So that's all about. Okay. Thank you Abhishek for this introduction. So moving forward, like if you want to become part of a community where lots of freshers and experienced professionals are connected and they are interacting with each other so that they can help like each other resolving some issues and problems. So you can scan this QR code and you can part of that group. Moving forward, if you want to receive timely notification, you can follow Sanjay Gupta Tech School on YouTube, LinkedIn, Instagram and telegram. And the session tracker link is available in the video description so you can follow all the session if you have missed any. And please keep providing feedback and reviews because these motivates us, right? So with this, like I pass it on to Abhishek. So please start with the session and like explain everybody what IEP is and what is the uses of IEP in Omni Studio. Over to you Abhishek. Yeah, sure, Sanjay. So till in our Omni Studio bootcamp till now we have covered all the data lepers and data leper types. So we will take a step back whenever we are building some functionality, right? So as we have discussed in previous sessions, like we need three things. First is database, second is business logic to write and third one is UI or the user interface, right? So till now we have covered the database part with the help of data lepers. Now what we will be doing is we will be creating some business logic around it so that whatever data that we want to retrieve or save it to the database, we can perform some logics here and there. The same way when we are using the SQL and we are writing it into the Apex class, right? So in Apex class we use some for loops, if well conditions, try catch blobs, right? To perform some business logic or to do some sort of validations and all these things, right? So whenever we talk about performing the business logic into the Omni Studio, we talk about integration procedures. So don't get confused with the integration word. This is not something where you will be like, this is not something where we will be doing integrations like we do in the Apex class, right? So the name is integration procedure but it has some relevance to integrations, but it's not all about the integrations or connecting with the third party application, okay? So let's move on to the next slide. Yeah, so Abhishek, I just want to add one thing like Sunil is asking one question and I think it is related to IP. So he's asking like after updating account phone, it should be automatically updating related contact phone like trigger. So he's asking, is it possible in DR, data wrapper? So I think it is possible in IP, not in DR, right? I think we can do with the data refters as well. So yeah, I mean like for connect, I mean we will be using two data refters. First is data refter extract and second is data refter loop, right? So from the first one what we will be doing is we will be getting all the information from account and related context for that account. And in the second data refter, we will be updating the phone number. So for connecting those two data refters, we need to create an IP. Okay, so IP will be involved in this scenario, right? Yeah, yeah. Okay, so I hope Sunil, we are able to answer your question. So when you will be having enough insight about IP and along with data refter that is already there. So you will be able to implement solution for this problem. Yeah. Okay, yeah, please go ahead. So let's move on to the next slide. So we were talking about integration procedures, right? So a primary component in Omni Studio service management layer. So as we have discussed, integration procedure will not do something with the databases directly, but it will provide a service management layer between the UI interface and the packet. And used to read and write from Salesforce as well as external system. So let's say if you want to communicate with third party application, right? So you cannot do it directly with the help of data refters, right? Like if you want to call it a third party application in Salesforce, you cannot do with the help of SOQL, you cannot do with the help of DML. You have to write some epics logic behind it. So that's the same thing we can do in the IP. If you want to connect with some third party application, you want to post some data or you want to retrieve some data from third party application, we can use the integration procedures for that. And integrations procedures can be called out from Omni Scripts, Flexcard and EPI or Epics method. So if you want to call your integration procedures, these are the places from where you can call it like Omni Script, Flexcard. We can call it from EPI or we can call the integration procedure from Epics method as well. Okay, but if we talk about Omni Studio, so I think Omni Script and Flexcard will be using IP mostly. Yeah, that's correct. So need of the integration procedure is if you want to, if you're accessing and transforming data, right? If you want to get it from third party applications with the help of Omni Studio tools, we have to call, we have to use the integration procedure. And let's say if you don't want any sort of user interaction, for example, whenever you are, so for example, you are creating a user interface where you are getting the information of account, but at the back end you want to insert one contact as well for that, right? So that kind of thing we can do with the help of integration procedures. Like user will be giving us only the account information. Now if you want to insert contact at the back end, we can do with the help of integration procedures. And when moving the workload from client to servers is desirable. And this is as simple as that. I mean, we are creating the user interface and we are saving some data to the databases. And when declarative solutions is required for the problem, like if you want to use some for loop, if you want to use some if else block, all these things. And it will process all the functionality on the server side. And then execute multiple action in a single server call. So for example, we have created one user interface with the help of Omniscript, right? And now what I want to do is I want to create one account, I want to call one API or third party application, and I want to retrieve some data from opportunity. So all these things can be combined into one integration procedure and that can be handled in one server side call only, right? So that's the power that integration procedure has. And in simple words, we can say, IP is a way to get, say, manipulate data in the background. So this is kind of similar to Apex. So let's say whenever we are creating some record and we have written some trigger on it, right? So we don't know what is going on, going on on the backend, right? So whenever we want to do something in the background, we will simply create one integration process. Moving on to the next slide. And before moving to this slide, I just want to add one thing, guys, whenever you are going to appear for an interview, so whatever Abhishek is explaining to you, so these are very much important, right, Abhishek? Because whenever interviewer will be asking, like, what is IP? So one needs to know all the aspects of IP, like where it can be used, what all sort of things they can do, right? Yeah. So I mean, these are all things like we have already discussed, but let's go through it again, like, IP can handle multiple data sources like DR call, HTTP call, or if you want to call some Apex class, right, that also we can do with the help of IP. And it serves as a data source for multiple technologies, like response action. I mean, we will get to know more about all these parts when we will be doing the practical implementation, but let's say if you want to give or provide some data to your omniscript or your flex card, right, we can create one integration procedure. If you want to get some data from a third-party application, you can get it from with the help of integration procedure, and you can simply pass it to that omniscript or flex card, right? And we can do one thing in the integration procedure, let's say from the one data rector, I'm getting, let's say, accounts information where I'm receiving 15 fields of account information, right? Now, I want to update one field on the account with the second data rector call. So in your IP first, first there will be a data rector extract where you will be getting 15 fields of account records and in the second data rector load, we just want to update the account name. So in the second data rector call, we can just simply send whatever data we need to update. We don't need to send all the 15 fields. So that also we can do with the help of integration procedure. And as we have seen, APX also has two types of transactions, right? One is synchronous and second is asynchronous, right? So whenever we are calling any IP from Omniscript or from flex card, we can schedule it whether it will be a synchronized call or a synchronized call. So that also Omnisudo has given that functionality or that feature that we can do that part as well. I mean, how this IP will get executed whether it will be synchronized or asynchronous. And I think Abhishek, these data rector extract, API, HTTP action, APIX, remote action, these are the actions that one will be having in IP, like the IP designer that we have. So guys, if we want to relate these things, so if you take an example of Flow Builder. So in Flow Builder, we have different elements, right? So these are the elements which you will find in IP, right? So whenever you want to perform particular operations, so you just need to pick, like here we have APIX remote action. So it means if you want to call any APIX class with IP, so that particular action you will be using. So these are some technical terms that are available on this slide. So soon you will be seeing how integration procedure looks like in Omnisudo application, right? So, okay, yeah, I think we can move ahead. I mean, whenever we will be seeing the practical implementation, we will go through all the, whatever designer that Omnisudo has provided us for integration procedure, we will go through with each and every element, how it looks like, whatever, what elements we have in IP, so all those things. Then we, I mean, you will be relating more stuff to it. I mean, right now this SGPP action, this data rector post action, all these things might be confusing for you, but once we do the practical implementation, then it will be more clear. Right, exactly. Let's move on to the next slide. And so advantages of using the IP is like, we can, similar to data rectors, right? Let's say I have created one data rector, and that data rector can be called from multiple IPs or multiple Omniscripts. That's the same thing with the IP as well. If you have created your IP in a generic way, like we used to create the data rector with the parameters, the generic way, right? Then that IP can be called from multiple Omniscripts. That IP can be called from multiple Flex cards. Flex cards, right? So we can reuse the integration procedures as well, right? And it provides optimal flexibility. So I mean, let's say if you are receiving some data and if you want to trim it down, or if you want to transform that data, we have that flexibility within the IP as well. And it makes implementation easier. Why? Because it's a low-code platform. Whenever you are creating any IP, you don't need to write any single line of code. So that's the biggest advantage of creating the IP. And it improves the performance of Omniscript and Flex cards. I mean, these Omniscripts and Flex cards can call IP and all the data or all the functionalities which is running in the background, that can be completed very quickly. So as IP runs in backgrounds of front-end and back-end implementation can be separated as... So this is what we were discussing previously. So all the front-end will come under the Omniscript and Flex card and all the back-end will come under the integration procedure. And all the databases, transactions will be coming under the data raptors. So that is... So one thing I want to highlight, like if you are thinking... If you want to compare Omniscript Studio with Flow Builder. So guys, reusability is the key factor here. Because in Flow Builder, if you create any element, so that element is basically part of that particular flow. You cannot use a particular element into another flow. We can create sub-flows for sure, but one element if it is implemented in one flow, so it cannot be reused in another flow. So here IP, data raptor, all these are independent, like you can say elements or I would say components. So if you want to reuse any IP with multiple, like two, three, four Omniscripts, so that can be possible. So this way you can relate your answer when you are going to appear in an interview. And if you want to compare it with code, so directly like you can compare it with Apex. So the way we write Apex and we use SOQL or DML. So similarly, for replacing Apex, we will be using IP. And for SOQL and DML, we will be using data raptor. So soon you will be having scenarios where data raptor will be connected with IPs and whatever we are discussing theoretically. So you will be able to see it practically as well. So you just need to follow all the sessions and believe in us because the way we completed data raptor sessions, in similar way, we will be completing IP sessions as well. Yep, we can continue. Moving on to the next slide. So now we will be seeing how integration procedure designer looks like. So when we were learning about data raptors, so as soon as you create a data raptor, we used to see all the tabs like extract, output, field, preview, formulas. So that kind of UI is called as designer. So for integration procedure also we have one designer which is provided by Obli Studio. So I think Abhishek, before moving forward, if you can log in to the org and give audience a quick walkthrough. Because through pictorial representation, people will be able to understand more clearly. So we discussed a lot about IP. Everybody can visualize how it will look like. In that case, like whenever you will be explaining any of the component or feature, so they will be able to relate it more clearly. Yep. So this is again created as a record in Salesforce. So we will be clicking on new button. And as soon as you will be landing up on the designer. So as you can see, we have multiple three sections over here. First is the available component. Second is structure and third is properties. So first we will go to the structure section. So in the structure section, we have one element automatically created which is called as procedure configuration. So as the name is suggesting, we have to define all the configurations or the definition of this IP. What do I mean by the definition like name and how to identify this integration procedure so that it can be an identical integration procedure. So whenever I am clicking on this procedure configuration in the properties section, what we can do is we can just simply write the name. So for example, what I want to do is I want to fetch the account records. So what I can say is fetch account records. And there is one more thing that we use as a best practice. So whenever you are creating an integration procedure, just add IP and underscore in front of the name. So this is your integration procedure name. So for example, let's say whenever you are creating a field or an object on the Salesforce, there is an API name created to it which is unique to all components in your Salesforce. For example, if you are creating a custom object or custom field, there is another component called as API name which is unique to all your Salesforce organization. Here also we have some similar thing over here. But in the IP, the combination of type and subtype will be unique all over the Salesforce org. So let's say I want to call it as like account because what's the general or generic way of creating the type and subtype? So let's say whatever you want to do and on which thing you want to do. So right now what we are doing is we are fetching the account records. So in the type, we can say that give me all account records. So I mean, you can write whatever you want to write over here. But as a best practice in the type, we always say on which object or on which third-party application. So if I'm writing creating this IP for fetching the records from third-party application, then I can give the name like, for example, let's say I want to fetch something from Google Drive. So I can say G Drive. So right now we are doing that on the account. So I'll say on account. And what I want to do is fetch the account records. So I will say fetch account records, right? And as soon as I hit the save button, it will reload itself. And now if I go to integration procedures again and if I search for my IP, right? So see the account slash fetch account records. This is coming from your type and subtype, correct? As soon as I open this, this is the label that will come. IP underscore fetch account records. So whenever we are creating any IP, there will be two things. First will be the label. This integration procedure name will be called as label. And the combination of this type and subtype will identify your integration procedure uniquely. So I mean, now if I want to create the, if I will be creating the, you know, for example. So as you can see, I cannot create with the same name. I cannot create a new IP with the same name. It will say I already have one IP with the same name or with the same combination, right? Let's say if I do this account one, and if I write this, then that will not come. Right? So I'll close this one and I'll go back over here. So in the structure part, we have seen by default there will be an element called as procedure configuration. And for that procedure configuration, we can do all the things like give the IP name type and subtype and all other these other things we will be seeing later on. I mean, what all these things are. Yeah, so guys, we are covering easy steps first and when you will be able to understand it more clearly, then remaining steps will be covered. And one question like these worsening is equivalent to the flow builder. Like in flow also, we create different versions and at the time one version is active. We can do, we can activate one version at a time. And if let's say we have 10 versions and 10th one is active. Now I just want to go back and want to activate 8th version number 8. So is it possible in this IP? Yeah. Yeah. I mean, what will what will happen is, so I mean, there is one more functionality in IP. So I mean, I so Sanjay, I'll cover that worsening part later on. Okay. Okay. Sure. No problem. Yeah. So first we will go through the all the sections that we have in IP. Then we will see all other options that we have in the procedure configuration. Okay. So as soon as you have created your IP, the procedure configuration element will be there in your structure section and you will be giving all the names. Now, for example, this is another section of IP, right, which is available components. And in this section, we have subsection, like groups, actions, right. So as you can see, if you have worked upon a picks, you must be aware of all these terms like cashier blog, conditional blog, tri-cash blog. If you want to, and these things we will be covering later on, but these all things you must have heard of, right? Yeah. So I think Abhishek for this, we have explanation in slides. So if you want to have that as... Okay. On the slides? Yeah. So like we can take help from slide and people can read what all things are written. So here, everyone has explained with purpose and example, so they will be able to relate. Correct. So as we have seen the group sub-tab under... group section under the available components, the cashier blog used to save the output within the session so that we don't have to fetch the data again and again, right? In the epics also, we can fetch some data with the help of Isoquel and we can save it to the session storage. So that can be used in the IP cashier blog can be used for that functionality for conditional blog. So for example, let's say if you are writing some five statements under a if blog into the epics, that kind of things we can do in the IP with the help of conditional blog. Okay. If you want, let's say you are having 10 records list of account from the data rector extract in your IP, and now you want to loop over it. You want to perform some action. You can take help of loop blog into the integration position. Right? Whenever in the epics, whenever you are saving some data to the database, we use tri-catch blog, right? So that we can handle if any error occurs. If you want to do similar kind of functionality, we can do with the help of tri-catch blog in the integration procedure. Right? And now we will go to the IP elements. So first I'll go back. Oh, sorry. Yeah, I think we can now jump to the all because for these actions, we don't have any specific explanation. Okay. Yeah. So these are the actions that is available into your IP for performing some business logic, or if you want to call some data rector. So let's say you have written one data rector for fetching all the account records, right? Now you want to migrate the data rector into your IP so that at the run time, you can pass the parameters dynamically. So if you have followed the data rector sessions, right? In the data rector sessions, what we have done is so we have created one data rector where we were fetching all the account records where active is equals to yes or no. And the active parameter we use to pass it from the preview tab. But that preview tab is just for testing. Now we will do the real thing. What we will be doing is from your IP, we will be calling that data rector and we will be passing that parameter, right? So if you want to do some sort of data rector calling from your IP, so we have so many actions available into our IP. So we will go through some of them for now. Like if you want to call data rector extract, you will be clicking this and dropping into the structure section, okay? And as soon as you will pick and drop your data rector extract section into the structure, in the properties tab, element name will be created automatically. Then in this data rector interface, we have all the data rector extract. Not all the data rector is only the data rector extract, right? So I mean how we call the data rector, how we pass the data and how we do all the things that we will be seeing later in the sessions. If you want to. Sorry to interrupt Abhishek. So guys, just to make it clear, right now Abhishek is giving you just a walkthrough. So in tomorrow's session, like next session, we'll be taking one real example and we'll be explaining that step by step, like how we can connect data rector with IP, okay? So if you are not able to understand it deeply, so no need to worry, we'll be implementing a few scenarios end to end. So in that case, you will be able to understand. Yeah. Similarly, we have data rector post action. So again, if you have followed all the data rector sessions, the data rector type of data rector post is data rector load. I mean, whenever we used to create a data rector for saving to the data to database, right? We used to create data rector load. So all the data rector load will come under your data rector post action. That is why data rector load are also called as data rector post. Okay. And if you want to call data rector transform, if you want to call data rector turbo, and if you want to delete some records into your database, that also we can do with the help of IP. Let's say if you want to send some emails, or if you want to call some IP from an IP. So in the apex, we used to do some sort of creating the utility class, right? Yeah. So from one apex class, we used to call another apex class. So that type of thing also we can do with the help of IP, right? And another thing, like if you want to call some integrations or third-party application, you can use the HTTP action. And if you want to... So in the apex, what we used to do, we used to create some variables, right? So if you want to create some variables into your IP, we can use the set values. Right. So I think Abhishek, these are different components available. And as per the need, we just need to identify which we need to use. Correct. And I think similar kind of actions are available in flows as well. So they are known as actions. So we just need to have and like sending email, chatter post, right? Send some notification, calling apex. So those kind of things I think we can have here as well. And I can see other than that, we have other actions as well like DocuSign, Intelligent Section, DCN Metrics. So lots of features, lots of components are available here. So we'll try to cover as many, right? Because there are lots of scenarios and we cannot cover each and every scenario in the bootcamp. So we'll be explaining few. And for rest, we'll be providing you some scenarios so that you can practice at your own. Yeah. So I mean, I'll just reiterate all the things again. We have three sections, available components, structure and properties. In the available components section, we will be having all the actions or the groups that we can use in the structure. We will be seeing whatever, what elements we have used in this IP. So let's say I'm calling one data rector, I'm calling one data rector post, I'm calling one data rector transform. So in the structure, we will be able to see, first this data rector extract will get called and this post then this transform. So what elements we are using into our IP that we can see in the structure section. And what is the configuration for this data rector post section? We can do into the properties section, right? And last but not least, I'll go to the preview. So it's similar to the data rectors. In the preview, we will be providing input parameters the way we use to provide into the data rector, right? And when we will be clicking the execute, then all the elements that we have used into our IP that will get executed, right? Now there is one more configuration left into the IP that we will be covering now. So let's say you have created all the business logic into your IP. Now you want to use this IP, right? Into your own script. So in the data rector, there was no concept of activating or deactivating the IP. But sorry, data rector. But in the IP, there is a concept of saying if you have created the IP, you have to activate it. If you haven't activated this IP and if you are calling this IP from your own script, then this IP will not get executed. Okay? And whenever we talk about the activating and deactivating, we will, parallelly, we will be also talking about the versioning. So let's say in your project, you are working as a team of five developers, right? And two of the developers needs to work on this IP parallelly, right? There will be one person who will be working on some other functionality and there will be some person who will be working on the other functionality related to this similar IP, right? So what they can do is they can just go to the activated version, right? And they can just simply create on the create version or click on the create version. So now what will happen is there will be a second version will get created for this IP. Similarly, if I go here and if I expand it, now you can see the first version is activated and I have created second version from the first version. And now I can work on the first version and other developer can work on the second version parallelly, right? So when you are working in a collaborative environment, then also the IP is very useful where you can create different, different version for yourself. You don't need to create new IP for the other developer. So that is the last bit which we can understand when we are talking about the integration procedures. Okay, and I think if we go back to the slide, so we have two more slides, one for input and one for output. So if we can cover that as well. So these actions we have already covered. Now if we go to data input. So data input source for IP. Yeah, so data input source can be for your IP can be, for example, if you want to fetch some data from your Salesforce org, right? Then what we will be using is data rector extract action or the turbo action because DRs will always work on your Salesforce org only. Not only third party applications or the integration. If you want to call some integration, we will be using the STPP action element which is available in the available components under the actions section, right? And if you want to call some apex class from your IP, then we will be using the remote action. There is an element called as remote actions. If I go back, see this in remote actions. So this remote actions by the help of this remote action, we can call some apex class from our IP, right? And output can be, like, if you want to feed some data to Flexcard or ObniScript, then we will be using the response action of IP. If you want to save some data to your Salesforce org, then we will be using data rector post action. If you want to delete some data to your Salesforce org, then we will be using the delete action. Again, if you want to send some data to the third party application, then we will be using same STPP action. If you want to send some email, we will be using email action. If you want to use some docuSign template, then we will be using docuSign envelope action. So these are some data source, data input source and data output source and what element we can use for those data input and outputs. Okay. So I think you covered a lot. And this was the introductory session for IP. And Saida Reddy is asking what is the use for response action. So right now we have not explained it in detail. We just have a walkthrough of IP, like how it looked like, what exactly it is having, right? So in one session, we could have covered these many things only. In next session, we'll be doing some demonstration, right? So we'll be creating an IP. We'll be connecting that IP with data rector so that you can see how we can implement business logic, how we can fetch the data, how we can perform DML operation. So those sort of things we'll be doing, right? And Abhishek, if you go to the next slide, so we have some scenarios. So like these are the scenarios that we'll try to cover, right? So we won't be covering all the scenarios. We'll be covering a few of the scenarios. And the related one, you just need to practice yourself. Okay. So I think this is it for today. And one more question Abhishek, we can take. So someone is asking, do we need to keep in mind the governor limits per transaction? So any explanation regarding this? You can think of it like it is similar to Apex. If you are doing some synchronized call from your Apex, then governor limits will be the same whatever we have for Apex. If you are doing some asynchronous call for your Apex, then if we are executing the IP in the asynchronous mode, so governor limits will not impact whether we are building some functionality with Apex or IP. Governor limits will always be, you know, we will be checking the governor limits or governor limits will get hit on the parameters of whether the call is synchronous or asynchronous. Right. And maybe like when we'll be implementing some scenarios. So it will be very, it will be easy for us to demonstrate that. Yep. So I think guys, you might have got some idea around IP. And in next session, whatever doubts are coming in your mind, those also will be cleared. Right. So I hope you enjoyed today's session, got lots of knowledge. And keep on watching these kind of sessions because only studio is new and demanding tool. So if you learn and add this knowledge or learning in your CV, so like for freshers as well as for experienced professional, it will add some weight is to your skill set. Right. So do follow all the sessions. Do practice whatever scenarios we have explained demonstrated in the sessions and those we have not explained. So do practice for those as well. Okay. So I think this is it for today. Thank you Abhishek for sharing all the knowledge and keep up doing the good work for the community. Right. So we are also planning to do some cloud specific sessions. So we'll see if things goes in the right direction. So we'll be having few more sessions other than only studio as well. Yeah, definitely. Okay. So with this note, we take your leave. Thank you everybody. Those who joined session life and thanks to those who are watching the recording. So see you soon. So in this week, we'll be having one more session maybe on Thursday. So do join that session. I will send you the reminders. Thank you everybody.