Привет!
Ты имеешь в виду роль - как объект БД? Ты помнишь, что их число по умолчанию ограниченно?

Я раньше использовал роли, для ограничения доступа к пунктам меню, но неудобств от этого больше, чем достоинств.
Как у тебя работают пользователи, под каждого своя схема и синонимы? Или паблик синонимы?

Я потом перешел на другой способ разграничения прав.
Есть основная схема А, в которой есть все что мне нужно, в том числе таблица с пользователями и их зашифрованными паролями.
Есть схема Б, для которой в приложении настраивается пароль для входа.
В схеме Б право выполнения одной процедуры из А и синоним.

То есть приложение стартует в Б, выводит экран для ввода логина и пароля, и передает их этой процедуре.
Та проверяет в своей таблице, и если все нормально дает роль и переключает на нужную схему
alter session set current schema

В основной схеме я просто прописываю возможные режимы работы и свои роли, привязка к пользователям, и в приложении проверяю, есть ли право на нужный режим работы. В зависимости от этого скрываю/показываю пункты меню, доступность кнопок и т.п.

В целом такой алгоритм оказался удобней, чем с использованием ролей, и встраиванием их в меню

Так я в приложении не прописываю роли )
Я там озадачиваюсь только правами работы - есть например право работы - загрузка данных из бухгалтерии - сделаю доступной кнопку, нет права - сделаю недоступной.

А т.н. ролям (в моем случае это не роли, как объекты БД) я даю права на режимы и другие роли. И соответственно процедура, которая проверяет наличие у пользователя, через роли, которые привязаны к нему прямо или опосредованно, прав на этот режим работы.

Привязываясь в формсах к настоящим ролям, ты можешь получить в будущем, при росте приложения, проблемы, когда потребуется тонкая настройка по правам.

Ок, давай по порядку
у тебя есть пользователь
у тебя есть таблица справочник режимов работы
У тебя есть таблица справочник "роли"
У тебя есть таблица связи многие ко многим "режим работы - роль"
У тебя есть таблица связи многие ко многим "роль - роль"
У тебя есть таблица связи многие ко многим "пользователь - роль"

Теперь пользователь вошел, ты получаешь его роли, ты получаешь через них прямо и опосредованно (роль->роль), данные ему права на режимы работы. ( при желании сохраняешь это, в переменной пакета или в контексте, что бы потом не тратить время).

Проверяешь, есть ли у него право на режим работы. И тут тебе не особо важно, через какую роль он его получил.
У меня примерно 60 пользователей, работает все без проблем.
Как-то так )