diff --git a/docs/AdvancedFeatures.md b/docs/AdvancedFeatures.md
index 81dde8c8..644326cd 100644
--- a/docs/AdvancedFeatures.md
+++ b/docs/AdvancedFeatures.md
@@ -284,14 +284,14 @@ It is possible to automatically create test users (since v2.1.0) for groups give
 
 property | comment | required
 --- | --- | ---
-createForGroupNamesRegEx | A regex (matched against authorizableId of groups) to select the groups, test users should be created for | required
-prefix | The prefix for the authorizable id, for instance if prefix "tu-" is given, a user "tu-myproject-editors" will be created for group "myproject-editors" | required
-name | The name as configured in user's profile, allows for interpolation with EL *) | optional, defaults to "Test User %{group.name}"
-description | The description as configured in user's profile, allows for interpolation with EL *) | optional, not set by default
-email | The email as configured in user's profile, allows for interpolation with EL *). | optional, not set by default
-path | The location where the test users shall be created | required
-password | The password for all test users to be created. Can be encrypted using CryptoSupport. Defaults simply to the authorizable id of the test user. Allows for interpolation with EL *) | optional
-skipForRunmodes | The configuration is placed in a regular config file, hence it is possible to add one to an author configuration (located in e.g. in a folder "config.author" and one to a publish configuration (e.g. folder "config.publish"). To avoid creating special runmodes folders just for this configuration that list all runmodes except production, skipForRunmodes can be a comma-separated list of runmodes, where the users are not created.  Defaults to prod,production | optional
+`createForGroupNamesRegEx` | A regex (matched against authorizableId of groups) to select the groups, test users should be created for | required
+`prefix` | The prefix for the authorizable id, for instance if prefix "tu-" is given, a user "tu-myproject-editors" will be created for group "myproject-editors" | required
+`name` | The name as configured in user's profile, allows for interpolation with EL *) | optional, defaults to "Test User %{group.name}"
+`description` | The description as configured in user's profile, allows for interpolation with EL *) | optional, not set by default
+`email` | The email as configured in user's profile, allows for interpolation with EL *). | optional, not set by default
+`path` | The location where the test users shall be created | required
+`password` | The password for all test users to be created. Can be encrypted using CryptoSupport. Defaults simply to the authorizable id of the test user. Allows for interpolation with EL *) | optional
+`skipForRunmodes` | The configuration is placed in a regular config file, hence it is possible to add one to an author configuration (located in e.g. in a folder "config.author" and one to a publish configuration (e.g. folder "config.publish"). To avoid creating special runmodes folders just for this configuration that list all runmodes except production, skipForRunmodes can be a comma-separated list of runmodes, where the users are not created.  Defaults to prod,production | optional
 
 *) Interpolation of group properties can be used with EL, however as `$` is evaluated at an earlier stage, `%{}` is used here. Available is `%{group.id}`, `%{group.name}`, `%{group.path}` or expressions like `%{split(group.path,'/')[2]}`.
 
@@ -307,6 +307,8 @@ Example:
      skipForRunmodes: prod, preprod
 ```
 
+*As [dynamic groups](https://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#enforcing-dynamic-groups) come with an Oak validator which enforces that no members are manually added to dynamic groups (like IMS managed groups) test user's cannot be created for dynamic groups directly. Otherwise an error like `OakConstraint0077: Attempt to add members to dynamic group '<dynamic group id>'` is emitted. As workaround use a non-dynamic ACTool managed group which is having both the according dynamic group as well as the test user as member*
+
 ## Configure unmanaged aspects
 
 The following table gives an overview of what is managed (in terms of authorizables themselves, group memberships and ACLs) by AC Tool and what is not: