diff --git a/product_docs/docs/bdr/4.0/functions.mdx b/product_docs/docs/bdr/4.0/functions.mdx
index 0870417e21f..4d4c3ce899c 100644
--- a/product_docs/docs/bdr/4.0/functions.mdx
+++ b/product_docs/docs/bdr/4.0/functions.mdx
@@ -47,7 +47,7 @@ connected to.  This allows an application to figure out what node it
 is connected to even behind a transparent proxy.
 
 It is also used in combination with CAMO, see the
-[CAMO.md#connection-pools-and-proxies]\(Connection pools and proxies)
+[Connection pools and proxies](CAMO.md#connection-pools-and-proxies)
 section.
 
 ### bdr.last_committed_lsn
diff --git a/product_docs/docs/bdr/4.0/nodes.mdx b/product_docs/docs/bdr/4.0/nodes.mdx
index d36b2146514..9f1d60832a1 100644
--- a/product_docs/docs/bdr/4.0/nodes.mdx
+++ b/product_docs/docs/bdr/4.0/nodes.mdx
@@ -1140,13 +1140,17 @@ the node which is being removed. However, just to make it clear, once the
 node is PARTED it can not *part* other nodes in the cluster.
 
 !!! Note
+    If you are *parting* the local node you must set `wait_for_completion`
+    to false, otherwise it will error.
     you are *parting* the local node you must set `wait_for_completion`
     false, otherwise it will error.
 
 !!! Warning
+    This action is permanent. If you wish to temporarily halt replication
+    to a node, see `bdr.alter_subscription_disable()`.
     s action is permanent. If you wish to temporarily halt replication
     a node, see `bdr.alter_subscription_disable()`.
-
+    
 #### Synopsis
 
 ```sql
diff --git a/product_docs/docs/bdr/4.0/striggers.mdx b/product_docs/docs/bdr/4.0/striggers.mdx
index 56aeb0b1c8f..1df60531a0e 100644
--- a/product_docs/docs/bdr/4.0/striggers.mdx
+++ b/product_docs/docs/bdr/4.0/striggers.mdx
@@ -171,11 +171,11 @@ otherwise data divergence will occur. Technical Support recommends that all conf
 triggers are formally tested using the isolationtester tool supplied with
 BDR.
 
-!!!Warning
--   Multiple conflict triggers can be specified on a single table, but
+!!! Warning
+    - Multiple conflict triggers can be specified on a single table, but
     they should match distinct event, i.e. each conflict should only
     match a single conflict trigger.  
-    Multiple triggers matching the same event on the same table are
+    - Multiple triggers matching the same event on the same table are
     not recommended; they might result in inconsistent behaviour, and
     will be forbidden in a future release.