If you hang around developers long enough you will hear them use the term “refactoring”. On one project, the developer even had a “Refactor Friday” where this is all they did at the end of the week. So what is refactoring and why should us configuration folks care?

Refactoring is taking existing code and reworking it to simplify it or make it more manageable without affecting what it actually does. In Agile, it is similar to the idea of “technical debt”. As iterative changes accumulate, often a pattern emerges which may not have been apparent at the start. Such a pattern leads to a better approach and rework (tech debt) is needed to align to this approach.

The same can happen to us with configuration. We have lots of tools at our disposal to change the behavior of Dynamics both on the client side and server side. Tools such as Workflows, Business Rules, and Automatic Record Creation allow us to make things happen which, previously, were the domain of the developer. Moreover, often we can produce identical behavior for the user with different tools.

Just as accumulated pieces of code can tread on its own toes, so too can configured behavior. For example, multiple Workflows could trigger off of the same event and overwrite each other’s values or a Workflow and Automatic Record Creation could both send an acknowledgement email on the creation of a Case. This is why it is important that those who configure adopt a developer’s mindset when approaching Dynamics and learn from the developers’ good habits.

While a weekly “Refactor Friday” may be too frequent, set yourself a periodic maintenance task to regularly review your production solution and see if it can be improved through refactoring. Not only will it make your life easier, it will give you an opportunity to reflect on the work you have done and give inspiration for how else you can add value to the users of the system.