 Hi, I'm Ravi Surya. I'm joining from Bangalore. I'm a host, Kamaskaran. With me have Robin Gupta, who is ABP at Innovation at Power. And interestingly, today I came across the library testers. And that gave me a pitch, because I've never seen a library dedicated to automate the SAS applications. And this brought me the question, why particularly for SAS? And I have the same question to Robin. Let's get started asking Robin why and what made him to come here. And let's move on to this. Yes, Robin, it's up to you now. OK, thank you for that brilliant introduction. So we'll get rolling over here. OK, we'll have some questions for the audience, some polls and everything. Plus, folks, please feel free to shoot your questions. This library itself is new. I'm more than happy to take in questions and feedback. So let's keep it very interactive throughout the session. Let's not make it those boring conference sessions. I totally hate them. So quick hello from Gurgaon. My name is Robin. And as you guys know, I'm the creator of TestZoos. So we'll go through the slides one by one. So first of all, let's have a question. How many of you have worked on a SAS application? So it's a full question as well. I think Ravi Surya can have that enabled. And we can quickly see some show of hands. OK, and when we say SAS, it's not sauce or gravy as a service. It is software as a service. And for this session, SAS and SAS, product as a service, platform as a service, would be similar for us. Let's not get into that debate. Salesforce, interestingly, is a SAS offering. So if you have tested or if you have worked on a SAS application, yes, if not, no, that's cool. OK, we have the poll running for a minute also. And interestingly, Oracle, Workday, ServiceNow, some of those platform applications are SAS as well. As for me, it is debatable, but we'll be to count them in. OK, I'm just seeing the results. So more than 50% people say they have worked on a SAS application. OK, I think we have the one minute, Matia, right? OK, I'll end the poll. Very interestingly, today, we have a divided audience. So 50% people say they have worked on SAS. 50% people say they haven't. That's cool. So that was more of a trick question or a trap. The point of that question was that if you have worked on a SAS application, then you know the pain. For those who haven't, great. You have been happy for the most part of your life. And I bless you, happy days ahead. So let's get into some of those details, right? Why do I ask that question? So this is a sample page on a Salesforce application, right? There is this one box in the middle. You guys can see if it says there's communications, right? It's an account on the database for people who have worked with Salesforce or SAS. They can relate to this. It's a representation of a record, right? Interestingly, there are dotted boxes on the left, right? And at the top, OK? Those are the key pieces. Now, Salesforce used to have this whole campaign around more clicks and less code. This is supposed to be an application where admins, non-technical functions, citizen testers, and developers can create applications for the CRM users. CRM as in planning and electricity management. Salesforce is a CRM platform, as most of you would know. On the left-hand side, they have a standard company. You can drag and drop them to the desktop view. On the right-hand side, for that page itself, you can edit features, right? For people who haven't worked on SAS, if you've seen visibly editors or website makers, right? This is reminiscent of that. Now, interestingly, this is great, but our whole premise is how do we test this, right? So let's move a little forward. I'm pretty sure, so I don't need a poll over here. I'm pretty sure that all of us, if not most of us, would have seen this lovely triangle or the pyramid on the left-hand side of the screen, right? Now, interestingly, a lot of people within the testing community believe that we should follow the triangle or the pyramid. There are some variations. There is a cone version that's in boxes and everything as well. The bottom layer being unit tests. The middle layer being integration tests. And the top layer being end-to-end tests. Then there is this whole cloud of manual tests as well, right? Now, interestingly, for SAS applications, then let's get a little specific about Salesforce testing, right? We will not spend too much time over here, but we'll very quickly run through some of the pieces where I need to deviate from this sort of interesting pyramid, okay? So there are some points on the right. Let's go through them one by one. Interestingly, people who are familiar with Salesforce would know that Salesforce themselves as a platform mandates 75% coverage for the unit tests. Excuse me. So what does that mean? If me as a developer writes index code or writes the Salesforce code, it will not hit production until I have 75% coverage for the unit tests. So that is very well covered from the Dev angle itself. Now, a lot of the APIs or the platform nuances or details are provided by Salesforce, right? So that's why a lot of the user tests are also covered. So let's say if we build a mean application, Mongo, Ember, Angular nodes, right? Or a full stack group application from scratch, we have to do the backend, we have to do the front end, we have to do the sockets and the APIs in between and ensure that all of those pieces work fine, right? But what I'm trying to highlight over here is that a lot of those pieces are either governed or supposed to be maintained or should stick to compliance from the Salesforce platform or to their offered as standard offerings, right? So the third point over here says that as a Salesforce developer or a Salesforce Chrome team, you need to manually adhere to the UI design system. They will have this uniform, blue color theme, uniform CSS, front end pieces everywhere. They have something called the Lightning Design System. A lot of what you will see on the Salesforce applications sticks to that very closely. And the whole point is that similar architecture pattern exists for other SaaS applications like Workday, Oracle Service Now, as well in my experience. So the big question, which we will not answer, but is a homework to the audience, is the testing pyramid the right approach for QA teams, testing Salesforce and other SaaS applications? And him, maybe not, okay? So let's move a little further. So then that brings us to the next question, right? So then what should we test on Salesforce and when, right? So I've got this model, it's very representative. This is not the golden test strategy for every Salesforce application ever, but this is more like a blueprint or a starter kit for you to start looking at things from a new perspective, right? So we have the first column. What is the type of change or what is the trigger? What is the event for you to start testing some of the pieces that you have in your application in the test? And then on the right-hand side, we have the layers where you can look at them, okay? The third element in this table is no medium to high. So when this happens at this level, this is a high risk or you should definitely look at this. This is not applicable so on and so forth. So let's take one example, right? Let's say we look at the changes to business processes. I'm looking at row three. So changes to business processes including work flows, non-visual flows and assignment flows at design level, low risk, but at unit level, high risk, system level, high risk, so on and so forth, right? So this is something which I didn't know and I feel that it is important for the Salesforce testers or the SaaS testers to understand from my previous slide and this one that when you attack the SaaS application for testing and not to be on the 20, you should have a very good strategy at the beginning, okay? I'll not spend too much time on that strategy piece. Let's move towards this, okay? Okay, that being said, let's say you figure out the test cases, we have everything in place, but we know these 50 test cases need to be tested in every release. But every release that we do with some releases which might happen outside with our vendors, the integrations, this looks like a job for Seaman, that's our superhero. The Selenium framework that you will build from scratch, that robot will run all these test cases for us and we will just take some vacation and have some gala time, right? That's generally the perception of automation engineers when they hit new applications, right? Oh, okay, now I've got this old strategy in my brain, even in these test cases, let me fire up some code, let me create this new framework, have Seaman attack the problem, okay? So this is a robot app, so there is nothing called a Seaman, but I wanted to give it a superhero vibe, right? Okay, however, there is a twist in this story. So interestingly, the Salesforce application, right? It looks very calm on the surface, it's like the surface of the ocean, very calm, relaxing. So on the left-hand side, we have a similar account detail page as I showed earlier, and then at the bottom, it's that inspected or chrome control piece. Now let's look at some of the problems, which Seaman, our automation robot or automation engineers face when they attack SaaS application and specifically Salesforce, right? So first is frequent system updates. In the beginning of this session, the reviewer was asking you, so what caused you to create this framework? So I was telling him the origin story for Tesdo's. When I met Salesforce when a half years back, me and my team, you know, we ran a project, automated a couple of test cases, and exactly one and a half, two months later, all of them broke, even though we hadn't done any changes from our side, but that was the harsh learning for me, that Salesforce does releases twice a year. They do the spring, summer, and winter releases, and interestingly as part of those platform releases, which are mandatory, by the way, they do change a lot of internals at the API level, at their own core level, but at the external level as well. So they will change the DOM structures, how they will handle shadow DOM, slots, lightning the components, so on, so forth, right? What does it mean for the QA teams, right? Every time they do it, you have to reassess most of your test cases that they are still working, what's the impact, so on continuous maintenance of not just your test base, but your automation base as well, right? Interestingly, Salesforce also has a concept implemented of shadow DOMs across the application, and their DOM structure is very heavy. You're as highlighted by the bottom section on the left-hand side, that you know, I'm just looking at the drop files button, which is highlighted on the screenshot, and the same element is highlighted at the bottom in the DOM itself, right? This is a very small snapshot. This slide was insufficient to show the whole complexity and the DOM tree, right? And interestingly, account is a standard object on Salesforce, but this is the easy piece. If you have custom objects, if you have custom integrations, or custom code trigger on top of it, it only gets much more interesting, so to say, okay? So we had the C plan earlier, we saw, okay, you know, automation engineers, when they see Salesforce or a web application or test, they attack it with the full energy, but when that robot meets the road and C man enters the ocean of Salesforce automation, as I mentioned from my case, a lot of things break, and a lot of things crumble, okay? So that's the origin for test groups. That's the problem statement that we are trying to solve, with this program source automation thing, okay? So, okay, whoops. So as I mentioned, right? So generally people attack automation from this front facing challenge, right? That, okay, let me look at the X path as I was showing earlier, or let me look at the DOM structure and try to see how best we can impact those elements. But interestingly, what we found in our case or on Salesforce was that there was a back door, right? We thought what if we could utilize the same APIs which Salesforce themselves use for rendering the front end, right? So this is a screenshot, this is from official documentation of Salesforce themselves. They have this concept of user interface API, UI API, okay? So the whole simple application, right? If we cut it into slices, that is what is being represented over here, let's start from the bottom and then go towards the top, okay? So we have the core platform and shared services in the Salesforce is a system which implements multi-tenancy, we're not going to do those details. On top of that, we have the UI API. So all that data, let's say from the databases, close to the UI API towards the Lightning Data Service and the application layer. Now this is the application layer which feeds into the Salesforce UI on your Chrome browser or on your web browser, right? And then on top of that, we have the base components, right? Like let's say we have the nine dot icon or we have this icon, right? And we have the experience components on the right-hand side. So we used to work with Kobywa as well. So people who know integrations on Salesforce, they can relate to it that that whole API is actually built, we get from the UI, we get from the backend itself, okay? So the whole genesis of test-zoom was the point that can be also used the same UI API to figure out which elements appear here on the UI, right? So that is the smart innovative approach that we took with test-zoom. I see some folks are raising hands, we'll take questions at the end. Please feel free to pop them up in the chat, make a note, but you have to definitely answer every question that you get along, okay? So UI API is what we actually use for the auto locator strategy within test-zooms, right? So rather than creating locators by hand, let's look at this picture that we have in front of us. On the left-hand side, we have the same account details page, right? The account owner, account name, phone number, address, the ITSLA, go on, go on, all those fields for that record, right? Now the same piece comes from the UI API, the box on the right-hand side. There's too much English, but don't worry about that. We'll go into the details in a second over here. So when we look at that screen, right, account details, let's say it has the account name and it has an account created on, right? So that's a snapshot, but don't worry about the data itself. The UI API basically is a design system that Salesforce has implemented, saying that on section one, which is for accounts, row two, which is account name, column one, we have the value for that account name, right? Now this is much more intuitive than writing in Xpath. Double forward slash text or double forward slash div, text equal to account created on or contains or some access or something around that. If we create that, one, you have to write it by hand. Two, it might change with the Salesforce updates or with the updates that the scrum team or the development team does. Now over here, even if something does change, the UI API will update us with the data. Let's say account name moves to the third place, rather than the second place, right? So then the data that we get from the UI API will be like section zero, which is account details, row two, which is account name, column one, something like that. So we'll get the precise location. And if you guys can imagine a little bit as we move along, that is precisely what we use within test source to build the auto locators, right? You can, in very simple words, let me simplify it. We can run a for loop, get all those pieces in month chart, iterate through the month by month and pass on the locator to the automation state, okay? Rather than writing all of that by hand or it makes paths and so on and so forth. That same piece is detailed on the right-hand side on the screen, okay? That is not only who we get in the precise location, but interestingly, Salesforce also sends in, is it a required field or not? And the type of that field, right? Is it a text field? Is it a pick list? Countdown, calendar value, multi-select, lookup, and so on and so forth, right? So we can use all of that contextual information to not only one, to get the locator, to perform the contextual action, okay? Cool. So that's the auto locator strategy that we have implemented in test source. Interestingly, Salesforce has got the property, experience, page load time, okay? In very simple words, if we have to wait for some element on the UI, we can do implicit weights, we can do explicit weights, and some of us would also do 10 dot sleep, okay? We're not debating that over here, but what Salesforce does is, they have this concept of experience, page load time. Let's look at the snapshot at the bottom for a second, right? Next to the star icon, you can see something in green. I'm not very good with colors, but the number says 1.33 space s seconds, okay? So since Salesforce is a managed application by Salesforce themselves, it's a CRM which they build and deploy, basically sell to their customers, they do a lot of this governance and compliance, right? So as part of that initiative, they also published numbers that, okay, when you load this webpage, it loaded in 1.33 seconds. And when we say load, right? So they do check for, is it ready? The norm is constructed, are the elements impactable, and also with some buffer frames, right? So test rules utilize the same concept to automatically wait on the page to load, right? So we, this is not like a silver bullet or explicit, implicit weights, but this definitely augments the weighting strategy, right? So based on the EPD concept, we have built-in auto weights which help on the weighting strategy for locator interactions and test automation. Here's a high-level framework background. Don't worry too much about it over here. Look at the code in the demo in a minute. The form figures the testing XML, which we got the test case. The test case and its basis, where we have the initialization from the web browser factory and the page factory. The test class also uses the page objects. So we use the page object model for custom integrations, custom implementations. The page object extends as a page-based, Salesforce page-based, where we actually do the auto locator management. We get all the locators in one shot, create the expanse or whatever is required, pass it on to the page objects for the interactions, and then use it in the test case. The base test class box with item number four, also interact with email utils if you want email interactions or also uses HTTP Client Trapper, so that we can, one, only use the UI API data, but also if people want to rest or API-based testing, they can write tests using the HTTP Client Trapper. So that's a very simplified version of the framework for TensorFlow. It's all open source and on GitHub. So we'll provide links at the bottom and at the end. Don't worry about that. But the whole device is very simple. It would be also very common for people to have seen similar structures in other places. The only differentiator being that this uses auto locators and other Salesforce specific nuances such as, okay. Okay, demo time. Let me jump out of slides. I think time-wise we are doing okay and get to our favorite place in Eclipse. I hope everybody can see the screen. Ravi, can you confirm or can folks confirm that? Yes, Robin, I can see the screen. Okay, cool. So over here, we'll do three things. One, I'll quickly show you the structure of the test case that we are running, right? Two, we will actually run it. What's the point of talking if we can't make it run? And three, then we look at the results and then some of the intervals. Not into too much detail, but obviously we'll see how the X path or the locators are getting constructed, how we open the UI API and so on and so forth. Okay. So basically I've tried to put in comments as appropriate. In the beginning section, we're trying to navigate and log in to the Salesforce application, right? Line number 31, over here, accountlistpage.uiprsterrecordid is the place where we actually try to get the data for certain record and record type. We are using account, but the same concept applies to the other subjects that we have on Salesforce, the other standard objects like contact, opportunity, cases, so on and so forth. Once we have that data, we can use it to create new records. The whole premise of this test case is to create a new account by just passing in the form values. The same can be done by API. We have a sample test for account creation by API on the Facebook GitHub repo as well. So that happens in line 33 to line 40. Line 43 says thank you. The second test is just to check what are the required keys. So we are seeing if the account data has required keys or not. As I mentioned earlier, the UI API also highlights those data elements and exposes them for use in it. Okay? So we'll quickly go ahead and run it as a test and key test. Hopefully it should work. If it doesn't work, we'll try something else. Okay? TestDos has also utilized Navel. The same keys that we are seeing is available as boilerplate code for you to take from GitHub and run it on your own. We have the new independency already set up in that boilerplate code so that you're good to go from point zero. What you are seeing on the screen is the Salesforce login page. People who have worked with Salesforce would have seen this, I don't know, a million times. What we are doing next is we put up the user ID and password. And once we click the submit button, we are trying to navigate to the account creation section. Okay? This is the setup. Again, as I said, people aware with Salesforce would be knowing this, if not, that's cool. This is more, you can think of it like as a homepage. From there, we are using the nine dot icon to get the URL for the accounts directly. And on this account list screen, we have clicked the new button which brings up this new popup for us to create a new account. Now these fields are the places where we are parsing over data from UI API, not hard coding expert and locators and dynamically creating them on the fly. As we see, the script has put up the real click on save button. The account was successfully created. We have very five those details and that's the office model test case. If Eclipse would work with me over here, I will quickly show you the data that also that we get. Okay, that's good. Okay. Yeah, on my machine, Eclipse faces some ego issues here and there. So it's not cooperating well, but no worries, you can get back to that in a minute. Okay, I'm just trying to keep Eclipse happy. I'm not clicking too many buttons, but what I wanted to show the audience over here is that in the console, I have printed out the values that we get from the UI API. And if you see specifically towards the bottom section, right? So from that account UI that we saw, we are parsing what is the label for that field, right? And the type for it. So for example, for SIT code, S-I-C code, we get the SIT code as the label and the type for it is string. For ownership, we get the label as ownership and the type as a pick list and so on and so forth, right? Now, example one, if we had to write page objects for that account page that we just saw, we would have to write in locators for all of these. I think in this specific case, as far as I remember, there were around 30, 35 fields and values, so we would have to write all of that by hand, but no need to do that because if UI API can provide all of that data, you can just store it in a hash map or a data structure as we're doing over here and then consume it for creating the X parts on the fly. So that is the difference in one, the efficiency or the velocity that you get with using test routes rather than writing stuff by hand because a lot of this is just pulled in, sucked in, massaged and parsed ready for usage and two is the maintenance. So as I mentioned initially, if Salesforce is doing three releases a year and if your development team is doing at least once release and in a month, so that is 12 development releases plus three Salesforce releases, interestingly Chrome, Chrome driver, Chrome browser does 13 releases in a year, you would have to maintain your test cases for all of them throughout the year, right? Obviously that wouldn't leave us with a lot of time for the other important stuff. So rather than relying on automation for efficiency, you would be stuck in maintenance hell. Okay, back to the main thread. So as we were seeing on the console, all the label and types are pressed from the UI API and then based on that data, we basically construct the X part of the locators or form the interaction, right? So if it's a string, we can read the value, input the value, if it's a pick list, we can interact with it as a pick list. If it's a URL, we can have the anchor tag, we can have the value, so we can perform contextual actions as well. Okay, so that's what I wanted to show the audience over here, that how are we getting those values and we are using them. Okay, that is sort of the end of the demo. So we'll provide the GitHub link, it's on testloose.com, pretty easy to remember. Very few alphabets there. So you can one, look at it, obviously, to get the code for yourselves, try it out, right? We are more than open for feedback. See, poke around, see how it works, see all the readers that I mentioned in detail. And four, if you're happy with what you see and feel motivated, feel free to open a commit request or a PR and we're definitely looking for contribution. So let's look at some of those angles. Okay, so the next thing which I wanted to highlight for this session is personal experience and other footnotes. Testloose has definitely helped us or helps us or helps the audience in one, as I mentioned, accelerating the test automation effort by removing the need for writing explicit locators, right? So that's the example that I mentioned earlier. But rather than writing all of that stuff by hand, you can just use it and consume the data by the UI API and then use it for your automation needs. Two, add stability. So with automatically waiting for pages to load. So using the EPP concept, experience page load time, we can do that, okay? And the third is reducing the meeting and support with the changes on the platform, okay? The other notes over here is that Testloose is an open source test automation framework. It's GPL V3 license and it's a proof of work. And the target is for test zoos, particularly strong engineering teams. You would have to fork it or get your own copy, build on top of it. That's the point that I'm trying to make here. And there we are talking about contributions. So a road ahead. There's a small quorum on the left-hand side, which definitely inspired me. And on the right-hand side, we have some resources and support. So the links will be there in the slide that you will share. Salesforce has its own community of test automation play blazer. That link is there. They also provide the trail heads or learning trail heads are, you can think of them as three online Udemy courses where you can learn Salesforce specific concepts. You also have a Selenium community on Slack, which is really up us with the questions and answers from the members of the Selenium community, the maintainers and the core members. And then there's a link for the Testloose repository as well. So maybe the session will come to an end in some time, but we are just getting started. And that's a robot back in action, C-Man. That's also the end of the slides and the presentation. Any questions from the folks over here? Hey, audience. If we have questions, please raise your hand so that I can let you speak with Robin. We can speak with Robin. Meanwhile, Robin, I had asked a question saying you, the question is UI API, will we get from developer or from network tab? So to review this question is asking, will we get UI API from the developer or from the network tab? Okay. You need to go to any of them because, okay, let me go back and one piece, okay. So UI API is something that Salesforce themselves provide as a standard API. Okay. If you look at the right hand side box over here, it says that heading UI API and you can do a get to that endpoint on your own. So get and then your Salesforce base URL slash UI hyphen API, record UI and the record number. So if you hit that, you will get the full details on your own. So I personally feel that we need not oppose either of those avenues. For a certain record, you can get the videos on your phone because the UI API is a standard API provided by Salesforce. I hope that answers the question. If not, please feel free to re-ask. What about, let me know if you want to talk to Robin, I can enable you, okay. Yeah. And we have one more question that came up now from anonymous identity. So the question says, how about handling the dynamic objects using Tizius? In case of web table, will API also return row and column IDs? That is a very good question. In some of our cases, we felt that, yes, it can do it. But interestingly, as I mentioned, Tizius is more active group of work stage. So we haven't deployed it in the wild and we don't have substantial data to say yes. But I'm also not saying no. So maybe is the answer. Please try it out on your instance. And interestingly, while we found that Tizius is good at handling the standard implementations, what I have seen in my own experience is that Salesforce implementations get complicated exponentially with time, right? People add in custom code, custom implementations, dynamic objects, integrations, integrations with other platforms, so on, so forth. We can't guarantee. But please try it out. And if you see it doesn't work, please put it up as an issue on Git. We monitor it very actively and I'd be more than happy to jump on a call or look at common news cases. Yes. I have a question, Rabit, from my side. Yeah. Like how do you handle the shadow dumps? Shadow dumps, like... Yeah. Basically that piece of code is not yet added to Tizius, but what we did initially was that we wrote custom JavaScript implementations for handling shadow dump. And as I mentioned earlier, Salesforce has a very strict design system. So if you would have shadow dumps in one place, they would be very similar to shadow dumps across the platform for that implementation. So generally with JavaScript interactions, you'll go to the root, open the root, interact with it, so on, so forth. Nothing magical over here, nothing special done with Tizius, but we were definitely using the standard ways with Selenium in JavaScript execution for shadow dumps. Thanks. So how are you handling the reporting part here? So if I clone this code and start talking on permitting the SaaS-based application, how the report seems to look like that? So we haven't done a lot of work there. We use test engine for that. And I'm assuming that that would solve most of it. OK, we have a question from Junayath Khan. He's asking, does it work with Salesforce Classic? Yes. Yeah, so for people who don't, are not aware of Junayath's question in detail, Salesforce had their own design system called the Classic. And then few years back, they migrated to the Lightning platform. But to the question, yes, it would work beautifully with the Classic interface. Robin, to me, one slide, OK, it looks like two slides, it looked very interesting. It's interesting, that's something, OK, which will help me to visualize the things. OK, that's one more slide 13, like slide 13. Yeah, especially, OK, that animation, OK, that one, two, three, four. So I feel, OK, that's something. That's something very neat. And that helps, OK, a tester or anyone who will go through the code and the flow. It will help them to see like what's happening. Thanks for that. So one can visualize, OK, the flow, right there. So yeah, that's very good. Thank you. So a lot of what we are seeing over here has come from my own late nights, working with code bases, the pro-organizations. And this is one thing which I personally felt that when you enter a new code base, right, generally people will say that go debug it and send it on your own. There is a lot of activity provided to dance. So I don't want the users of Pezzuz to hate me for that. So the numbering might be a little off, but it's 99% accurate. Yeah, but this looked very innovative and neat. For me, there's no need to go and look at the different. The packages and class. I can just see this and I can connect in the ID, the flows. Thanks for this. And one more which looked interesting for me is that the UI API layers. I did not know that the web page of this one, the web page of Salesforce application is so structured in the DOM. Yeah, it's layered. Yeah, correct. That is one thing which even I realized once I enter the Salesforce ecosystem is that how well, how neatly organized things are. So I have worked with Chrome-grown applications for most of my career. And as I mentioned, if you build a full stack of a back, it's like this cluttered house. You don't know where to find this thing. And one NBX update or whatever it had, 50 things will break. Interestingly with Salesforce, a lot of these pieces are solved very nicely. It's very well structured, very well documented, beautiful diagrams as we are seeing over here. This is not something I've made. This is from their documentation. So yeah, but to your point, definitely that is something which we can definitely take inspiration from. Right. So, I think just let me know if you have any questions so that I can enable you to talk. We can talk. And after this talk from Robin, Robin will be available at the Hangout table. So we can go to the Hangout page there and join the table and you can continue to interact with Robin and ask your queries. Okay. Yeah. So I'm seeing are there any questions coming in from the audience? Okay. If not, then we will catch up in the Hangout table with Robin. Robin, this was a good one for me to highlight. I mean, I've not talked with the SaaS applications. I mean, when you say SaaS, Salesforce in particular. Okay. I mean, I've not talked with Salesforce applications. And this was useful for me because I do not know how the Salesforce, okay, I saw this and I got an idea. Okay. Next time when I write, okay, the flow of my framework. So I will carry your idea by mentioning your name. I got to study from Robin. Thank you so much. This was a, we did a session for me in terms of understanding Salesforce and how to present the idea of the flow of a code. That helped me a lot. Thank you. Yeah.