Table definitions
Seven tables, one ownership chain.
Two tables are native ServiceNow CMDB objects. Four are custom extensions that carry the PAM-specific attributes. One is the junction table that keeps usage rights and rotation rights separately recorded.
Native CMDB tables
Already exist in most ServiceNow instances — this model adds no new fields to either.
cmdb_ci_business_app
native
sys_idguid
namestring
owned_bysys_user
criticalitychoice
cmdb_ci_appl_instance
native
sys_idguid
business_appcmdb_ci_business_app
environmentenum(prod/non-prod)
support_groupsys_user_group
Identity and group tables
Also native, but the model depends on a specific convention: one group per application-instance pairing.
sys_user_group
native
sys_idguid
namestring
business_appcmdb_ci_business_app
appl_instancecmdb_ci_appl_instance
sys_user
native
sys_idguid
namestring
job_code_typeenum(rtb/ctb)
managersys_user
sys_user_grmember
native
sys_idguid
usersys_user
groupsys_user_group
Custom PAM extension tables
Built to carry the affiliation tag and separate the permission grant from the vault's own internal safe object.
u_pam_safe
custom
sys_idguid
safe_namestring
appl_instancecmdb_ci_appl_instance
service_ownersys_user
pam_platform_refstring (vault safe id)
u_pam_account
custom
sys_idguid
account_namestring
safeu_pam_safe
platform_typeenum(win/unix/db/ldap)
reconciliation_accountsys_user (service acct)
u_pam_safe_permission
custom
sys_idguid
safeu_pam_safe
granteesys_user / sys_user_group
permission_levelenum(use_retrieve/reconcile)
Why
u_pam_safe_permission is its own table rather than a field on the safe itself — the safe can have many grantees at different permission levels simultaneously. Modeling this as a junction table is what lets the catalog request workflow assign use_retrieve to a group and reconcile to a single service owner without a schema change every time a new grant type is needed.