Very much welcome, everyone after the summer to this webinar all about integrations with GraphQL in monday.com and Make. And with me here today we have our resident specialist when it comes to Make and integrations -Lucas Anderson. -Hello everyone. Hope you're all doing -okay. -So Lucas, let's dive right into it. I think the people are more interested in what you have to say. Then what -I have to say. -Sounds good. All right. Let's get straight into it. Just starting off with the agenda, what we're going to look into today really quickly, we're going to talk a bit about what GraphQL actually is, the use cases that we generally use it for. We're going to look a little bit at the GraphQL format. So actually how are the graph queue queries actually structured. So we can actually understand what they do and how they do it. And then we're also going to go through some actual examples where we will actually go into our monday.com board, go into make, and we're going to look at some executions and how it actually -acts and works. -And, uh, Lucas himself can't see while he's sharing the screen and everything. He can't see the shot, but I can, and that's my work. So, as per usual, guys, we will have a Q&A session towards the end. But fire your questions when you get them so we don't miss anything. And if they fit, we'll take them right away, as we usually do. Otherwise if they don't fit just then and there, we'll wait and we'll make sure that all questions is answered at the end. Um, well, Lucas, -what is GraphQL? -Well. What GraphQL is, is very shortly explained. It's an alternative. So there's multiple ways of interacting with an API. Maybe some of you are familiar with the term SQL or SQL. So what it really is, is simply a language or an interface that is a way to basically interact with other systems. So getting information or inputting information into a system. So compared to some other alternatives on the market, GraphQL is a method that really simplifies the process. Just as a fun fact, GraphQL was actually initially developed by Facebook and used internally and was released to the public open source in 2015, I believe. But what it does is the main kind of use for it, or how it can be used compared to SQL or such, is that usually when you interact with some form of API service, then you have a lot of different what's called endpoints. So for each and every entity within a system, say like for monday.com, we could look at a board or an item or a user or can be a multitude of different things. You would have to configure it for that specific entity. GraphQL kind of abstract defines this whole process. So instead of saying where you want to do something, you simply say, what do you want to do? And it translates that for you. It will also help a lot since it returns very predictable results since the way that it is structured where you say, I want to do this thing and this thing only you also in the same way say, and I also want this specific information back. You will might also notice if you've been coding or using Json at any form, then it also kind of looks like Json. So you will get the same sort of results back in a very interactive way. But. So why should you care about this at all? Really? Since. You're not. Maybe not experts at designing and making systems or APIs. GraphQL is the way that you interact with the API as well. So this is what we use sometimes to make our monday.com and Make integrations. Awesome. So what do we use it for -specifically? -Yeah. So we have quite a fair bit of use cases, but we're going to look at a few now. So a few of the things that are more related to getting information from monday.com is, for example, the activity log. And just to be transparent here, what we're talking about, what we can do specifically with GraphQL. In this case, what we're referring to is there's no standard modules for it in make, since the standard modules need to be fairly abstracted, so it's easy for user to use. These are very specific things we use GraphQL for. So first we have the activity log. We can get the activity logs on every single level in monday.com. So we can get item activity logs boards activity logs and etc.. This is -really useful. -Yeah. And for those of you who aren't really with us here, when we say activity log, it's basically the log of everything that's happened in a board or on a specific item, every changes that's been made or updates and -everything like that. -Exactly. We can also get very specific information about columns. So we can get column settings. We can get column descriptions and column types. So for example say we have a numbers column. Some of you may be familiar that you can input a specific prefix or suffix like a dollar sign euro sign, percentage sign such we can actually know via the API what exact sign this is. We can even like know if it's situated on the right hand side or left hand side, stuff like that you need GraphQL to get. We can also clear updates, and by updates we mean those the chat bubble icon on each and every item where you get this kind of forum style input interface. What we can do is we can go through a board and really quickly clear all of the updates. This is something that you can do with any native monday.com functionality or automations, and there's also no native functionality to do that with the monday.com API modules in make. We can also do the same for column values. This is particularly useful since some of you may know if you're a frequent monday.com user, that there's a column called the connect column that has a limitation on how many unique connect values you can actually have before the system stops you from inputting anymore. This can be really useful to just help out with clearing those out by some sort of rule or -logic. -Yeah, that that can be really good and in that way work with the within the limitations of the system. Exactly. We can also list deleted or archived items. This is also useful since you might sometimes just have a bunch of items that you don't know where they're located. Someone might have accidentally deleted or archived them, and then you can just easier keep track of these. There's also a very good reason to use GraphQL, and that's complexity budget. For those of you who do not know what the complexity budget is when we're referring to Monday API. The monday.com API has a limit on how pretty much fast or complicated queries you can run against their API. If you try to query or make too many changes in too short of a time span, it will actually block you and it will tell you to wait a certain amount of seconds before you can continue to use the API. What we can do is we can actually ask the servers for how much complexity budget do we have left. That way we can also make some logical decisions on, for example, how to wait or even when to wait, since we don't want to accidentally stop in the middle of a transaction, but rather we might want to finish the entire transaction, wait if needed, and then continue. Yeah, and to be fair, here monday.com has a 10 million complexity per minute, uh, I believe, but it's a running minute. So at any given point, that minute starts and then it ends and you can start something in the middle of that. But so it's basically on an average 30s or something like that. But. But you can't run higher API calls than a complexity of 10 million within a given minute. And then it basically resets itself all the time. Is that a fair explanation? Yeah, I think that's a fair explanation. That's a that's exactly how it works. And adding to this. This is also something that we're actually going to look at an actual example later on, some foreshadowing there. Yeah. And this is going to be a really good example for those who actually run a fair bit of integrations or extra -automations within your system. -Especially if you run those using make rather than integral mod. We'll get later. We'll get to why that also makes a difference. Overall, I think what's the most important takeaway from this as well? Kind of connected to the complexity budget, but also the runtime of your integrations towards monday.com is that we can make much more tailored and therefore more efficient calls, meaning both calls to cost less complexity budget, but also simply calls that will complete faster and gets quicker and snappier -integrations overall. -And actually run on less operations in make. That as well. So overall, GraphQL is a really good tool when you want to make very specific or customized solutions. And I think you will get into that. But it's also like you can actually combine things that you would have had to use several modules for, uh, in, in May to actually run that in one command. Right. Exactly. That's for those of you who are not completely familiar with, integrate or make. The way that make integrate actually builds you is the number of operations or modules or as it's shown, small circles. So each and every circle is called an operation. Using GraphQL, we can actually accomplish the same thing, but with fewer operations as -well. -Which might be neat. Which can be very neat. And sometimes this is actually a huge difference, especially if you're a small scale, maybe middle scale user of integration and make and don't actually want to pay for a substantial amount of operations and can get by with a very simple subscription tier. All right. Let's look at the actual format. How does GraphQL actually look. So here we have a more abstract example of how a GraphQL code actually looks like. So the first part of it is simply one of two options. It's either you're going to tell GraphQL I want to ask for some sort of information only, or I want to change something. Meaning you want to update something, you maybe want to create something, or you want maybe you even want to delete something. After you tell that, you're also going to tell it, what do you want to ask or change? You might also notice that you have these curly brackets around. If you're familiar with some sort of coding, then you will know what these means. It's simply containers. So the ask or change word that you start off with as a starting container and an ending container, saying that all of this in between those curly brackets is my question or my change. After that, you say what you want to ask or change. And within parentheses, we're also going to see a bit of a clearer example below. But within the parentheses you say which for example item or board you want to change, or maybe how you want to change it or ask about it. Lastly within this container block as well. You simply tell it after I've done this, this is the information I want to get back as well. So that's actually look into a more actual code example so we can see what this does. This GraphQL query. What this does is it asks monday.com for two items or rows, and we want it to return the names of these items. So we start off with the term query, which is the GraphQL language for asking for something. So just retrieving some information we're going to ask for items, since usually if you go back to the first talking points we talked about SQL, you might have to define a specific endpoint for items, but in this case it's enough that we simply write items to tell it. We want the items and they will figure out the endpoints themselves. Within the parentheses. It's the which and how we're gonna input here we have two item IDs. So these are the IDs of the items in monday.com. These can also be accessible from the URL link in monday.com for those of you who are familiar with that. We input these numbers with a common between to separate the different item IDs, and then within this block we simply write the word name. So we're asking for items these two specific items. And we want to get -the name back. -Easy enough. Easy enough. It's fairly straightforward. Looking at another example along the same lines here we have the word mutation, which is the graphical word for changing something. So creating, updating or deleting something within the system. Here instead, since we're not asking for an item here, we're going to use the term create item to actually use this end point for creating items and what it wants to know when you create an item is the board ID. So we're going to input the board ID, and it also wants to know what item name should the new item have. And then again, we can still, even though we're creating an item, we can still define things that we want to get back for an example. Obviously, the name we're probably already going to know because we just put it in, but we might also want to save this new created items item ID for some other use, maybe within the same integration or maybe within another. So this is the general format of a GraphQL query within the span of how it works with monday.com And when you write the code through May later on, you can surely use the dynamic values if you have earlier things coming in your scenario. So actually pulling the schema. Exactly. That's generally how we would use it, since it doesn't provide much functionality to run an integration that always simply creates a new item with the same name. So just as Fredrik said, we we generally pull some sort of information from elsewhere that we then map into these fields to dynamically. In this case, we could dynamically create items with item names based on something else. Perfect. So we have no questions in chat so far. So if you have them guys fire them off. Uh uh. Otherwise, uh, -let's go on. -Let's do it. All right. Let's actually look at some examples with monday.com -and make and GraphQL. -Uh, yeah. So here we have a very just simple CRM setup. The actual setup is not really important for this webinar, but we have a few items. We have a few columns. What we're going to do is we're going to look at actually live interacting with this board using GraphQL and make. So let's start off with actually looking at these two queries that we just looked at. But just in the presentation let's actually see them at work. So here we have the first query that we looked at. We had get specific items. What I've done is I've put this in. And then, as I mentioned, you can open an item like this and it will actually display the item ID in the URL after the term pulses. So we've done this this for the top two items. So deal name one and deal name two. And put these into what's called the parameters of this -query. -Actually, when we are, uh, in, in this section or actually in the next section. Uh, we actually got a question here. Uh, fine. Enough about creating one item, but can you create multiple items in the -same line? -Good questions. Uh, you can do this several different ways. Uh, just to be very transparent or clear here as well. Generally when creating items with make. We would use the native modules for this, since the GraphQL version of it does not necessarily provide any extra functionality. The native modules in monday.com that you have. So for example, the create an item module. Does the exact same thing. It also communicates via GraphQL, but it helps you out with the mapping and writing that code for you. The reason that we use it in this case is, first off, mainly because it's simple to read and simple to understand as an initial GraphQL query. But how you would answer your question? Create several items. You would still either have to make a query that includes. It's several times, so simply you could do something like this. Or a more reasonable way with. With Make or integromat, you would use the what's called an iterator that will be input some sort of array or number that is going to do something several times, and each time you do it, it's going to be connected to some form of iterator that just keeps sending out bundles and creating new items again and again. So creating multiple items would not be done within the same query, but rather using this query multiple times. Yeah, because that way you can also get it to be dynamic, right? Exactly. That way we can control the name. So it does become different by some factor. For example, using the iterator example, you might put in a list of a bunch of names you've gotten from somewhere else. And when it goes through the iterator and creating the items, you would actually map values from the iterator that changes for each bundle or pulse or iteration. -Cool. -Awesome. So let's look at actually running this one. We as mentioned put in two item IDs. We're asking for items and we want to know the names of these items. All right, so we got some data here. We're going to open the body data items. And here we have two items. First item with the name deal name one. And our second item with the name D. Name two. Looking at the other one that we also briefly looked at before. This is a mutation that creates an item in the board that we just looked at with the item name, new item. And running that. Let's go back to our board. You can see here that this item was just created. I can even confirm in the activity log here that it was created now. So those are two very simple examples of GraphQL. As mentioned, usually when we do these things we use the native modules. But it can always be done fully using GraphQL. And here's actually should we perhaps show what module you're actually looking for when you're trying to add a -GraphQL code? -Absolutely. Good point. So within the monday.com library of modules, we have a specific module that actually just says execute a GraphQL query. And the reason why it's its own module is you still get some help from Make to use your connection that you previously set up, so you still don't have to set up your authentication process. -Very good point. -Awesome. And actually, as you saw now in the activity log, when Lucas changed into that, you could see that it was he who had created it. And that's because he had used his API key to the system. So that's also something to think about when you set something up in a system. What API key are you actually using? Because that is the user that's actually going to -execute everything. -Exactly. All right, moving on to the next example, the one that we hinted to previously, the complexity budget. So here we have how the complexity budget query looks for in monday.com It's very short and even simpler than the previous ones. We ask for something. We're asking for the object complexity, which is a top level object within monday.com. And then we have within that. You might also notice that now we have actually two blocks again. And within the second block we're asking for two data points. We're asking for reset in x seconds and after. What after means is the exact number of our current complexity budget. After this runs reset in x seconds returns how many seconds left we have until the next reset. So let's actually try to run this. Here we have in the data complexity. We still have our full 10 million complexity budget left and it's going to reset in 60s. This is what Fredrik referred to previously is as soon as we use up any of this budget, this is going to start counting down. So it's not going to start counting down from 60 once you're fully out of budget, but rather as soon as you're not fully topped up, this is going to start counting down. So this is also very useful that we get this exact amount in seconds until the next reset, since we can use this within our scenario as mentioned. For example, we can make a filter like this. We can map in the complexity after value. And we can say that if it's less than, in this case, 1 million. So in this case it's less than 10% of the budget left. We're going to run this module, which is simply a sleep module that pauses the scenario for a set amount of seconds. And here we can map in the actual reset in x seconds. And we're simply just going to add plus one to make sure that we don't just barely snug the timeout for this. This is something that we use quite often, especially in Make. Getting in. -Why Is that? -There's a very good reason for doing this in Make specifically. Uh. Previously Make was called integromat, and a very big difference between these two systems is that integromat would always work sequentially, meaning that if it gets an execution into a scenario, it's going to wait for this execution to finish before it starts receiving the next execution. Or rather, it can receive a bunch into the queue, but it's only going to run one execution at a time. This is not true for Make. Make can run a bunch of scenarios in parallel, meaning that say you get 100 webhook triggers to do something. At the same time. Entanglement would do that one after the other Make will attempt to do. Maybe not all of them, but a lot of them at the same time. Meaning that you're going to use a lot more budget in a smaller time frame. -Yeah. -And to give an example where I forgot to do this a bit back was actually I try to import contacts into a CRM system and there was wasn't many, was maybe a couple of hundreds, but there were a line information on them and maybe 500 contacts and it's probably. 10 or 15 columns of information going with each. Uh, yeah. monday.com had a shouting match up made with that one. So, uh uh, I should have timed that better. Fair point. Yeah. So this is just these two modules really, when you start getting a lot of executions, it's really going to be a lifesaver. So just putting these combinations at some key places in your scenarios is going to save you a lot of headache. All right, moving on to our last examples. -Anything you want to add before we do? -No, we have a few questions, but we're saving them for later, so sit tight. Uh, you, uh, those of you who -have asked those questions. -Sounds good. All right. Getting into some more examples here as well. Kind of reflecting back into the point when I spoke about having more efficient calls, even both for complexity budget on the monday.com side, but also the operation usage within make. This example is getting an item. We can have a query that looks like this, kind of similar to the earlier query we had, where we ask for specific items. We're asking for two items. We're asking for the name. But here we're also going to ask for the column values. Here you will notice that we're adding another step of curly brackets since column values. Also has its own properties within it. So in this case we're going to get two items. We're going to get the column values, all of the column values for the items. And we're going to return the ID of the column, the value of the column and the text value of the column. Now this is just a little bit of a tip. Why we actually get the text value is because the value parameter through the API is going to return the full Json string of that column value, meaning that you're going to get a bunch of extra information like column settings and maybe the names of the sub variables within the column, which is just a headache to work with integromat, since usually you just want the text value that the user inputs or can see within monday.com that can be found in this property, which is why it's good to add it if you want to get column values. Yeah. Anyway. In a lot of the Make modules right that you have that you can choose the value or the text. And this is basically that. Right? Exactly. When you use the native monday.com modules, for example, for getting an item, it's going to get all of these as well and just put it in in separate data field so it's easier to map. But this way you make sure that you still get this text to use. This is usually what what most people will use anyway when they use the native modules is the text value of a column. All right. So running this module on the same items as we looked at before. We still have this structure of the body the data the items the two items. But now we also have as before the name and another level. That's the column values. So here we have all of the different column values. You can look at a few of them. For example we have the sub items column. Then we also have. This is probably a good example to look at. We have a status column. The value of the column is this Json string, which is a headache. You say you you have the status column. It simply says lead. You're probably not interested in the index of the value or the post ID or when it was last changed, but you want the text value that just says lead. All right. Moving on. Here we have another step since, let's say sometimes when, especially when we have big boards with a lot of columns, maybe we even have 100 columns in a board getting an item with all of the columns. First off, it takes a lot of more complexity. It also takes a lot more time, since the server API has to actually put this information together and send it back to you, which, if you're getting a lot of items really quickly, will have a huge impact on your execution time as well. To get around this with the native monday.com modules within make, you can do something along these lines. You use a specific module that's called Getting Items column value. Within this module you can get a single column for a single item. Problem with this is let's say you have 100 columns you're interested in ten. To accomplish this with the native functionality, you would need ten of these modules, meaning that for each item you run, you will need ten operations to get all of the column values, which is probably going to stack up really quickly. This is where we get into what we can do with GraphQL. We can actually use this first GraphQL we looked at and we can make it more specific. We still have the same structure we're asking for item. We're asking for the name. We're asking for column values. But here just as we added the parameter IDs for the specific items, we can do the same thing for the columns. So here we also add IDs. But instead of item IDs here we have column IDs. -And how? -How do we fetch the column -IDs from within monday.com? -Great question. Let's actually look at that. So if you go into monday.com, something that you're going to have to activate before you can see this is you're going to go to the profile portrait monday.com Labs and you have something called developer mode. Once you activate this, you can access a lot more of the back end data that the normal users are probably not interested in, including, for example, the column IDs. If you click on the settings for the column here, you're going to notice that I have another row of information here, which is the actual column ID. So this you might already recognize as one of the columns that I'm fetching, we have the column numbers, and I've also selected the column numbers zero. These are what I've input into my parameters here. So we have the IDs numbers and numbers zero. Then we have the same as before. We have ID, we have value and we have text. So running this query instead, it's going to be a lot more specific. Now we still get the items, but now we only get two columns here, which is the numbers column, and the number zero column, which have the values 70,090. So this with double double use of operations. And this with a single module accomplishes the -exact same thing. -Yeah. And here we can be it can actually be scalable to not 1 to 2 but basically 20 into one. -Exactly. -So this is extremely good when you're trying to handle, uh, your Make budget or -operations. -Sometimes this can actually even be something that you have to do. If you go back to the the case of a really big board when you're starting to get above. 70, 80, 90 columns or further beyond that, obviously, depending on what exact columns you have, since some are heavier than others. But sometimes what you will notice if you get a full item, it will be so much information that the entire call times out. And in that case, the only way to get an item where you want specific columns is either this example of getting a column by a by each module, or a GraphQL query like this, where you get everything -within the same module. -All right. So these are some fairly basic examples. Is that fair to say? Uh, if you aren't extremely knowledgeable about GraphQL code and especially how monday.com works with it. Uh, I guess there are some sort of documentation regarding this as well. That's right. This is also something when you do get into writing GraphQL code, the monday.com API documentation that I have here. So developer.monday.com this is going to be your best friend since here, not only do you have all the information you need, since I happen to know that to ask for items, I write the word items, but if you don't, this is where you will find the information. So here we have the items and you can even see here that they have ready to use core structures of these queries. So let's say you want an item. You can just copy this full thing and then you just make adaptations to it. You can see further down as well. You can see the arguments that you can input, the arguments being things you input between the parentheses. So you can limit your search results by the arguments. And you can also find all of the fields that are available for querying for a specific entity type. So here we can actually see that for an item you can get a lot of different data. You can get the creator of the item, you get the name as we looked at can also get things as we talked about before like state, you can see if the item has been archived or deleted. This is definitely if you do want to try out making your own GraphQL codes. This is definitely a place to get comfortable with and just look around. Awesome. So people developer.monday.com they have everything and it's structured in the left pane. So you can easily find the different section for like groups and items and everything. Yeah, as you can see. So go to the section that is pertains to what you want to do. And you will find and you will always find those code snippets as well. So it actually tells you how -it's basically set up to work. -Yeah. With that, I think we are moving into the region of, uh, Q&A. Right? -Sounds good. -Uh. Yeah. So Joseph had a question. Can you please explain how you would use the iterator to add -multiple items? -Um. -Sure. -All right. So let's get back into that example. We have the create item. So um. Iterator in Make just starting off there you're going to probably want something before this. So let's really quickly I'm going to make a a simple. A simple array. Actually, I'm going to do this. For those of you who are somewhat familiar with coding, an array simply means a list of things. So in the in this case we can use split. So we can say one. Item two. Item three. It's just if I can get my array. We can put this array into an iterator and what it will do. Is for each item in this list, it's going to send out what's called in and make as a bundle or a pulse into the following modules. So this flow is simply I create an array with three items item one, two and three. I put this ring into an iterator, and for each item I'm going to want to create an item. So here, instead of having the item name new item each time, we're going to map this into the value of the array that we've looked at. So let's actually try it out. There. You can see it's been run three times. If we go to our board. We're going to see item one, item two, and item three. I hope that answers your question. Yeah. So you both have an iterator, which basically takes one package and make it into several. And you have an aggregator which takes several packets and make it into one. Uh, and actually the icon of that green blob is actually kind of telling because it's actually a parentheses. So it's one going into many and the aggregator goes in reverse of that. -Exactly. -Uh, we actually had one question earlier from George. Um. About. Let's see here. Uh, can you write an example for saying when a formula column is greater than zero, change status to positive. And that's no, because this formula aren't on the server. It's on your client. So. When monday.com, changes of formulas are actually calculated on the server. Yes. You will be able to do that right now. Now you can't. But what you can do is actually run the formula itself in make having it to make the input into a text column or number column or whatever, and then it can be done. Is that a fair explanation, Lucas? No. Yeah, I think you you said it very well. What you would do is whichever columns that you initially would put into the formula in monday.com, those would instead be your triggering columns. So you would put a webhook on column changed for them to go into Make to make those calculations to formula previously did. That way you get full control of this information and any updates of this information -within make. -Yeah. And and this is actually something we tend to do at times just to be able to actually use the information we get from the formula, because in that way we can actually use that for automations and for a load of different stuff, which we can't when there's a formula column in the world of monday.com So that's why at times it's actually quite smart to run the formulas through Make instead, -depending on what you need to do with it. -Very true. Uh, okay, guys, I think we have answered most questions, so we have a few minutes left. If you have any more questions. Now is the time. Um. Uh, use this time wisely, guys. Lucas normally charges over $250 an hour. Okay, so no more questions. So with that, my friends, uh, we're at the end point of this webinar. Thank you so much for listening in. Oh, here we come. Actually, we have a question. Can I see quickly what you use to create the list? Um, yeah. It's the set variable function. Yeah, I did it really quickly just to get the list. If you're interested is I simply use the function split. The first argument takes in a text, and the second argument I tell it what to use as the separator. So here I simply wrote the text item one, comma item two, comma item three and told it for each comma. Use this as a separator to make a array list. So this full function spits out an array with three items, which are the ones I simply typed in. In this case, usually this is probably not how you initially get the array. You're probably going to get it from somewhere else. But but this is this is simply the way that I quick fix it. Now for the example. Yeah. And when you look at that dynamic data fields, when you get to schema from monday.com, a race will be marked with brackets, -right? -Yes. Uh, so you can actually see just on, on the header in monday.com if they are an array. So like you see at the end of array here it gets those two brackets. That means it's an array um which you can run through an iterator for example. Um. With that said. Thank you so much for watching, guys and see you next time. -Thank you for listening in. Bye. -Take care. Bye. Thanks for watching. If you liked our content, remember to subscribe.