D365 Saturday Boston 2019: Solution Management Presentation

It was great to be involved in D365 Saturday in Boston this weekend. There was an amazing line up of speakers and so many enthusiastic attendees.

Aiden Kaskela, Todd Mercer and I led a session on Solution Management. In this panel we explained what a solution is, how to use them, and gave an introduction to change management. We also started into the great debate of Managed versus Unmanaged solutions.

Slides are available below. You can also watch an earlier recorded version of this presentation on CRMUG or register to join our next session on February 19th.

How are you using solutions in your environment?

Copying Records with GUID in Microsoft Dynamics 365

If you are using workflows it is likely that you need to link to specific records in the environment. One issue with this occurs if the record is manually created in each environment so when migrating workflows via solutions you still need to manually edit the workflow and re-link to the correct record. This is because the record GUIDs are not consistent across the environments.

But there is a solution!

I was working on this very issue today and had to re-learn how to handle so I want to document it for myself and hopefully it will be beneficial for you too. 

In my case we are using a Queue to send an email from a shared inbox via a workflow. So what I can do is create the Queue in our Development environment and then use an Import to create in other environments with the same GUID.

Steps: 

1. Create Queue in Development environment.. Populate with all necessary details such as name, email address, etc.

   

   Create Queue record in Development environment

2. Create an Advanced Find of these Queue Details. You will want to include any fields you populated such as the email address and description.

   

   Advanced Find to isolate new Queue details
   

   

   Export fields from Advanced Find to get GUID and ensure data matches

3. Export the details from this Advanced Find. This will include the GUID of the record.
4. Open this file and expose columns A, B, C.
5. You can delete columns B and C. Then rename A to "GUID" for clarity. Save this file as a .csv
6. In your next environment, click on Import Data and select the file you just saved.
7. For Mapping, select the entity you want to import to (in this case, Queue) and then map any fields that are needed.
• Map your "GUID" field to "Queue (Primary Key)"
• Keep in mind some fields are set by the system so they may not let you map them. These can be ignored.



When importing map the "GUID" column to the Primary Key for the entity

8. You can choose to save this map if you like for future environments. Then click "Submit"
9. When the import is done, verify the new record was created and you can check the GUID. All should match.

If you entered a name for your Data Map (last step of import process), then you should follow these steps before moving to the next environment:

• Settings -> Data Management -> Data Maps
• Select the one you created and click "Export"
• In your next environment, navigate to the same area and click "Import"

In your next environment you will use the existing file (from your Development environment) from step 5, no need to export again. For step 7, you can either remap or select the imported data map name.

I hope this is helpful for you! Have you had this issue in your organization? How do you handle?

New Year, New Change Management

As we enter the new year it is always a good time to evaluate where you are and where you want to go. This is also a good time to evaluate how far you have come. I have been reflecting on the change management progress I made at my organization. Let's talk through what that looked like, steps taken and next steps for the future.

Background

I started as the first subject mater expert for Dynamics CRM (this is back when it was still CRM not D365). The organization had migrated to CRM 4.0 and then upgraded to 2011. So there had been a lot of fairly rapid changes all being managed by a team that had other non-CRM priorities. 

This resulted in frequent releases, possibly multiple times per week. The solutions were built the night of or changes were manually made in each environment. Testing was on the fly and based on anecdotal system knowledge.

The team had done a great job on their CRM system and had developed their release process to fit the business. As the system and team matured, there was a need to adjust the process to fit the complexity of the implementation.

First Steps

The change management revolution started with a few small steps.

