I want to show you a new way that you can define joins in your catalogs, which means that Count can now intelligently pick the best join path when you're using views in the canvas. This is going give you big performance gains and it also means that you have more modeling freedom to create those more complex models with higher volumes of data. Let me show you how this works and what you need to change to make the most of it today. Previously there was only one way that you could define joins in a catalog and that's in the dataset as you see here. I have my base view defined as customer table and then the joins to my other views in the dataset are defined under the join object. This works really well for more simple models but as soon as you have many joins, higher volumes of data or a more complex model with multiple fact tables, there's a higher risk of unintended filtering caused by those joins and all of your canvas selects will have to go via this base join, which might not always make sense. Now, there is an alternative way that you can set up these datasets. By defining those joins on the view level in your dataset you now only need to list the views that are contained in that dataset. So in this case I don't have a base view and I'm just calling out each of the views I want to be able to access in my canvas. The joins are defined in the individual views and this is using the exact same syntax that we saw previously in the other version of the dataset. You can see in the documentation schema on the right hand side of my screen here we've given you all of the information you need to set up these joins from scratch, but you can also just copy and paste your existing joins to the relevant views. So in this case I'm looking at my customer table view and I've defined the join that I want it to be able to make out to my order data. Setting up your views and data sets in this way means that no matter which views you're using in the canvas Count will intelligently pick the best path of join. This is really convenient when we're working with those more complex models and it's going to give you much more modelling freedom especially when it comes to those multi faceted schemas. All of that said you don't have to change anything and defining datasets in the way that you have been up until now is still absolutely valid. So it's totally up to you how you want to define your datasets going forward and whether or when you want to translate them into our new format using the joins on the view level. Have fun.