You can provide any text you'd like in those fields. The string value is available in your plugin class in the constructor.
Rather than simply typing in a string in one of the config fields, where the string value doesn't have an associated name or meaning, I usually create an XML fragment with the data the plugin needs and I parse the XML when the plugin runs. This allows
you to pass in multiple values and have more meaning to the data. You could also pass in comma-delimited data, JSON or other types of strings that you're familiar with parsing.
An alternative to passing in configuration details during plugin registration is to have an entity in CRM that provides configuration settings that your plugin can use. However, you take more of a performance hit on that approach, so if the plugin is called
synchronously then users will experience a slightly longer delay.
If you have multiple CRM environments (e.g., Dev, Test, Production), make sure you add a deployment step to adjust the plugin configuration string if needed based on the target environment. On one project, we included the settings for dev, test and
prod in the config string for each environment and used logic in the plugin to determine which setting to use.
More information is available here:
https://msdn.microsoft.com/en-us/library/Gg328263.aspx?f=255&MSPPError=-2147217396
-Tim
Tim A. Dutcher Altriva Solutions Microsoft Gold Certified Partner Bellevue, WA