1. Building the solution first - whenever working on changes for a release the solution needed to be built first. This allows you to add items as you work on them and ensure nothing is missed. This ensured that on release night the solution was ready with all required components.
2. Enforce the use of all environments - all changes needed to be done in all environments. We had a Development, Test/QA, and Live environment. It was important that all changes were made in Development in a solution (step 1), moved to Test as a mechanism for testing the solution, and then imported into production.
• This is important so your environments can stay as closely in sync as possible. We had a case where there was an option set with 50+ values. As the new system administrator, I added a value in Development and then moved the solution to Live. Then we found out that another team member had been creation options in Live that were not in Development. This meant the Live-only options were no longer visible or potentially overwritten by the Development options. Thankfully this was able to be resolved with no data loss due to the use of these records but that might not have been true in many other cases.
3. Documentation - I worked to document everything. As a new system administrator in the organization this was a great way for me to learn about the implementation I was working on. There were several ways I went about this:
• Testing - I worked with the team to build a comprehensive list of test cases for core system performance. This was broken down into full regression test items and release night core items. Depending on the size of the release we could evaluate the level of testing needed and assign from a set list of test cases.
• Workflows - Automated processes are a huge part of this implementation but there was limited documentation on what these processes did or how they interacted. It was essential for me to have a deep understanding of these. I created a list of all workflows with high level details and then also created flow charts for the more complex items. Learn more in my post on Keeping Track of your Processes.

Long Term Changes

After understanding the system and business more, it was time to modify the state of the releases to make them more manageable for development and release. The timeline we agreed on was monthly releases. We would "require" all changes to be finalized in our Development environment a week prior to the release. This would allow time for testing in our Test environment and time to work on any communication or procedure updates.

This change did not happen overnight. It was a major shift for the business and end users who were accustomed to asking for changes and having them made in just a week or two. The users needed to understand the benefits of this change to get behind it.

These benefits include giving the team more time to focus on higher level changes, lower risk of issues with less frequent changes, more stable system, etc.

This is still a battle that I face as priorities shift quickly and changes are needed right away. We have worked to ensure when this does occur that it is documented so those making the decisions understand the full impact of these types of changes or interruptions.

Goal State

The goal state of our change management transformation consisted of a few things:

• High level CRM/D365 Roadmap set by the team of important changes. This is specifically for large projects or items that may not be known to the business. This could include business priorities such as a new integration that is expected to take a fair amount of work and potentially multiple dedicated releases. This also included system Upgrades. These are not necessarily business-driven but are important to minimize future risk.
• Prioritized backlog of all items waiting for work by the team. Priorities set by the team and users to ensure the best items are handled first. Reviewed consistently so old items can be removed or upcoming items refined.
• Feedback meetings to gather requirements and discuss changes with stakeholders. We were able to implement some cross-functional feedback groups to assist with the backlog management. This gave users the opportunity to share their needs with the team and gave other users the opportunity to discuss. This was very important to ensure changes for one area of the business did not negatively impact another aspect.

Note I said this was a "goal" state. I am definitely not saying we got it all perfect all the time! This is still very much a work in progress each day!

Communication

Communication was an area of our change management strategy that went through many iterations. Originally we thought it was important for the full organization to know about every release but only impacted managers to know about specific changes. Then we wanted all managers (even non-users) to know about all changes as a way to promote the team and show value of changes. Finally we have settled on just informing our feedback (stakeholders) group of all changes. This team is responsible for ensuring these changes look good in Development and are properly communicated to their teams. We work to get this communication out as soon as we can so any issues or potential conflicts are brought to light early.

We have also stopped notifying all end users when we have minor releases. This prevents issues that "started with the changes last week" and allows the team to more effectively troubleshoot problems objectively. 

The main lessons learned from our different variations was to give ownership of training and communication to the leaders of each department. This allowed the CRM/D365 team to step away from those responsibilities to work on making the system more effective.

After the release, we work with the stakeholders to capture successes and time saved. With large releases or changes we want to ensure teams monitor the before and after behavior so we can report these successes to the larger group.

Still Learning

Our system is still far from perfect. There are always other priorities that need to push items out of the way. There are always other distractions or issues that prevent dedicated work time. This will continue to be a work in progress. As the business changes, we need to change our processes to fit with new priorities.

The most important piece to change management is making sure you (as the system owner) fully understand your system and the way it fits into the overall organization. This will allow you to make the hard decisions, set priorities and plan releases so it is effective in your case. It is necessary to have someone with that ownership who can ensure valuable changes are being made to the system.

That's where I have come so far. Still more to go and always more to learn. You can also  learn more on this Release Cycles Panel Webinar from a few weeks ago.

What else has worked in your organization? Any change management goals for 2019?