diff --git a/docbook/auth-server-docs/reference/en/en-US/modules/MigrationFromOlderVersions.xml b/docbook/auth-server-docs/reference/en/en-US/modules/MigrationFromOlderVersions.xml
index dc0b6a15fc..5ab29ecbc6 100755
--- a/docbook/auth-server-docs/reference/en/en-US/modules/MigrationFromOlderVersions.xml
+++ b/docbook/auth-server-docs/reference/en/en-US/modules/MigrationFromOlderVersions.xml
@@ -120,6 +120,16 @@
                     the various HTTP error codes.  See documentation for more details if you want to catch and handle adapter error conditions.
                 </para>
             </simplesect>
+            <simplesect>
+                <title>IdentityProviderMapper changes</title>
+                <para>
+                    There is no change in the interface itself or method signatures. However there is some change in behaviour. We added <literal>First Broker Login</literal> flow
+                    in this release and the method <literal>IdentityProviderMapper.importNewUser</literal> is now called after <literal>First Broker Login</literal> flow is finished.
+                    So if you want to have any attribute available in <literal>Review Profile</literal> page, you would need to use
+                    the method <literal>preprocessFederatedIdentity</literal> instead of <literal>importNewUser</literal> . You can set any attribute by
+                    invoke <literal>BrokeredIdentityContext.setUserAttribute</literal> and that will be available on <literal>Review profile</literal> page.
+                </para>
+            </simplesect>
         </section>
         <section>
             <title>Migrating to 1.6.0.Final</title>
diff --git a/docbook/auth-server-docs/reference/en/en-US/modules/javascript-adapter.xml b/docbook/auth-server-docs/reference/en/en-US/modules/javascript-adapter.xml
index e0d78f3e88..ab7896d7c4 100755
--- a/docbook/auth-server-docs/reference/en/en-US/modules/javascript-adapter.xml
+++ b/docbook/auth-server-docs/reference/en/en-US/modules/javascript-adapter.xml
@@ -164,9 +164,12 @@ keycloak.init({ flow: 'implicit' })
             Keycloak also have support for <ulink url="http://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth">OpenID Connect Hybrid flow</ulink>. This requires
             that client in admin console has both flags <literal>Standard Flow Enabled</literal> and <literal>Implicit Flow Enabled</literal> enabled in admin console.
             The Keycloak will send both the code and tokens to your application. Access token can be immediately used and in the meantime, code can be exchanged for access token and refresh token.
-            Hybrid flow is good for performance similarly like implicit flow, because access token is available. But similarly like implicit flow, the token is sent in URL fragment, so security may not be so good.
-            In addition to implicit flow, you have also refresh token available in your application. For hybrid flow, you need to pass the parameter
-            <literal>flow</literal> with value <literal>hybrid</literal> to <literal>init</literal> method.
+            Hybrid flow is good for performance similarly like implicit flow, because access token is available immediatelly to your application. But similarly like implicit flow, the token is
+            sent in URL fragment, so security may not be so good.
+            One advantage over implicit flow is, that you have also refresh token available in your application (after code-to-token request is finished in background).
+        </para>
+        <para>
+            For hybrid flow, you need to pass the parameter <literal>flow</literal> with value <literal>hybrid</literal> to <literal>init</literal> method.
         </para>
     </section>