Simplifying System Settings Management

Managing system settings in complex projects can be a daunting task, especially when the requirements mean for multiple changes to default configurations.  As with any complicated process, we can streamline the approach to handling system settings, while also focusing on the organization entity. In this blog, Kerv DevSecOps Engineer, Dan Styles, will take you through a method that ensures ease of consistency across different environments and allows for a competent solution to an intricate process.  

The journey began with a project where constant changes to defaults were needed, leading to frustration. After some research and a helpful article by Craig Seymour on the cloudThing website, a better way to manage system settings emerged. By leveraging PowerShell and Dynamics WebAPI, this process can be easily incorporated into your workflow to eliminate the need for manual configurations. 

In the development environment, the first step involves manually adjusting the system settings as required. Once these changes are in place, a PowerShell script comes into play. The script utilizes the Dynamics WebAPI to retrieve the organization entity and fetches all relevant properties. However, not all properties can or should be replicated to other environments. To ensure that only the necessary settings are included, properties like “@odata.etag,” “createdon,” “organizationid,” “createdby,” and more are excluded from the list. By filtering and selecting only the properties with non-null or non-empty values, the script creates a JSON file that will serve as the blueprint for the settings to be replicated. 

While JSON is a powerful format, certain limitations arise when handling datetime objects and OptionSetValues (picklist fields). To overcome this hurdle, a plaintext list of datetime fields and picklist fields is referenced. These references are well-documented on the Microsoft website and provide a reliable solution for these specific data types. 

During deployment, the PowerShell script constructs a hashtable to store the settings from the JSON file. Looping through the JSON, the script adds field names and values to the hashtable. When encountering datetime fields, the script converts the value to a datetime object. Similarly, when encountering picklist fields, the appropriate conversion to a New-CrmOptionSetValue is performed. This ensures that all settings are appropriately mapped and retained during the deployment process. 

Once the hashtable contains all the necessary orgSettings, the final step involves iterating through the hashtable and applying the settings to the organization entity. This is achieved through the use of Set-CrmRecord, which enables seamless updates to the specified entity. 

In essence, this streamlined approach simplifies the management of system settings, ensuring that developers and administrators no longer need to manually configure each environment separately. With the use of PowerShell, Dynamics WebAPI, and the ingenious hashtable technique, the process becomes efficient, consistent, and easily scalable for large-scale projects. 

To sum all of this up, the systematic handling of system settings through the organization entity brings significant benefits to any development or system administration project. By eliminating the need for repetitive manual configurations, it saves valuable time and minimizes the chances of human error. Developers can now focus on more critical aspects of their projects while maintaining a consistent and reliable configuration across various environments. For seamless integration and execution of the outlined approach, the Microsoft.Xrm.Data.PowerShell module by Sean McNellis is a valuable asset. Whether you are a seasoned developer or just starting, adopting this method can revolutionize your system settings management and enhance overall productivity.