Hello everyone. We should now be be live. So while we're we're waiting for people to drop in, I'll take a couple of seconds to to introduce myself as well. So my name is Lucas. I'm one of the team project leads here at omnibus, so I do a lot of project leading and implementation projects. And secondly, that I'm also one of the resident monday.com specialists. So in this demo later on, we'll not only be looking at monday.com and what monday.com solutions can provide for cross-departmental projects, but also how make and kind of complement that and make your builds and functionality even more advanced than what you can usually accomplish using only Monday.com. So I think that we're two minutes in now, so we'll get started and let people who are a bit late drop in as we go. Okay, so today we're going to be talking about Cross-departmental projects and the agenda. Will be to first we're going to go through and just look at some general challenges that we usually see when we're talking about Cross-departmental projects will also look at a specific use case where we've actually implemented a similar solution to the one I'm going to go through today. We'll look at the solution design from more of a high level perspective and just take a look at okay, so how does this actually work? Not only exactly how it looks in monday.com, but how it all kind of hangs together. After that, we'll also go through a demo where we'll look at how this can look within monday.com. And we'll also when going through that, we'll actually take one, one item all the way through the flow and also look at how make is actually a part of that. Okay. So challenges very classic first one operative silos. Most companies or many companies say that they avoid them to every cost. But nonetheless it's very common, especially for medium to large sized organizations. It's just very difficult when you have a bunch of different departments to keep them all intertwined, usually to some form of organizational principle. You need to split them apart to some degree, and then you get operative silos, pretty much whether you want to or not. Within this operative silo way of thinking, very common issues that you encounter quickly is being able to have good visibility between these departments or silos. And even further than that, having comparability between different silos. And this can be something as simple as how people what people, what label people use to say that something is done. This is finished just there. You have two you can like done, completed, finished. ET cetera. So then when you want to compile all of these results in some way, it's very difficult to compare them. We also have the classic of communication. Communication between departments oftentimes have to go all the way up and then way back down instead of just talking directly to each other, which just increases lead times. And usually when going through all of that communication, several levels, some things get lost in translation. Outside of that, we also have a slightly different problem that you might not always think is going to be an issue, but that's having clear segmented information levels. What I mean by that is, for example, someone within an actual execution team so fairly low down in the chain, they might have special needs for what information they need to do their tasks. Moving one step up. You might have project leads and middle management etcetera. They might still want to have somewhat detailed information, but they can't have everything that a task executioner has or they don't need everything that everyone working on task needs. And moving one step further up. We're talking maybe upper management C levels. ET cetera. They probably never even want to see the status of a single task. They just want to have an overall understanding and perspective of how are our projects doing overall, and perhaps even seeing very specific things about projects like projects being delayed, for example. And then lastly, we have another piece of this pertaining specifically to Monday.com. And that is Monday.com is an excellent tool in most ways. But there are of course some limitations. And usually those limitations will be volume. So for example, the amount of total tasks you can have in a single space, what's called a board and monday.com. So getting around that and actually creating a very scalable solution for middle to large sized companies, or even just companies who have a lot of projects with a lot of tasks, can be a bit of a challenge initially. All right. So the use case here. And again this is based on an actual implementation with an actual client. The use case was a marketing campaign planning and production workflow. So we needed to build a monday.com workflow for them where they could use to plan and do production for different types of marketing campaigns that they wanted to do. So a bit about the organization. It's roughly 2000 employees in this use case, a little bit more than a quarter of that. So just over 500 users are actually within monday.com. They had roughly seven teams or departments involved in any potential project. Could be all of them could be a few of them. They also had some differences in what types of campaigns they could have. So sometimes they would have a campaign with a very short lead time. It could be like, we need just a simple banner. We need it by next week. It doesn't have to be super fancy, we just need it now. So low demands on internal resources and also often very short executions for them. But they could also have campaigns with over a year of lead time where there were a lot of planning going into this, there would be months of preparation and the execution would also go on for several months. So there would be a lot of work, but it would still be considered a project or a campaign within the system. So there were some different needs as well for a single campaign. Not all campaigns were alike, and neither should the workflow be. They also had an issue that they had a lot of multiple sources for campaign ideas. Some of them could simply be that people actually working with ideating campaigns, they would come up with some ideas. Sometimes it could even be anyone in the company who just realized, hey, I have a really good idea for a campaign. How do I submit that? And how is that after that actually viewed or reviewed? Do we need any more information? And finally some form of process with a go or no go decision? Is this something that will do what we want? So that's the use case. This is roughly what we came up with. So looking at this diagram from left to right is essentially our workflow. And just from a broader perspective how everything kind of hangs together. So if we start from the start here we had two examples. There were actually more than this. But this is mostly just to show that there can be more. We had submission by a form that would be shared internally, and we also had manual entry. So different sources going into the same space. And that will land in a first space called requests and ideation. This is the space where several people would actually look at these and try to complement it with any information they might need. And finally they would have a go or no go decision and that would move on further in the flow. However, as you can see now, it's actually broken up into two flows. And this was what pertains to a large campaign. So part of the ideation this step was actually defining okay. Is this a fairly quick short lead time small campaign. Or is it something that we're going to require more planning and more internal resources to actually do this campaign. So when they do a go No-Go decision, it could go to one of two spaces. Functionally they're more or less the same, but how they work is a bit different. So looking at the small campaigns first, what this is, is it would be all contained within a single board with small campaigns. Again, going back to the volume limitations in Monday, with small campaigns, it would be very few tasks. It wouldn't even be that many campaigns either. So we could keep everything contained within a single board. And then for the large campaigns, we would actually go a step further. So each campaign would receive their own dedicated space, a project plan board. Essentially, these two are the same a project plan board or what used here is the sub item. So the items underneath the rows. And Monday they would represent a task. But the kicker in the end is that no matter if it's a small campaign or a large campaign, everything still goes into the same execution team. So here on the right side, we have all the different spaces for the dedicated team. So physical graphics for example, they have their own space, legal has their own space. And this was really important as well because every department and space has slightly different requirements, not only for what information they need to execute their tasks, but also just simple things. As I mentioned before, for example, with a status, how do we actually track the status of a task? Some departments had something along the lines of maybe just 3 or 4 ways to track this basic stages. Some might have 10 or 15 stages that they need to go through, but also going back to before that comparability. No matter if the task is a financial task or a fiscal graphics task, there needs to be some way to standardize that status so that higher up in the chain, we can still understand is this something that's been just planned, being worked on, is had been delayed, or is there anything else we need to. About it that can be standardized into one label for all teams. So let's actually move into Monday and look closer at what this means. All right. So first off here we have essentially our boards that we just looked at before when I said space essentially mean a board. So first off here we have a bit of a navigation pane to the left just split by a couple of folders. First we have this requests and ideation space where people could submit their ideas to we receive a go no decision which is going to go into either the small campaigns overview or the large campaign overview. Furthermore, we have a couple of project plans that are generated from the large campaigns overview. And we also here at the bottom we have our different team boards just to add to here as well. This is all collected not within one space but obviously within Monday.com with different workspaces and permission settings. You can make this go out into all different directions within the system, but are still all keeps together the same way. So starting then with request and ideation, they would have a Monday form so they wouldn't need any separate form service. In this Monday form, a requester would just fill in the name of their campaign, campaign description and the date that they need it by. When they submit that form, it would land here as a new item in the top group new. So for example, it might land in here as a new idea. It might have a. Description to it and it would have a date. Let's say this one was something that's needed later. Next year we'll go with 1st of April. So this is roughly how it will look when it lands in here. Or it would be manually input as I just did. Now, what the ideation team then does is they have a look at it, they read the description. If they need more information they can contact the requester. And then they would also need to determine is this a small or a large project. So let's go with a large project in this case. And then finally they would decide if this is a go or no go. So let's say we want to go with this. So it moves down for it down to the group. Something to note here as well is that although we're going to be looking at some May cases in the end, I do also want to make the point here that make is not a replacement for the native automations. The native automations are still great, and they can oftentimes do a lot of the stuff that we don't need. Make for make is a compliment. And the good thing about native automations is it also improves visibility for the actual users, since usually not everyone is going to be in make or even be able to have visibility over what happens in make. But now let's jump into the launch campaigns overview. And then we have the new idea. And this was created here for native automation. So before we get to that though, I want to quickly have a look at the small campaign's overview. You might have noticed when I just switch between those board, essentially the columns are more or less the same. That's because one item in these boards still signify a single campaign. So, so far it's pretty much the same thing. But if we look here under the sub items of this, we're going to see a couple of tasks. So in this example we have seven different tasks for seven different departments. Assuming we need all of them. And then we have some basic information about it for example. And this would be something for like a project lead to fill in. The project lead is going to go ahead and look at the different. Requested deadlines. They probably have a due date of some date that they need it by, and then they can go through and just figure out by which date do I need each specific piece here? Something like that. After that, what they do is they send it to team and here they can create if they need multiple physical assets. In theory, they could either have multiple sub items or you can take it several steps further of defining like specific scopes and attaching briefs and a bunch of things to that as well. But for this use case today, I'm keeping it very basic. So here they would go ahead and just send that to team. And this is where make takes over. So what makes actually make actually doing is that it's looking at this row right here. It's looking at what is selected in this team. And based on that it just implements its own logic to figure out which team board should this actually go to. We can actually have a quick look in make how that looks. So here's this. It's a pretty basic scenario. So what we have is the first what's called a module. It's the one that receives the trigger. Then we have something that just retrieves that row as I mentioned the one that we clicked on. And here we have some logic which might look a bit daunting, but it's really fairly simple. What we do is we take the text from the team column. So in this case that was physical graphics. And then we look at what that says. So in this case physical graphics. And then it shows you a number. That number is the unique identifier for the physical graphics board. After that, we create the team task. And here we also have it dynamically mapped. So this one is going to pull the name. So the row name from the original task item it will be named the same in the team board. It's going to take the board selection from this switch that we just looked at. And then we're going to bring some values with us. In this case we're going to bring the requested deadline and a task ID. Task ID gets a bit more important later on. The task ID is what we actually use to connect the different tasks throughout the system. And this is where make can essentially replace what's in Monday called a connect column, which is the main way you actually connect items between boards if you're not using make. And that's also one of the main limiting factors limit being 10,000 connections per board. But let's move back to the small campaign's overview. So here we can see that it's now been sent to to make actually gives us that feedback as well. Just to notify that yes, this went through. You don't have to try clicking this over and over. And then here we see that there's a deadline actual column. So this is actually once the team receives the task they obviously receive the requested deadline. But the team still owns the resources. So it's up to them to then go and say, this is when we can actually deliver this, whether that be earlier on date or later. Once they do fill that in, it's also going to show here we also have a status and this is the entire task status. Just a couple of ones planned working on it done and delayed. And this also comes from the team board since they're the one who actually owns the execution of the task. Well, we can also do with some magic is we can provide a link. And this link number one goes to the right board since we have one of seven. But it also in the end you might see that it says term and then equal sign and a couple of numbers. You might also see that that's the same numbers next to it in this board. So this is the actual task ID. And that's a unique identifier within Monday.com for that row. But so if you click this button. It's going to take us to that board, and it's going to Pre-filter by inputting into the search bar here, that task ID. So there's actually more items in this board, but we're only seeing the item relevant to us, since when we click that link, we're looking at a specific task. And the general purpose for this is if you do see as a project lead, this task has been laid. For example, you want to figure out more, no more. Then you can click that link to delve deeper into the data. So if I remove this, we'll see that there's multiple more items here. Moving on to the large campaigns. Overview. Pretty much the same deal here. One item is one campaign, but we don't have sub items here because as I mentioned before, if we had those for all of the campaigns, these campaigns usually have a lot more tasks within them. We would sooner or later reach the capacity of this board. So what we have here is we have a button to actually create a plan. What that does is it looks at this template that we've defined. And this template looks like any board. This is the basis of a project plan as we want it. You might even notice that it has pretty much the same columns as we saw in sub item level before in the small campaign's overview. But so if we click here on our new idea campaign. It's going to go ahead and create a new board for us, which we could see just popped up here in this project plan folder and also provide us again a link. So these links are really helpful for actually navigating through the system. Let's say we have 200 project plans. Finding it is going to be a trick. But here you have all the projects in one overview and a link for every project plan to get straight to it. So here we see it's a copy of the template. Here is pretty much the same thing as before. Sub items are just main items now. So here we can still go through. We can set a request a date. And we can send it off to the team. But here we have our own shared space for a project plan, and this also potentially empowers for the project leads. We are probably going to be the primary people working in this view is that here they can even add some stuff to this board and empower them even further. Let's say they want to have a basic email integration they can set up for themselves to email them. If something gets delayed, then they have the power to set this up within their own dedicated project plan board. Whereas in the small campaigns overview, if you were to do that, you set that up for everyone, right? For all campaigns. But here you have your own dedicated space, similar to. Before we get a team board link, you can click that to move into that one. And here we have physical graphics. We have requested deadline. Let's assume that in this case. We're going to be able to meet the deadline perfectly. So the execution team or whoever is owning the resources or tasks they put in a deadline. And if we go back to our project plan here, we can see that deadline actual has also been updated. They might even also let's exit this search really quickly. They might also want to tell the project lead that this task has not been planned, for example. So they change that task to planned moves to a group. Of course. And if we go back here, we can see that this one has also been updated to planned and moved to another group. So essentially we're seeing more or less the same thing, but for different purposes and different informational levels. Here in the project plan, I can see all tasks for the campaign throughout all departments. Whilst in this team board for physical graphics, I only see the tasks that are relevant to my department or my team. So here is essentially just our work. You. We receive things at the top for new requests. We communicate back at deadline, and we communicate the status of that task as we're working on it. I'm going to pass quickly to check if there's any questions. Pierce. Very clear. Fantastic. Okay, so let's actually have a bit of a look as well. Just to look a bit at it again we're going to have a look at creating this plan. Creating the plan is also done by make. Again, not a lot of work really to set this up, but let's go step by step again. We receive the trigger. The trigger in this case being someone clicks create on create plan that sends a webhook to make. So here we have that normal recipe when create plan change to create send a webhook. That webhook goes to this module, which sends a pulse to the next one. As you probably saw, once you click create, it actually changed by itself to create and to give that user feedback. That's make doing that. So going into how this can look, we can see the basic mappings here. We have for what board. In this case it's going to update two large campaigns. Overview which is where we click the button here. It's going to update what's called a pulse ID or item ID. And this is again the unique identifier of a single row in Monday. So that's actually what you can see here as well in the URL. So in this case it updated the item ID of this row in the column Create plan change it to creating. Next step was creating a board from the template. Here we can also define the name however we want. In this case we've named it to always say project plan dash. And then again mapped from the initial module pulls name. And that's the item name. From the overview. So we took this name, the name of the campaign, and we named it Project Plan Dash. That name we can select if it's going to be a public or private board. In some cases you might want this to be a private board or sent even to a private space that only a couple of people have access to. And then here we just fill in some ideas to even further drill down on exactly where we want it so we can say, put it in this workspace workspace as being this one. We can say, put it in this specific folder to keep it really organized as well, and not just have a huge list of board. You can add even more logic to this and say, depending on what type of task it is or perhaps what type of campaign it is, put it in different folders. And then here we also select which template that we want to use. And then finally, in the end stages, we change that project plan status to created to give that feedback that everything went fine. We didn't get into any issues and make through the way. We're also going to create that link. So we actually know in Monday that you can play around with the link a bit. So for example, if I go in here and open this item, we're going to see a couple of things in the URL with numbers. And all of these are unique identifiers. So in this case we have this board. With this number we actually have multiple views in this board. And that view also has an ID. And then pull says that's another name for item in monday.com. And this is the unique identifier of this item in this view in this board. So knowing this we can dynamically say that this is always going to be the start. And then here we mapped in the ID from this module. Since when we create the board that's when it gets assigned its board ID. So we have one question now is this set up scalable or are there any hurdles that needs to be considered like monday.com number of connection between boards. So this is essentially going back to bit before, as I noted that there's going to be a task ID this task ID essentially replaces that connect call. So within monday.com, for those of you who don't know, there's a column type called Connect Column. The connect column allows you to connect one item in one board to an item in another board, or multiple boards. You can also select multiple of them. This is one of the limiting factors within Monday.com because as mentioned, you can only have 10,000 linkages within a single board. This is usually plenty, but in some cases, going back to that example of having hundreds of campaigns and each campaign has maybe 100 tasks. If you want all of those connected together, you're going to reach that limit sooner or later. So what we do instead is when we create these boards or we create these tasks, at that point in time, we know the unique identifier of it. As we looked at before in the URL, these unique identifiers, we actually know that that because that's information we received to make. And because of that, we can actually tag items or boards at any level with that information. So again looking here at the specific project plan, each of these tasks has a task ID. And if we look here again in the team board we actually carried that ID with us. So. Going into the next example with make sinking values. Back to the project plan, we can have a look at, for example, sinking the status. We have here a webhook on this status column whenever that changes. Which looks like this. Once data changes, send a webhook. And then we retrieve that item. We pull from the received trigger module. We pull the unique identifier of that item. We also have to get a target item board ID. Reason being that when you update Monday.com items, you need to always provide which board is this item actually in? And the information that we have on this initial row in the task ID is the unique identifier of that row. But here we actually know. From experience that if you just want to retrieve a single item within Monday.com, you don't need to define board ID. So we just put in the task ID here from the triggering item, and that's actually going to give us some information, including the board ID from where it originates. And then finally we can say in this board on this item update the status. So that's fairly long explanation to your question, but that's essentially how you can get around connect column limits is that we use, for example, text columns to save those connections instead, but still retaining the same functionality of relating, for example, one tasks to one task, which is going to be the case between a team board and a project plan. And even going one step further, you want to relate tasks from a project plan back to an overview. Since this is usually going to be multi-step process going back to the solution design again. We have, as mentioned, three different levels of information, one being the overviews, one item is a project. And then we have under here and in the project plans, one item is a task that we can see all tasks across departments. And then finally also one item is a task within the department boards. So here in the first step we have a 1 to 1 relationship. One task in a fiscal graphics board is going to be one task in a project plan board. So that's a very simple connection to when you change a deadline or status change to same item in the next board to the same deadline status. It's a 1 to 1 relationship. But moving one step further now it gets a bit trickier because now we're going to have, let's say, 30 tasks, but we only have a single project, right. So we need to for that transfer we need to define some form of logic. For example take the status column. -If a project. -Status is working on it, what should that be on a task level? Does that mean a single task has been started? You're working on it, a specific task is now working on it or even going one step further. Let's say that one task is delayed. Should that mean that the entire project gets was delayed? Or does it need to be three tasks for the entire project to be marked as delayed, etcetera? So there's a lot of different types of logic there as well that you can really customize in those things, and aggregation of data all the way down from the team specific boards up to the overviews. And all of that is done in make. There are some things you can do in Monday just to be really transparent, to get close to it. There was also some apps that you can use that go a bit of the way to do the same thing, but if you really want to get it exactly the way you need, then usually make is the tool that allows you to do that. All right. So that's really it for the demo. If there's any specific other questions you want to ask, feel free to send an email to us at Monday at Omnicom. All right. Thank you everyone. My name is Lucas Anderson. And take care. Bye.