diff --git a/README.rst b/README.rst
index 47f3e6d..c7cf95c 100644
--- a/README.rst
+++ b/README.rst
@@ -145,19 +145,28 @@
 
 To enable keystone notification listener, set the `ks_notification_enable`
 to true.
+
 `ks_notifications_allow_requeue` enables requeue feature in case of
 notification processing error. Enable this only when underlying transport
 supports this feature.
 
+`ks_notifications_pool_name` allows to use keystone listener together with
+other applications listening on the same notifications topic without
+interference between services. Set it to any distinctive value to enable
+listener pooling. It is enabled by default with pool name 'barbican'.
+Disable it (by setting to empty string) only if underlying messaging transport
+does supports this feature or Barbican is the sole service listening for
+notifications on 'notifications' topic.
 
 .. code-block:: yaml
 
     barbican:
       server:
         enabled: true
-        version: ocata
+        version: pike
         ks_notifications_enable: true
         ks_notifications_allow_requeue: true
+        ks_notifications_pool_name: barbican
 
 
 MySQL server has gone away
diff --git a/barbican/files/pike/barbican.conf.Debian b/barbican/files/pike/barbican.conf.Debian
index c132ee8..99c9a04 100644
--- a/barbican/files/pike/barbican.conf.Debian
+++ b/barbican/files/pike/barbican.conf.Debian
@@ -294,8 +294,21 @@
 # of the servers in a round-robin fashion. That's why Barbican service should
 # have its own dedicated notification queue so that it receives all of Keystone
 # notifications.
+# Alternatively if the chosen oslo.messaging backend
+# supports listener pooling (for example rabbitmq), setting a non-
+# default 'pool_name' option should be preferred. (string value)
 topic = 'notifications'
 
+# Pool name for notifications listener. Setting this to a distinctive
+# value will allow barbican notifications listener to receive its own
+# copy of all messages from the topic without without interfering with
+# other services listening on the same topic. This feature is
+# supported only by some oslo.messaging backends (in particilar by
+# rabbitmq) and for those it is preferrable to use it instead of
+# separate notification topic for barbican. (string value)
+#pool_name = <None>
+pool_name = {{ server.get('ks_notifications_pool_name', 'barbican') }}
+
 # True enables requeue feature in case of notification processing error.
 # Enable this only when underlying transport supports this feature.
 allow_requeue = {{ server.get('ks_notifications_allow_requeue', 'False') }}
diff --git a/barbican/files/queens/barbican.conf.Debian b/barbican/files/queens/barbican.conf.Debian
index 3958f8e..af8b05c 100644
--- a/barbican/files/queens/barbican.conf.Debian
+++ b/barbican/files/queens/barbican.conf.Debian
@@ -245,8 +245,21 @@
 # fashion. That's why Barbican service should have its own dedicated
 # notification queue so that it receives all of Keystone
 # notifications. (string value)
+# Alternatively if the chosen oslo.messaging backend
+# supports listener pooling (for example rabbitmq), setting a non-
+# default 'pool_name' option should be preferred. (string value)
 #topic = notifications
 
+# Pool name for notifications listener. Setting this to a distinctive
+# value will allow barbican notifications listener to receive its own
+# copy of all messages from the topic without without interfering with
+# other services listening on the same topic. This feature is
+# supported only by some oslo.messaging backends (in particilar by
+# rabbitmq) and for those it is preferrable to use it instead of
+# separate notification topic for barbican. (string value)
+#pool_name = <None>
+pool_name = {{ server.get('ks_notifications_pool_name', 'barbican') }}
+
 # True enables requeue feature in case of notification processing
 # error. Enable this only when underlying transport supports this
 # feature. (boolean value)
diff --git a/barbican/files/rocky/barbican.conf.Debian b/barbican/files/rocky/barbican.conf.Debian
index 683ab00..b970c8b 100644
--- a/barbican/files/rocky/barbican.conf.Debian
+++ b/barbican/files/rocky/barbican.conf.Debian
@@ -238,9 +238,22 @@
 # messages will be dispatched to one of the servers in a round-robin
 # fashion. That's why Barbican service should have its own dedicated
 # notification queue so that it receives all of Keystone
-# notifications. (string value)
+# notifications.
+# Alternatively if the chosen oslo.messaging backend
+# supports listener pooling (for example rabbitmq), setting a non-
+# default 'pool_name' option should be preferred. (string value)
 #topic = notifications
 
+# Pool name for notifications listener. Setting this to a distinctive
+# value will allow barbican notifications listener to receive its own
+# copy of all messages from the topic without without interfering with
+# other services listening on the same topic. This feature is
+# supported only by some oslo.messaging backends (in particilar by
+# rabbitmq) and for those it is preferrable to use it instead of
+# separate notification topic for barbican. (string value)
+#pool_name = <None>
+pool_name = {{ server.get('ks_notifications_pool_name', 'barbican') }}
+
 # True enables requeue feature in case of notification processing
 # error. Enable this only when underlying transport supports this
 # feature. (boolean value)