All right. All right. All right. Okay. I'm going to turn it over to Andrew. Andrew, I think we're going to be using which what. Dear Adele, is that the one? Sure. Yeah. I guess I'm just wondering how much do we want to split between sort of just high level overview of the orbit of platform. First is getting into the weeds on. So let's do sort of framework. I was going to say let's do 10 minutes or so on the overview and then we can get into the weeds. We have about 40 minutes left. Okay. Sounds good. Let me share my screen here. Everyone can see what I'm presenting. Yes. So this is the orbit up platform. This interface here is what we refer to as experience manager. When you first log in, you're going to see main listing of sort of all the projects that have been established with thinking that you know you would have different projects for different customers or perhaps sometimes different projects just for very distinct functionality some within the same customer. Yeah. So pretty basic at the outset you'll have your list of projects. Clicking in to a project. And I'll use the adira jade new as our example for this call. You're going to get project specific menus. And so at a high level, orbida was designed as a platform to. And so we can enable the creation of skills once in our platform that could then be deployed to a variety of sort of interactive skill frameworks, I guess you would say with the main ones that we target being Google dialogue flow and Amazon Alexa. And so we're going to be able to make more our solution for sort of text chat bots Alexa often being for you know the boy skills with other possibilities for like I be aren't stuff but that was the main the main crux of the platform design. It is. I just wanted to confirm that mark has started the recording. Thank you. Thank you. Is that right, Mark? Yes, that's correct. I have started recording. Okay. So, you know, at a basic level it is, you know, a underlying it is a node. And application you won't necessarily interact much with the node process if at all, but you know the development is primarily job script based. We hosted on AWS, but again that's sort of not not something that you deal with at your level. And the primary backing of each orbite sort of instance is it's built on top of framework called node red. So this what I'm showing you here is experience designer. This is where you would write most of your code for your projects. It's a visual editor. I'm not sure how else to describe it. It was primarily geared towards sort of internet of things applications. And sort of a carryover from the earlier incarnation of orbite. I thought it was going to be a sort of healthcare IOT focused platform. It certainly, you know, interesting being a visual editor allows you a lot of sort of interesting possibilities for visualizing your flow logic. But at its core it's, you know, a series of nodes that you develop. A lot of these orange nodes, for example, are just sort of job script function nodes. It certainly, you know, encourages a lot of modularization of your code into very discrete units, which is good. And essentially when a flow in here by a flow, I mean sort of some sort of starting node. And then the series nodes after it is invoked. You just sort of get an execution where what they call a message object is created. And it gets passed through node to node until it hits an endpoint. But we'll get back to this in more detail later. So the primary loop in the orbite platform is essentially a request comes into one of these interactive frameworks like Alexa or dialogue flow, which will be our use case here. It comes in, you know, it'll be saying an utterance of some kind. Google dialogue flow is what does, you know, they do the heavy lifting in terms of sort of interpreting the utterance into an intent based on what we have told it. So something like, you know, I want to schedule an appointment, dialogue flow, you know, interprets that as the scheduling intent. Once it is done that, it sends off a request to a webhook on the orbite end saying, hey, the scheduling intent has fired. And then orbite will invoke an intent node like this in node red. That will then carry on that message through whatever the configured code is for the scheduling intent until it hits an endpoint and sends a response back that then gets sent back to dialogue flow and then back to the user. And you know, similar chain for Amazon Alexa would be a request comes into it. That request gets interpreted by Alexa sent over to the orbite corresponding intent request node and goes through our logic here and experience designer and then I response a sent back to the user. And then there are pieces that make that happen. Our and it's based on the level everything is sort of driven by intense. Intents are defined here in the intent library. If we look into one, see if there's a good example here. And it's pretty minimal at the moment, but you know, if you want to create a new intent. What you would be asked for is a variety of utterances. So, you know, let's go back to the example of say like a scheduling intent. You'd be filling it potentially with, you know, utterances like, you know, I want to schedule an appointment that sort of thing. What we would call templated utterances where, you know, you have slot lists, which are lists of particular known values. So let's say, you know, I want to schedule an appointment at, you know, downtown hospital or some location name. You would have a situation where you would have a list of say like scheduling location names. And then you could create an intent here. That would utilize that. And just as an example here. I'll just use the orbino. Are they built in sort of city slot. You know, I can do something like, you know, I want to schedule an appointment in. And then using the bracket notation, you would select a slot and this sort of represents, you know, to dialogue flow, like catching any utterances like I want to schedule an appointment in any of the values that are in that slot. So yeah, between hard code utterances and templated utterances. Intents are where you are indicated to either Alexa or dialogue flow sort of what. What sort of utterances you're expecting from the user and how they should interpret them as an explicit intent of the user. So when you have created your intents, there is a deployment process over here. This is where in this case in the Alexa, you are seeing that or but I have sort of taken all of your intent information and converted it into the format that Alexa would expect for a skill deployment. We know certainly to play the same thing over here, but dialogue flow, Google, same things happening there. We are converting it into the sort of format that dialogue flow would expect. And then you are publishing out there through the project. So that that agent that is listening for user input is then ready to interpret whatever sort of utterances you have configured. And like I said, you know, that's sort of the that builds the core loop of orb to projects user request intent interpretation sending that off to orbit of processing we give a response back to the agent that goes back to the user. So then there are a bunch of other mechanisms that sort of around building that sort of intent fulfillment logic. The I'll skip over some of these days. They're not really that relevant to most project development, but the big one would be orbida answers, which, you know, handles sort of your Q and A type situations. We do have some increasing stuff that we are building around generative AI handling question answering that's something we get into more detail later if applicable. And flow studio would be the other very big piece of intent development. So we've seen experiences, I know is great for a lot of sort of like custom logic for, you know, let's say you need to call out to some third party web service or retrieve records from within orbida we have a content library for storing any sort of data that you might want to store. Based on schemas that you define. But it has some limitations in terms of flow logic. So that's where flow studio comes in. So in flow studio, you will see the development of sort of user experience flows. So we're going in here. This is a rather large one. But like this where you know, in this was sort of developed as a more less technical user friendly means of developing experiences. And here is where you know, you can sort of piece together nodes that either present, you know, content to the user or ask them for input. So this note here represents sort of, you know, asking for input and then presenting them choices for that input. So we have our nodes in here that will pass for sort of free form input here. We are presenting a text box to the user asking for a zip code. Nodes that sort of connect back into experience designer for more complex valuations, for example. So this flow studio would be your sort of primary development of the actual user facing experience by large with some back and forth between flow studio and experiences, either depending on the complexity of what you're trying to do. I guess one other thing to touch on quickly here would be adaptive cards. I don't know if there are any in this project, but it provides sort of an interface for creating more complex user interface or user like input interfaces. So you know, in flow studio have sort of these simple options for, you know, say I want to just present a text box that takes a zip code from the user adaptive cards provides tools for let's say, you know, creating like a multi input form of we want like first name last name email date of birth with a calendar selector from the user. So that's another useful tool. So from the selection side, if there are any questions about anything so far. I guess not. Okay, so two other things that I'll just touch on quickly here. I had mentioned content. So, you know, there are a lot of mechanisms in orbita for, you know, like storing custom data based on schemas that you define. You know, taking a look at schemas here, for example, this is a schema for an instance in error that has occurred that we want to store to sort of be able to review later. It's primarily just an array of field definitions where you say sort of what the key is, you know, what the type of field is and evaluation requirements. And then that enables the storing of data either in what we call the content library here. Let's see. Have a good example here. So in this case, one of our content sort of schemas is settings where we store setting information for our project. Looking at the error schema, it's over here under section called data, I'll get into why there are two different sections in a moment. But here we can see items that were records that were created based on that schema that I showed you over there of the. Of the error records and you know, we present sort of a, you know, dynamically generated interface for editing based on what the schema is. The items are split between two sections here. It was a distinction that was more important earlier on in orbit. So initially there was content and there was data. With Mark correct me from wrong, but I feel like content initially was the only thing that got indexed for search and data did not. Or it was maybe the other way around. That distinction has sort of since been removed. So either data under the sort of content section or data section can be indexed for search. So really there isn't a significant difference between which area used for content storage. It will be determined by the type you select when creating the schema. So there is a content type, which will go in this section, a dynamic type, which will go in this section. I think in general, we sort of just enforce the convention of okay things that are under the content are things that we would expect might be edited by, you know, less technical users, let's say, if it's content items that represent the content that we displayed at the user, that sort of thing. Whereas data may be more for analytical sort of data errors that we're recording user interactions that we're recording that sort of thing. But at the end of the day, there's really no huge functional difference between content stored in one place over the other. And your primary means of interacting with content from experience designer would be the dynamic data manager nodes where you sort of tell it which model you are trying to interact with. So let's say our, for example, and what you were trying to do with it, whether or not you were trying to create a new record, updating existing one, free it. You know, it's primarily analogous to sort of just crowd operations against the database and the payload in that, in that node would be essentially a mango query, mango DB is the backing database for for more things. And then one more thing that's important to touch upon here is chatbot settings so not applicable and Amazon likes skills but very entirely applicable in dialogue flow skills that are fronted by a chatbot. So we pull up an example here. Actually, let me pull up. There are style sheets on here that are interfering with the default or with a chatbot display. So essentially in the chatbot settings by default when a project was created, you're going to get this default chatbot that has default or but as stylings for the chatbot that is displayed on the page. Which, you know, is a good starting point, but you will often, you know, just inevitably do a very customer specific branding, which is represented here by these change chatbot settings, which have sort of changed the default or but a chatbot styling into this jade specific styling. You can see here sort of takes over half the screen. There's complete flexibility, whether or not you want sort of a chatbot that just takes up a corner of the screen versus a full page view. But the chatbot settings are what govern the display. You have the template itself for the chatbot. So you have a lot of control in what markup is actually rendered on the page, custom CSS that is applied to it, custom JavaScript that is invoked as part of the chatbot floating. And then a variety of other settings in here, depending on what, what or what a functionality is maybe utilized on this, for example, is where like live agent settings would live if that was being utilized for a project. But yeah, so those I think are the key pieces at a high level in experience manager for your standard sort of dialogue flow based chatbot based or what projects. There are other items in here. They're just less commonly used things like calendars, surveys, provides a sort of alternative means for developing a customer like a user input survey, but it sort of fall into the way side in favor of doing that through flow studio. Any so I think that covers everything I want to cover an experience manager, so I guess I'll pause here again for any any questions about any of us. Yeah, I have questions. I like to down some the board, we have developed it, and then we want to down it, so we can do that. I'm sorry, I'm here to be that. Yeah, okay, yeah, so we have. Yeah, okay, so we have developed one bot and deployed it, and then we just to down it, so we want to unpublish it. So what with the way to uncomplish that part? When you say unpublish it, you mean like sort of reverts. Yeah, I am. We don't want it to open for the public, so we just wanted to revert it. So is there any easy way to do it so that the code will be as it is, it will not be removed from the projects, but the what will get unpublished. So I mean the actual live availability of the bot is going to be dependent on whatever page it's being hosted on. So that would sort of be up, so you know, we don't. We have to remove the address, which we have placed on the hosted server, and then it will get down automatically. Is there no, anyway, there's no way to unpublish from the platform, right? I mean, it's an interesting question, you know, typically yes, it would be you were to remove these scripts that is injecting the chatbot onto the hosted page. There certainly would be options if you've wanted to enable toggling that from orbita to sort of create a flag on the orbita side that then like, you know, every request comes in for the chatbot, you just sort of cut it off at that point. But yeah, primarily that sort of thing we would handle from the hosted page, but you down there is flexibility to also just like I said, have a, you know, live flag or something in the settings in orbita that you could them, you know, look at an experience designer and sort of cut off chatbot loading. Yeah, okay, gorgeous. Thank you. So, you know, just to go into, you know, I guess it's a good segue into sort of the experience designer part of things, but like chatbot, for example. So, you know, this request is coming in for the sort of orbita hosted chatbot page. So that request is coming into this HTTP endpoint here that is displaying an HTML template that we have created. Where among other things we are injecting the JavaScript to load the chatbot in an actual production situation, you know, this page would be a, you know, actual hosted page on whatever the customer website is. With the request still being made into the orbita script and everything. But yeah, so HTTP endpoints, one of the sort of many options for input into experience designer code. The primary ones are going to be intent requests, like I mentioned, which these are handling input from dialogue flow based on. Received user utterances and the interpreted intent. HTTP endpoints are going to be another very common one, you know, you had one of these into the project, you tell it what the path is and then it's, you know, exposing that as an endpoint for anyone to request from the project instance through this sort of, you know, the orbita URL. And then there's this slash OE API prefix for any of those sort of endpoints. You'll see endpoints like this, which is a web socket input that handles input back and forth from the actual chatbot interface. There are inject nodes, which can be scheduled at a specific time to fire off a process and experience designer. They can, you know, be manual only if there's say some sort of like, I don't know, clean up routine or something that you have created in here to remove some stale data or something that you only want to fire manually. I think those are the primary means of input that you typically see my experience designer. But like I said, you know, the sort of core unit of functionality and experience designer is some sort of flow that goes from some sort of input node through a series of logic to some sort of response node, whether or not it's an HTTP response node that is indicating like what the actual response body content type is and a web socket response or in the case of intent nodes, they are typically going to flow into a response node that will create the appropriate format of response for Alexa or dialogue flow, depending on what's being used. A few other less commonly used ones, especially I think from what I've seen so far in the entire projects, but there are Twilio nodes for inputs to and back to Twilio is an SMS handler. Yeah, those would be the primary ones. So like I said, all, you know, everything you're going to see in here is JavaScript based. The, I guess a note worth making is that so any sort of, I would say modern JavaScript code is going to work fine in orbita. We at one point, forked node red and lost some more recent updates in terms of what the JavaScript editor will recognize as valid JavaScript. So if you were to use say like a sync in a way as keywords in your JavaScript code in here, it may throw an error about it. It often also likes to throw errors about play come the sort of expansion operator for expanding objects into their constituent properties and stuff. But it will all function the sort of backing node JS version has been upgraded over time, but they're the editor is due for an upgrade. But yeah, so it is it is pure JavaScript. And yeah, I guess there's not much else to say about that. I guess I did, you know, sort of lends itself nicely to being very, you know, discrete in your functionality. I would typically recommend that you know as you are developing in here that you keep each function node as succinct as possible and name it well to indicate exactly what is happening in that node. And it is very easy to just sometimes fall into a habit of creating a function node, you know, chaining into the next one, chaining into the next one, not naming anything. And then when it comes time to debug something, you're just kind of going through node through node and taking a guess as to what lips were. And you're often jokes around here about how clean I keep my code and experience designer and people can, you know, tell just from the look of it whether or not to this code that I wrote. But yeah, it's the visual editor is interesting and it provides, you know, opportunity for I think very clean organization of your code. So pick a man of that. So, I guess going into sort of the common framework that we have put together. So Orbita as a platform, especially with this experience designer piece, it's very, you know, it's very much just a sandbox. It's a very thin layer on top of sort of open, you know, just development in node JS. So there aren't really a lot of limitations as to what you can do. And that, you know, earlier on led to a lot of variations in code that we would see between projects. So at a certain point, we came up with what we sort of called our module system within experience designer to help make certain things repeatable and standardize the code that we were putting out in our own projects. And so everything that you will see in this project, for example, after this customer success modules tab is part of that framework. And so typically, you know, recommend and you'll see a note on every one of these tabs, not to edit it. You know, these are standard modules and we have a whole system for deploying out different versions of them. And obviously if sort of custom changes have been made into one of these modules that breaks the ability to do that. And if you were to sort of customize, let's say the chatbot module here for some reason. If we on our end, like, you know, saw some sort of issue we're trying to resolve with our standard notation or want to his functionality here and then deploy that out. We would overwrite the changes in that case. So if at all possible changes shouldn't be made for these modules, they should be made elsewhere in the project on sort of custom tabs. And each module should allow a sufficient life of interactivity with its methods from other tabs. And I'll get into that in a moment. But so a quick rundown on the sort of common modules you'll see one this CS modules tab is just essentially it's the sort of equivalent of a package. So in the file in no JS it's indicating what modules what our system have been deployed, what versions sort of what the primary dependencies are and then your full deployed dependency tree and what the versions are. Going through from the basic level, everything is built on sort of this project context system. And so that's the problem that we commonly had where we would use a lot of timed injects nodes to sort of initialize code on project startup. And it just became a headache to sort of get them to fire in the correct order. If you're using time to inject notes, you can sort of stagger them saying, OK, this one fires like a 10th of the second after the project loads and then another one fires a half a second to try to get the order right. And then we became a more formalized version of essentially waiting for dependencies between projects to resolve. Not something you need to worry about the details about, but just an explanation as for what that is doing there and why you see it referenced in all of these other modules where they are getting the project context. This is just like on the module startup, it is using this other sort of core module to handle dependency resolution. Most common ones you will see all the time are utilities. This is common utility functions that are utilized across different modules settings handles sort of translating our settings content here and the values in there and making it accessible within orbita over in this context section. And updating it here if changes happen to that content. And then the other sort of really core one would be error handling, which handles on any of these other nodes, if an error, unexpected error were to happen. Now we get funneled into there so we can create a record of it and there's some features in here around sending out notification emails whenever's happened. So you have those core sort of modules and then built on top of that you have you get into the more. You know actual functionalities that you'll see in most projects things like flow manager, which handles input to and advancing users through those flow studio flows. And then the big one would be chatbot, which handles the input into and responses back from dialogue flow to chatbot users, as well as presenting sort of these orbita hosted pages primarily used for. Internal testing before you are ready to deploy out to a customer site. And then there is also sort of I guess another category would say have modules that we refer to usually as utility pages that presents sort of framework of. One second here. So we have some additional sort of augmentations of stuff that's you know our administrative tasks that aren't necessarily covered under experience manager. Another new tab here. So this essentially covers pages that we sort of saw a need for in customer success, but needed to get built out more quickly and then they could be created as actual project features. So the big one is going to be version control. So by default in orbita there isn't necessarily any built in version control. So one of our sort of big augmentations that we did work was creating a system for that. So there's a whole system in place that can be utilized. That will take a look at the sort of current project code all of it deconstructed into a format that would make sense if looking at it looking at it all in a get repository checking that in sort of moving it up between stage and production environments. We're hurting if needed. But this, you know, this would be a subject that we'd probably want to get into another call to fully cover it. But yeah, that's another sort of common. Common thing that you will see among the modules things under the sort of category of utility pages, examples being origin control. Sometimes we'll push out one called business hours that's just sort of a complex interface for editing business availability hours. One for content synchronization, but I guess you could say so there's I'm the category of custom tools that are not in experience manager by that we saw any for. Yeah, so we have the module system, like I said, the, you know, thinking behind it was standardized or code be able to deploy it out cleanly like you would say packages within like a node project. And all developed from the thought that OK, no, you know, people utilizing these modules shouldn't need to add the modules themselves. They should be able to interact with it from other nodes. So getting into that for a moment, taking low manager as an example. So a lot of flow studio flows are going to operate on not sure if there's an example here, but operate on interactions with experience designer through custom nodes. So essentially passes control off to experience designer to do some more complex logic and pass it back to flow studio. Initially, there wasn't really a great mechanism for even maintaining these connections. So typically an experience designer, you would sort of need to look for the control ID and handle it based on that. So one thing we standardized was essentially using the custom node name as a function name and implemented all the code for handling that. But obviously the actual sort of hooks that we call them themselves are going to vary a lot project to project. So one example of interaction between the sort of code and different tabs is when the flow manager module here gets initialized. It is establishing a series of available methods in this project context that we referred to earlier. And over on a tab here, this is where we have our custom code for all of our custom hooks that are getting that project context, getting a reference to be flow manager module from it and calling that method to register the hook. So in node red, there are what we call link nodes for moving logic between between one tab and another, I could have say a link out node here that some code flows into and then a link in over here. And connect these two. And that's perfectly fine for your custom code. But in terms of modules, if we had say links like that, so you'll see links within modules within a tab, but links like that between tabs wouldn't really work for code that might be replaced in a piecemeal manner. So that's why you would want to use this pattern of essentially like exposing the functions in context for code and other tabs to call it's going to be much more resilient pattern. I guess I didn't touch on it, but one sort of other important construct in node red development is these contexts. So this is for data shared either between nodes within the same tab or amongst all the tabs. So one context that they allow is the flow level context. So you will see code sometimes like flow dot set and key and the object or other data. So that is establishing that is setting this project property in the flow level context. This code, he any data here is only accessible by other nodes within the same tab. And then there is also the global context. So here, for example, or it's not there, but. So you will see code sometimes that is a similar global dot set or global dot get that is establishing or storing retrieving updating data in this global context. This is shared amongst all tabs in the project and worth noting, this is something to be cognizant of is technically there is one node red instance that backs all projects on an orbita environment. So this would technically be shared not only amongst all tabs within this project, but amongst all tabs on all projects. Which could lead to the temptation to do some clever things of sharing certain code and data between multiple projects in the same environment, but I would strongly recommend against that. And I would say that you should keep things as segmented as possible between your projects, despite the fact that there are some of these gateways in the back end between different projects. Because yeah, it's it's not as like always going to be obvious. So you could change something this global context and have another project is referencing it, you would not really know that and you could unintentionally create issues there. Part of the global context that gets populated by default by orbita is you know, a variety of libraries that may be useful you in certain situations, there's crypto JS is library. Load ashes in their moment and moment time zone. There are some orbita specific utilities around things like I think there's a function here I can you can call to like get the name of the current project you're in that sort of thing. So yeah, there's some potentially useful stuff in there for you. And yeah, I think I think that mostly covers the basics of the module system. I guess I would also just say it's worth taking some time to sort of, you know, familiarize yourself with the available nodes and node red. Some of them, you know, are very orbita specific some are just sort of built in interesting logic nodes around, you know, essentially it's a clean interface for sort of a switch statement of changing direction based on conditions. Every node you see in node red is going to have one input but a variable number of outputs, which makes sense, you know, more than one node can flow into any given node, but there's really just the one input. And in the case of a function node, see if I can find a good example here. Well, so in the case of a function node, you know, all code in here is going to be executed with the assumption that this. This message object has been passed in from the prior node and is carrying some sort of payload to be carried through within a function node I can customize it to say any number of outputs. The sort of standard return for a function node with one output would be just to return the message object. If you don't have a line like this, your execution is just kind of die at that node. There's an alternative form of node dot send message, which achieves the same thing, but this is more useful and sort of when you're writing a synchronous code. And then in the case of multiple outputs, it would be expecting in array. So if I do something like an array of message, no message, no. This, for example, in the case with four inputs would be sending the message out on pins one and three here, but not two and four. So, you know, the order here of what you're passing out corresponds to the order of your output pins. There are some other operators here for say joins splits. This split would operate on whatever the message payload is and assuming it's an array would sort of split it out and invoke the next node once for each item that was in the array. And then at the end, if you do a join, it could sort of join those results all back into one payload for the next node. There's some sorting options. There are some sort of conversion options from different different formats XML, Jason, that sort of thing. Yeah, so I mean, pretty much anything you could want to do could certainly be handled by just, you know, only using JavaScript function nodes. But there are some, I guess that's some other interesting options in here that can lend itself to some clean code. So yeah, I think that's. I think that's everything that I would once everything we have time for right now, anyway. So any any quick questions. And I have one small question. Could you please tell our developers that which tabs or modules are important for them like to change where they will be doing most of the changes like customer and which are not like really they should not focus it more like. Then more of a one time activity. Yeah, so typically like if you'll see all of the customer success modules typically at the end of the list of tabs here, the tabs can be reordered. So that's not necessarily a hard and fast rule, but every module should be marked with a comment tag like this that says CS module do not edit. And that would imply like you don't want to be writing code in here or touching this code really. So anything labeled custom and again, this isn't like a strict requirement, but you know if something is labeled custom that's where you're going to be running customer project code. But yeah, basically it's if it does not have one of these tags, then it's considered sort of custom code for that project from the module perspective. So pay attention to this. One last question. Could you please drag the dynamic data manager note? Sure. And one other. You can clean it any if we have in settings we have that already. Yeah, so in terms of getting a note here, like there is this list on the side, I could do like a filter up here for dynamic data. And a very quick shortcut is if I control click anywhere on your grid here, it brings up this interface for quickly adding something in. Yeah, so here's a dynamic data note. Could you please click on like select the dynamic data node and click on information tab on right side in the content. So earlier we had this help here, which was used to come. Yeah, it is not coming right now. Like all the like how read right everything was they used to show here. Yeah, that is something I'll need to look into. Okay. Yeah, I'm seeing it for other nodes. So it's not a cross the board, but yeah, that's that is no longer there. Yeah, I'll need to check it out. Yeah, in the morning for us, like that orbita help was also not working that support manual that document we have on that was also down, I guess, or something for was some, I don't know, but this was I seen like I was giving some demo to my colleagues and I was not able to, you know, remember the syntax and everything. So it was bit like if they see that they're only then they can, you know, write it better. Yeah, no, that's that's definitely yeah, without that you would have really no way of knowing sort of the intent of you here. Yeah, I'll need to follow up on that. That's odd. That's what I've gone away. But yes, so typically what you would see like here in the function node, you'll see it where there's a whole sort of in this info tab, there's a whole sort of information about actually utilizing it. You should see that for most nodes in here, and there used to be help information here, indicating sort of expected queries around different operations. So yeah, I'll have our team figure out why that is no longer showing up there. That would be it. Thanks. A couple takeaways. We'll check on the why the helps not working in the documentation. We'll send the recording to you as well and any other documentation. We've got kind of on the module process. I think it'd be good to schedule a follow up call next week. Does this same time work for everybody next week? Is it possible like early next week? Tuesday. Yeah, that will be helpful. Andrew, is that work for you? Let me just check quickly. Tuesday at 10. Yes. Yeah, that's fine. Okay, so I'll send out a meeting invite for Tuesday at same 10 Eastern. If you have any questions for him, if you want to send us over, then we can be ready for those and can talk about those more detail on Tuesday's call. But as Mark. I told you that. Sorry. Yeah. So Mark, as that, like, mentioned it multiple times that from our select, we, we always face issue of this modular modular structure. Is it possible for us to, you know, cover like how flow manager works and how we can capture the hooks here and store data like in a modular way? Yeah. Yeah, we can talk about that. Yeah, that will be helpful for team to, you know, go ahead with the new project, which is coming in. So. We will try to keep that as a target and I like team will, you know, meanwhile, they will go through all the training materials and this video what they have learned today. And they will, you know, come up with the questions, which will they have. We will email you that. Okay. Yeah. Awesome. Well, very good. Thank you all for attending today. Thank you. Andrew for doing the training. We'll send this out and we'll look at these a couple of issues that you mentioned and we'll get ready for Tuesday's call. Thank you, Mark and Andrew. Thanks everybody. Hope you all have a wonderful evening or day, depending on where you are located and we will talk to you soon. All right. Same to you more. Take care guys. Bye.