According to this what development and configuration we need to do tell in detail

shivanitana
Tera Contributor

a month ago

According to this what development and configuration we need to do tell in detail

 

BRD for Module admin roles.docx
0 Helpfuls
  • 167 Views
1 REPLY 1

Vikram Reddy
Tera Guru

a month ago

Hello @shivanitana,

 

Requests like this BRD, giving a set of users admin-level control over one module without handing out full system admin, come up constantly on ServiceNow projects, and the platform has native support for it. You don't need scripts or a custom UI to pull it off, it's pure role and ACL configuration.

Application Menu Module (sys_app_module)
  Roles: x_yourscope.module_admin

Access Control (sys_security_acl)
  Table: your_module_table
  Operation: write / create / delete
  Requires role: x_yourscope.module_admin
  Admin overrides: true  (leave checked unless the requirement is to lock out even full admins)

The mechanism is two layers working together: the module's Roles field controls whether the nav item even shows up for that user, and the table's Access Control rules control what they can actually do once they're on the record. Miss the second layer and you've only hidden the module, the underlying data is still wide open to anyone who knows the URL.

In practice, the development and configuration checklist looks like this:

  1. First check whether ServiceNow already ships a delegated admin role for that module, products like Service Catalog (catalog_admin), Knowledge (knowledge_admin), Change (change_admin) and CMDB (cmdb_admin) already come with scoped admin roles out of the box. No point building custom if one exists.
  2. If nothing fits, create a new role on sys_user_role, something like x_yourscope.module_admin, and use the Contains roles field if this role should inherit a lower-tier role automatically.
  3. Add that role to the Roles field on the relevant sys_app_module record(s) so the module only appears for members of that role.
  4. Write ACLs on the tables behind the module for each operation, read, write, create, delete, with Requires role set to your new role.
  5. Only uncheck Admin overrides on the ACL (and the underlying dictionary entry) if the actual requirement is that even the admin role can't touch this data, that's an unusual ask and worth confirming before you build it.
  6. Assign the role via User Administration, and remember roles are cached in the session, so users need to log out and back in before the change takes effect.
  7. Impersonate a test user in that role before rollout to confirm they see exactly the module and nothing else.

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls