Module Configuration Documentation

prebid-server/developers/add-a-module-java.md

@@ -93,6 +93,18 @@ The structure of your module source code inside the modules directory must have
 +- README.md <- documentation
 ```
 
+## Module Configuration
+There are several places to configure a module:
+
+- **Host/Bean config** is stored in one of the YAML files, primarily used for enabling the module altogether (`hooks.<MODULE_CODE>.enabled`). It should only contain static config which applies to the entire prebid server, potentially independently from account configuration, or no config at all, apart from enabled flag.
+- **Default account config** is stored in one of the YAML files, only used when there is an actual account present. It is used to define defaults for all accounts globally.
+- **Account/Runtime config** is stored in the database, or YAML file, or anywhere else depending on the backend used. It is used to define individual account configuration.
+
+Important Notes:
+
+- Host config will be provided to module once on application start.
+- Account config will be provided to module on each request.
+
 ## Module Code
 
 The quick start is to take a look in two places:

prebid-server/pbs-modules/index.md

@@ -132,9 +132,10 @@ hooks:
   }
 ```
 
-{: .alert.alert-info :
-Execution plans can be placed in account configuration, but depending on how modules are enabled in your environment, it can be inconvenient to provide instructions to place the highly technical execution plan into the account config. Some organizations have
-chosen to keep all execution plans in host-level config, then enabling the `require-config-to-invoke` option as described in the next section.
+{: .alert.alert-info :}
+Execution plans can be placed in account configuration, but depending on how modules are enabled in your environment, it can be inconvenient to provide instructions to place the highly technical execution plan into the account config.
+Besides if there is more than one execution plan (e.g. on the host level and on the account level) all of them will be triggered and the module mentioned in the plans might be processed several times because of that. 
+Some organizations have chosen to keep all execution plans in host-level config, **and we encourage everyone to do the same**, then enabling the `require-config-to-invoke` option as described in the next section.
 
 ### 3. Supply the module with configuration