diff --git a/documentation/src/main/docbook/devguide/en-US/Envers.xml b/documentation/src/main/docbook/devguide/en-US/Envers.xml
index 293217c8d0..2e5c8b8eff 100644
--- a/documentation/src/main/docbook/devguide/en-US/Envers.xml
+++ b/documentation/src/main/docbook/devguide/en-US/Envers.xml
@@ -218,6 +218,41 @@
+
+ Additional mapping annotations
+
+
+ The name of the audit table can be set on a per-entity basis, using the
+ @AuditTable annotation. It may be tedious to add this
+ annotation to every audited entity, so if possible, it's better to use a prefix/suffix.
+
+
+
+ If you have a mapping with secondary tables, audit tables for them will be generated in
+ the same way (by adding the prefix and suffix). If you wish to overwrite this behaviour,
+ you can use the @SecondaryAuditTable and
+ @SecondaryAuditTables annotations.
+
+
+
+ If you'd like to override auditing behaviour of some fields/properties in an embedded component, you can use
+ the @AuditOverride(s) annotation on the usage site of the component.
+
+
+
+ If you want to audit a relation mapped with @OneToMany+@JoinColumn,
+ please see for a description of the additional
+ @AuditJoinTable annotation that you'll probably want to use.
+
+
+
+ If you want to audit a relation, where the target entity is not audited (that is the case for example with
+ dictionary-like entities, which don't change and don't have to be audited), just annotate it with
+ @Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED). Then, when reading historic
+ versions of your entity, the relation will always point to the "current" related entity.
+
+
+
Choosing an audit strategy