Why should you care?

Enterprises map “PaymentsService”, “SupportRO”, and “DBA” to roles once, then onboard humans/services without inventing privileges each time.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

use admin
db.createRole({
  role: "orderReader",
  privileges: [{
    resource: { db: "NoSQLVerse", collection: "orders" },
    actions: ["find"]
  }],
  roles: []
})
db.createUser({
  user: "supportBot",
  pwd: "strong-pass",
  roles: [ { role: "orderReader", db: "admin" } ]
})

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• orderReader may only find on orders.
• supportBot inherits that role.
• It cannot read users or write orders.
• Custom roles encode company policy in the database.

Practice next

1. Create a custom role limited to one collection.
2. Assign it to a test user.
3. Attempt forbidden actions and confirm failure.
4. Add update action for a support “refund note” field only via careful app design.
5. List roles with db.getRoles({ showPrivileges: true }).

Remember

RBAC assigns roles, not raw privileges, to users. Custom roles scope collections and actions. Align roles with services and job functions.

Bank-grade separation of duties

Writers, readers, and admins map to different Mongo roles audited quarterly.

Outcome: Compliance can prove who could touch which collections.