Today we're going to understand what's considered customization vs what's considered configurations and then we'll get into what the impact to the business is for not having a strategy for both. Let me explain what each of them are first.


When I think of customization's I think of anything that can be put into a solution. This is a wide variety of things like: Entities, Views, Fields, Option Sets, Client Extensions, Web Resources, Processes, Plugin Assemblies, SDK Message Processing Steps, Service Endpoints, Dashboards, Reports, Connection Roles, Article Templates, Contract Templates, Mail Merge Templates, Security Roles, Field Security Profiles, Routing Rule Sets, Case Creation Rules, and SLAs. There types of customization's can be exported through solutions and deployed to your test or production or even sold as a product out in the industry. 


When I think of configuration I think of any data and business setup in your organization. For example it would be things like: Accounts, Contacts,  Business Units, Users, Teams, Queues, Goals, Subjects, Product Catalog, Sales Territories, Facilities/Equipment, etc... It could be something as simple as a custom entity that stores information pertaining to your system. This is the data that really enables and is used in your organization. Configuration data extremely important to be in your dev/test/ and prod environments to ensure that your customization's are properly functioning. 

What does it all mean and why is it so important?

Here's the thing; when making views, or charts, or processes that rely on any configuration data consider it's a business unit lookup your filtering on or a specific queue or team. When moving theses customization's through solutions from your dev to test environment it expects all of this configuration data to be in the next environment for it to function properly. But wait theirs more because not only does your account view filtered on team "Delta Bravo" expect in your test environment that there be a team named "Delta Bravo" it expects it to be the same GUID! If this isn't the case then your view won't work; it'll stop filtered until you go back in and select the proper "Delta Bravo" team through editing your view. This is very problematic overall as you build our your base level customizations and all of your configuration in your dev & test environments before going to prod. It's not enough to simply recreate all of this configuration in each environment especially if you have any views or processes filtered on specific configuration data. 

Strategy Time

The first thing that needs to be done is to determine what's "Business Data" or configuration data in your environment. This is the important stuff much like solutions you'll want to move from one environment to the next. Once you've defined what type of configuration needs to be moved between each environment; we're going to use one of the more sweeter tools in the CRM SDK. Inside of the CRM SDK there is a tool called CRM Configuration Migration. This is an application that allows you to export configuration data with relationships intact and export just like a solution. We then can take this export and import or load it into your next environment. It's important to note that it will copy the same GUIDs; this is essential for making your customization filtering via configuration work! In order to keep a proper dev/test/prod environments working you'll need to ensure you have a strategy on not only your customizations but also your configuration!