Therefore, the values could not be hard-coded by the plugins and needed to be easily editable by the users. Initially I thought parameters would be the solution to this problem, the users could simply go in to the customisations and change them? Then I thought of a much cleaner way to achieve the same functionality, a configuration entity. The use of a configuration entity solves 3 problems here, firstly the everyday system users should never have to go into the customisations and make changes on a regular basis, even if they are just to process parameters. Also, a lot of the same parameter values were being used in several different processes and plugins and related to that, plugins can't have parameters in the same way as workflow processes.
The idea is that you create an entity with a field for each value required, users can then access this entity in the front-end system and change the values to be used in the processes. The processes access the parameters stored in the configuration record(s) by performing a simple retrieve on the configuration record(s) required and storing the required values in variables at the start of each execution.
This concept could obviously be applied in any Dynamics CRM system that had to make use of regularly changed values in its processes and plugins.
