 Shan asked question, hi all, how do I create a solution and import set of tables from one environment to another environment? Can someone please suggest? Scrunch there? Yeah, suggest. Thank you. Yes. Well, we are talking about the Power Platform and we are talking about moving objects from one environment to another environment. So don't think of an environment like one tenant to another tenant. You could have multiple environments inside of a single subscription. So it's almost like containers, removing objects from a container to another container. If you're in the Power Platform and you want to move something like tables from one environment to another, your go-to should be a solution with a capital S, and that is a project if you will. It's just another container where you are going to reference objects that are either delivered from something like Dataverse or something that you've created inside of Dataverse or the different components. When you add it to the solution, you can do something called export. Well, I mean, that sounds more important or technical than it is. But anyway, you can package it up into a zip file and move it out. But the interesting thing is that you can have options where you could do, it's a managed solution, so no one can touch like the source code, if you will, or it can be unmanaged. So you can deliver something that people can develop. So now you're touching on this ProDev ALM type stuff. But I use it all the time, moving objects around from dev to prod or test to prod, and packaging things up in solutions is a great way just to move the objects. Does anyone else have the experience moving objects around from environment to environment? I'm more a little old school, and it would just be macro. You could just do a simple macro, and it depends on their skill sets, I suppose it depends on what the depth of the knowledge they're trying to bring across and a few other things. What type of solution, yeah. Yeah, that's it. We don't know what the solution is, what they're trying to bring, and from where they're trying to bring it, so. Well, we all were in the SharePoint world previously, and this was an issue with components that were built, and whether they'd migrate or not, and then we had the evolution of solutions within SharePoint, which is now what we're talking about now, and we have over in the Power Platform, but this is another reason to have some oversight or governance model in place. Because if I have a plan to go and build something, and I start working through, if I'm advising with other experts within the organization, that might ask questions about whether this can be supported in scalable outside of my team, across environments, whatever those things are, that's why there should be some process, and that's why Norm, you're right, and this is in the ALM world, it's a having a change management mindset, and reviewing the scalability and the supportability of solutions that are built, so that if it needs to be moved, it can be safely moved and operate the right way, and all those fun things. Not to take the conversation sideways, but regardless of moving things around, having those processes in place, just important for overall life cycle management of solutions you create in your environment. There are lots of best practices that are out there. I mean, that's part of what you have, governance methodologies and things that are out there. You have a lot of experts from the MVP community and beyond guidance on this specific issue of governance. You don't have to recreate your own methodology and process. You can leverage heavily from the community. Absolutely. Shan's question is only one half of the equation when you think about it, whether it's a Power Platform or SharePoint that we talked about, you can create the schema of your table or your list, but you still have to move that data over. That's where it gets a little more tricky. So there's out of the box tools, but there's also the third party tools that a lot of us like to use. Good question.