diff --git a/postgresql/procedures/README.md b/postgresql/procedures/README.md
index 8a9706a..063edba 100644
--- a/postgresql/procedures/README.md
+++ b/postgresql/procedures/README.md
@@ -17,7 +17,7 @@ This is the declarative partitioning implementation for Zabbix `history*`, `tren
   - [Scheduling Maintenance](#scheduling-maintenance)
 - [Monitoring & Permissions](#monitoring--permissions)
   - [Versioning](#versioning)
-  - [Least Privilege Access (`zbx_monitor`)](#least-privilege-access-zbx_monitor)
+  - [Least Privilege Access (`zbxpart_monitor`)](#least-privilege-access-zbxpart_monitor)
 - [Implementation Details](#implementation-details)
   - [`auditlog` Table](#auditlog-table)
   - [Converting Existing Tables](#converting-existing-tables)
@@ -220,23 +220,23 @@ To check the installed version of the partitioning solution:
 SELECT * FROM partitions.version ORDER BY installed_at DESC LIMIT 1;
 ```
 
-### Least Privilege Access (`zbxpart_admin`)
-For monitoring purposes, it is recommended to create a dedicated user with read-only access to the monitoring view.
+### Least Privilege Access (`zbxpart_monitor`)
+For monitoring purposes, it is highly recommended to create a dedicated user with read-only access to the monitoring view instead of using the `zbxpart_admin` owner account.
 
 ```sql
-CREATE USER zbxpart_admin WITH PASSWORD 'secure_password';
-GRANT USAGE ON SCHEMA partitions TO zbxpart_admin;
-GRANT SELECT ON partitions.monitoring TO zbxpart_admin;
+CREATE USER zbxpart_monitor WITH PASSWORD 'secure_password';
+GRANT USAGE ON SCHEMA partitions TO zbxpart_monitor;
+GRANT SELECT ON partitions.monitoring TO zbxpart_monitor;
 ```
 
-> [!NOTE]
-> If you ever apply updates to `03_monitoring_view.sql`, you should run the script as the `zbxpart_admin` database user (the original creator of the view). The script drops and recreates the view, so running it as `zbxpart_admin` ensures the view retains its ownership and preserves existing `GRANT` permissions for read-only users.
+> [!WARNING]
+> Because `03_monitoring_view.sql` uses a `DROP VIEW` command to apply updates, re-running the script will destroy all previously assigned `GRANT` permissions. If you ever update the view script, you **must** manually re-run the `GRANT SELECT` command above to restore access for the `zbxpart_monitor` user!
 
 ## Implementation Details
 
 ### `auditlog` Table
 The standard Zabbix `auditlog` table has a primary key on `(auditid)`. Partitioning by `clock` requires the partition key to be part of the primary key. 
-To prevent placing a heavy, blocking lock on a highly active `auditlog` table to alter its primary key, the enablement script (`02_enable_partitioning.sql`) detects it and handles it exactly like the history tables: it automatically renames the live, existing table to `auditlog_old`, and instantly creates a brand new, empty partitioned `auditlog` table pre-configured with the required `(auditid, clock)` composite primary key.
+To prevent placing a heavy, blocking lock on an `auditlog` table to alter its primary key, the enablement script (`02_enable_partitioning.sql`) detects it and handles it exactly like the history tables: it automatically renames the live, existing table to `auditlog_old`, and instantly creates a brand new, empty partitioned `auditlog` table pre-configured with the required `(auditid, clock)` composite primary key.
 
 ### Converting Existing Tables
 The enablement script guarantees practically zero downtime by automatically renaming the existing tables to `table_name_old` and creating new partitioned tables matching the exact schema.