-Why use a webhook? Yeah. -So really a webhook I would say is what often is the thing that you compare it to. If you want to compare webhook with something else, it's really three main parts that we use a web book, 4 or 3 parts where we try to use a webhook wherever we can. So the first part is that webhooks are near instant. So what I mean by that is simply that if you have some sort of trigger and that trigger makes it so it sends a webhook, then that has the same sort of response time as you would expect. As mentioned, if you type something into your browser, hit enter, right? It's pretty much instant. So that's really the first part. You don't have to do something along the lines of having a scan every 15 minutes or 30 minutes or every few hours. It's really just that. Old, like that old like thing. Yeah, we do a batch run every night, right? Exactly. Yeah. And that kind of ties into the second part where we're talking about like batch batch updates and batch checks where books you usually put it or connect it to some sort of trigger, right? So it usually it's you make the trigger and then that sends the webhook. So you save a lot of data. This way, instead of doing something like you have two separate registries, maybe in two systems and you want to keep them synced instead of having to do one of these like overnight checks where you might have tens of thousands of items in both registries, and you have to go through every item to check. Has there been an update? Instead, we can use webhooks to say from registry one. When this specific line gets updated, find the same item in registry two and update it that way. We only updated one line of data or checked one line of data rather than having to go through an entire registry of data every -day. -So basically your data validation is done from the start? -Pretty much. -Yeah. Which ties perfectly into the third point. You also get kind of trigger based validation. You know that if you have depending on your data structure, you can in for an example, if you keep with the registry one registry, two ones you can have in both registries, you can have some sort of unique identifier that is connected to the line's unique identifier in the other registry. So this way you don't ever really have to do some sort of check and validation because you know that if I check, if I change this item, it's going to correspond to these this side. I'm on the other side. You want to have to do some sort of like search through all this items and find the specific parameters to do that sort of matching. Instead you already know which is the correct one to update on the other side. That's webhooks. It's nothing scary. It's actually rather simple in what ways? But it's immensely powerful in what you can do with it. Have a look because I think you prepared a few cases -or scenarios, right? Of course. -I did. So let's have a look. So first off, let's just if we remember this previous slide where we're looking at it, to use it like a browser, let's use it like a browser because that's also something you can do. So for an example, this is a really simple scenario done in make website usage. Usually, as I said, webhooks are made for server to server communication, but just for this demo we can use a normal website to access the webhook. So this is just really simple scenario. We have, as I said, this trigger module right here. This is just a webhook destination. This is an example of webhook and this would be the address that a server would actually use to send information to this endpoint. You can go ahead and copy that to our clipboard. And really what I've done is here I've just defined a webhook response. Usually what the standard types of webhook responses are are stuff that is like normal Http codes. So we'll be like a three digit code to say something along the lines of this request has been accepted or this has been rejected because of authorization issues, or maybe this endpoint doesn't exist, stuff like that. So it's usually used for some sort of response for error handling. But we can use this for really anything we want. In this case, what I've simply done is I've used one of the formulas available in make to simply get a timestamp of the current execution time whenever we request it, just formatted it to be a bit more nicer. Let's do just that. Let's just go to this webhook and they will get our response pretty much instant, right? So we have April 27th, 2022, 5:15 p.m., which is the current time. Look here, for example. This is one I did just before the webinar. If we just refresh the page, this will solve will also update to the current time. Use. And here you see how quick it is because it actually run around that scenario now as well. And did that response calculated and reformulated the time and everything? And it's -exactly. -All right. So let's move on to some more real world examples where we use webhooks for these few examples. Here we just created a really simple project overview board within Monday here. It's super simple. You have the main items here is a project and we also have a few sub items which we can add, which would be a task. Looking at one of these rows we have just like Project four and the project has task one, two and three. Super simple stuff. Here we have a question which we can actually take right now. Sure. Reuben asked, Can you get a webhook to show no response and not open a web -page? -Absolutely. You could. It's I could also really simply define for this one can even do that super fast here. I can just remove this entire thing and it would define the the response is nothing. That's it. We can we can control our webhooks responses as we want, right? Yeah. Or you can reroute that and we use it for one of our webhooks. We actually reroute you to our web page, so. Exactly. And so look at this, this way, Ruben, as well. When you send a webhook from Monday, for example, no one's going to see that. It's just Monday sending information to an address. Exactly. Webhook communication is. Yeah, it's usually not something that the users see. This browser example is more just to show you what kind that you get responses and that they're pretty much near instant. Yeah. All right. So as I said, this is a simple project overview. Just have some basic stuff like status priority and stuff like that. So what I mentioned before in my presentation where we would have something along the lines of we do something, a trigger. So in this case we do something in Monday triggers the webhook to make and make. Then we do something where we might fetch data from Monday using the webhooks data, which will tell us stuff like This is the row that the trigger came from. This is the column that the trigger came from, stuff like that. We can use that data to then, as I said, put that back into Monday after we do some stuff with the data. Let's look at an example here. For an example, I have this. Each project has a project number. This one has p three. One, two, three. And when I add a task, what I wanted to do simply is I wanted to automatically assign a task number. I want that task number to be the project number underscore and then a number going up. So the first one is going to be task three one, two, three, underscore one. Next one is going to be underscore, two underscore three, etcetera. I also want each project to start this counter from one. So each task number will be unique within that project. And it will also show in which order they were actually created. So what I've done here is I've added a trigger. That is when a sub item is created, send a webhook. That's pretty much it. So if we do this, we say that's one. We're going to trigger one of the scenarios. And what that scenario is. Let's have a look at that. This is the actual scenario. So what we have here here is pretty simple. Once again, we have this webhook trigger. I know that this one looks slightly different than the one we just talked about, but we'll get to why that is. What this then does is first we're going to get the parent item. Now, why do we want to get the parent item? Because the item also has this task counter, which is a supporting column pretty much for this function. And in this way, we're using Monday as well as kind of a database or a backend, right? So each, as I said, each. Project is going to have its own counter for its tasks. So we just have this as a normal number column. And you can see here already the scenario has been run, gave it the P3 one, two, three, underscore one. And as you might have already as well, the task counter incremented by one used to be one. This one was created. So now it's two to prepare for the next task should we create it? Look back here. It keeps -going on along these lines. -And the parent item is also where the -project number is stalled, right? -Exactly. Also where the project number is stored, which is part of our task number. So we get the item. Next, we have all that we need, so we're going to assign the task number. We look a little bit closer how that looks here. We simply assign to this column ID, which is our task number column. We're going to put in here the first part here. Text four is really the back end column of the column, but the columns actual name is our project number. And then we also have the numbers column, which is our counter. -So that's. -Yeah. And here you use the mapping function, right? So you're actually using the dynamic values that you actually got from the module before the get item, right? Correct. You can see here, for example, it says two mappable column values. That's because this is module number two. So this is exactly as you say. It's using dynamic map mapped values to actually input these numbers for you. And the last part, what we do is, as mentioned, we simply update the counter. We go back to updating the parent item ID, which is also something that we get from our webhook. Right. We're going to look more into what kinds of data we get for webhooks for Monday in a few seconds. But here, just to show you, it's really simple. We use a formula once again where we take this mapped numbers column for my parent item. We know this is the counter and then we just add one. We write that back to the counter column and it's ready -for the next execution. -So should we have a quick look just in the trigger, how the information, what it looks like when it comes and remember what the trigger now, guys, was when Lucas created the sub item. So just by craving it Monday will now send the information to the address. Exactly. Can actually look here at an execution. This is the one I just ran. We can see here from the one here is the output data that we got. So this is our actual webhook webhook contains an event and that event contains a bunch of data. This is really all the info that Monday sent along with the webhook to make when it was triggered. So here we have a bunch of stuff. We have what the items ID was, what the boards ID was the name of the item, which was task one, the one we created. We also have some other stuff, like when it was created and when it was triggered and stuff like that. And here's actually for those of you who haven't been working with this before, he's actually when you're looking for the item ID in Monday, it's actually called the pulse idea. And that's a legacy thing from back way back when when Monday was the pulse and an item was called a pulse. So that's why you have a pulse I.D. So don't try to find the item name because you want it's possible. This data is as we just looked at. We can then use this data dynamically. So that's actually what we've done here since we got from the trigger. We got stuff like, for example, the parent item ID, So when we get the paranoid ID we've mapped in this one, which is this module event, paranoid ID, and this is pretty much what we've done. We simply click there on the list and we've fetched that part of data that can will then run dynamically each execution. Yeah. And the get item function overall, it just gets it goes back into Monday and basically get all the other data so you get all the columns and what their values are and so on and so forth. Right. Exactly. Since the webhook doesn't actually want to send too much data, it wants to send you the data generally that you use to get the other data that you want. And that's why we use the supporting columns that get that fetches more data and also only fetches the data that we actually need to accomplish our task. So as we mentioned before, you might have noticed that before we used a module here that is a custom webhook for those of you that might have seen our earlier webinars in integrate which make use to be makes main product. We used to use this module the custom webhook module. Now this custom webhook module has been replaced in make with a module that's specifically meant for Monday. It's really the same thing. But instead what you're going to use is watch events. It's pretty much the same thing. You might even know it is that it looks the same way. It's only to define a webhook. You use it the same way and it works the same way. Just a good thing to be aware of if you're going to build Monday specific scenarios -in make. -Yeah. And here setting up your webhook the first thing you do before you do anything in Monday, you go in here, add this click add that will create the webhook. You will get the address. Copy that. Then you go into Monday and set up your webhook. All right. Should we move on to the next function? -Yes, let's. -Let's do it right. So let's say we have our tasks here. Let's just create another one. Look at the earlier ones. We also have, for example, we have a project manager and then we also have a project team. So the function we're looking for here is simply that when we assign people to the actual tasks which we do on a sub item level, each task has an owner. What we want to happen here is simply that we want to pretty much aggregate up all the people who are assigned down here on sub items back up to the project team so we don't have to actually open each project product or each project rather, to see which people are actually part of this project or working -on the tasks. -And you can of course do this with basically mirroring the sub item sub. But there are some cases when you actually -don't want to have a mirror column, right? -Right. So, for example, in this case, what we can also do here is we can manually add people here. So let's say we have two people who are assigned to these tasks. It will aggregate up those people. Then we also want to add someone else. It might not be directly connected to the task or they might not be assigned yet to the task, but you want to add them to the project team. And this way we can actually do that since we have this column in original here. Exactly. And there's also a couple of Native Monday automations which you just can't run on a miracle, Right? Exactly. Since the mirror columns are are actually client side, what that means is anything that's client side will only really show you or exist when you're viewing it through the browser. So automations and integrations such won't actually be able to see changes in them since they're actually mirroring some other column, which is where the value really exists. And now this is actually a rather great spot to actually readdress a question because he was asking. He'd like to know how he can get mirror columns, data because he can't. He says that he doesn't think that Monday allows for it. No. And here's the reason. It's that it's only actually mirrored in your client. So it's your browser doing a bit of magic for you. So when working with that in make, you actually need to go to the source point. So you actually need to. There's something in a flow controls called an iterator. Correct me here if I'm wrong though because you're an expert, so you need to iterate on the connected column, which is mirrored, right. And fetch the information from there. Is that correct? Exactly. So for those of you who who aren't completely following, you have this column called a connect Board, which is really just you can link items between boards. Once you link items between boards, you can also add this mirror column that we're talking about. And that's really just kind of as it sits, it mirrors information from another board. It doesn't actually exist in this board since it only mirrors some other information, but we know which item it is mirroring since we've chosen it in our Connect board column. And this is something that we actually do a lot and can really not be made with normal automated automations in Monday since you have to kind of get to the source data. So yeah. Yeah, it could be something along the lines of we trigger something here, maybe it's a status or something, and then in the back end, using make and using these dynamic fields that we've been looking at, we can actually go to the item that's connected and find the source column. -That way we can get the information. -Yeah. Or and even go and actually not just have a status column mirrored between the two but actually when this column is changed then also jump all the way back and change that status of that one. But as to if memory serves me right, I think actually our first Integra webinar actually has a guide on how you use the iterator because we go actually went through that. So how you do that. So have a look at our YouTube channel or on our website and look for our first Integra webinar with Viggo. And he actually goes through that step by step -on how to do that. -Yeah. So with that, I hope you're happy. Now let's continue -on. -So let's actually look at this function pretty simple. Let's assign myself to the first task and let's go ahead and assign M here to the second task. You can see when I assign myself, I popped up in the project team and now we also got Emma. Let's say it's also we know that good stuff is going to be part of this as well. So we add them to the project product or the project team, even though we haven't signed them to a task yet. This is also based on completely on webhooks and completely on make. We have a trigger here that is based on this column, right? Since this is the column we actually changed and the action that should trigger what our end product will be. So here we simply have when sub item owner changes, send a webhook. But looking at that scenario. It's also really simple scenario, but it's very powerful. Again, we have the trigger. We know which item it actually triggered. We want to fetch, again, the parent item ID since we want to get the people column on the main item level first. Since if someone's already assigned here, we want to include them as well. Once in the end we actually update this column since we are actually going to overwrite this column and anything that may already be there. So we simply get the permanent ID and then we're going to update it. So here we have involved. Now, this one is kind of also we've done some extra magic to it since we know that you might get some stuff like duplicates. So a person will seem to be present multiple times. But really all this is, is we first have the collection from module one, which is our webhook, which actually also sent with it. Since the People column was the trigger it's sent, this is the actual update that was made. This is the person that was added. So we actually use the merge function here to merge. It's actually an array in the background. Since you can add more people. We merge this array with the array of the main people item column that we just looked at that we get here in module number two. So all it does is it takes this people column and the one we just updated puts them together. But as I said, we might this way get duplicates. So if I add myself here, but I'm already present in the project team. We will get two icons of me. So we also add something called distinct that simply removes all duplicates inside of the array. And then we just write that back. Awesome. We actually got a question asking can a webhook be useful in time tracking columns for tasks, logging workouts, pausing a workout and stopping the time column? Yes. Or part of it. So the time tracking column is the one I'm assuming that you're talking about. I would assume so. Yeah, I would think so. You can put pretty much a simple webhook trigger on it, for example, whenever it's updated. So in this case, that would refer to whenever you stop the clock or start the clock. Also, if you would add a session to it. Really simple since I don't want to go really deep into it because it has a lot of complexity, but something that's just simple to know is each time tracking column holds its own, it saves each session in a list and you can get to this list by first having this webhook trigger when the time tracking is updated and then we get the item. We will also get this column and the values in this column you will get a list of the different sessions. After this, you can really do whatever -you want with it. -To a Google spreadsheet or something like that if you exactly for your time reporting system or whatever. As far as doing more complex things with it, some things like automatically and starting and stopping the clock. I'm not 100% sure if that's possible at all, but if it is possible, it would require something along the lines that we talked in the beginning of the webinar where you actually have to make custom calls. It's not something that's initially built in. And if you want to learn more about that and figure that out yourself, I would direct you to the Monday.com API documentation there. You can search for the time tracking column and you can really read up on everything there and just adding this to it. We have a specific module for Monday custom calls that is going to be this one. Execute a GraphQL query. This is also the kind of code you will get an example code of from the Monday documentation. Hopefully that gives you at least a bit to stand on in looking out that function for you. -What more do we have? -Let's look at another one, which is actually what we're going to do is we even we're even going to chain integration. So we're going to chain webhooks were pretty much what we do is one scenario or one integration is going to trigger the next one. So what we built here is a simple template function. So what we have here is mentioned. We have projects and we have tasks. Let's say that in our projects it's very common that we have these few tasks. Like every time we start a project it might be like. Let's say for an example, scope of the solution or have a have a start up meeting. Stuff like that. We always do these for each project. So instead of having to create them each time we've done some templates. So we've done a separate template board for this. So here we have just simply three templates. Each template has a selection of tasks which are just for now named Template one, Task one. ET cetera. ET cetera. So we can at least tell them apart. So what we done here with webhooks is we've added this status to our project board. And here simply we can select one of the three templates that we've already added. And what we want this to do is if I select template one, it should go into the templates board. Look at all the tasks that are here and add those tasks to the same project that I clicked on. Template one on. That's the function you would want to do and some of you might already have. Thought back to our first thing we looked at. When a sub item is created, we assign it a task number and this first scenario is going to create tasks for us and that will also trigger our next webhook that will assign the task. So this is kind of chaining webhook integrations. Let's have a actually have a look at that. What I'm going to do here just to make it a bit more pretty. I'm going to delete these example items that we made and I'm going to reset the counter to a one. So we start from the beginning. Let's pick template one in this case. As you can see here, we've added some other functionality to this. We've added feedback and that's it. Done. So those of you who were paying attention there, you will have seen that it changed from after we selected template one. It's changed to generating to tell the user that it's doing some work and now that it's finished it's changed to generated.