Centrally capturing service accounts - Custom app/table or CMDB Class?

[PattenM1]

Hi Experts,

I've been tasked with building a register of service accounts that are in use across an environment.

This will encapsulate accounts and credentials such as API, SGC, (traditional) Service Accounts, and Test Accounts that are shared between teams (for non SN accounts, so don't suggest impersonation).

I was initially building an app for this, however given these would align with business services and application services, it makes sense to add them to the CMDB as a new CI class, and build relationships.

Keen to know people's thoughts over whether the better way to do this would be via a custom table or a new CI Class, with sub-classes? The related accounts may be in systems and environments where using integration hub or APIs to monitor isn't possible.

Acct Register table - containing things like 'environment', 'related primary business function', renewal/expiry date, etc

... is extended by 2 sub-tables;

Service accounts - containing things like credential type, credential location, last reviewed, etc.

Test accounts - containing things like 'current assigned to', 'equiv role', etc.

[AJ-TechTrek]

Hi @PattenM1 ,

1 – As per my understanding lets Clarifying the Goal
You want:
* A central register of service accounts (API, SGC, traditional service, test accounts)
* Attributes like environment, owning function, expiry date, last review date, etc.
* Relationships to Business Services / Application Services
* To model them in CMDB if possible
* These accounts may be not discoverable or not monitorable by APIs

2 – Should This Live in CMDB?

Yes, if:
* Accounts are considered Configuration Items because they’re critical to delivering services.
* You want to establish dependency mapping between services and accounts.
* You want to leverage CMDB relationships for impact analysis (e.g., if an account is compromised or expires).

No, if:
* You only need an inventory for compliance or audit with no service mapping requirement (then a custom standalone table could suffice).
Since you’ve mentioned alignment with Business Services and Application Services, CMDB is the right place — but with careful design.

3 – Recommended Design
Option A – New CI Class (Preferred)
* Extend from cmdb_ci → Create cmdb_ci_account (custom class)
* Create two sub-classes:
* cmdb_ci_service_account
* cmdb_ci_test_account
* This ensures:
* Inclusion in CMDB queries, reports, and CMDB Health
* Reuse of CI relationships (Depends on, Used by, Runs on)
* Service mapping capability

Example Hierarchy:
cmdb_ci
└── cmdb_ci_account
├── cmdb_ci_service_account
└── cmdb_ci_test_account

Option B – Custom App Table (If not treated as CIs)
* Create u_account_register as the master table
* Create u_service_account and u_test_account extending it
* Maintain relationships manually to Business/Application Services via cmdb_rel_ci or a custom relationship table
Trade-off: This approach avoids polluting the CMDB but loses native CI capabilities.

4 – Suggested Attributes
Common fields (in cmdb_ci_account or base table):
* Environment (Dev / Test / Prod)
* Related Primary Business Function
* Expiry / Renewal Date
* Owner Group
* Associated Business Service / Application Service

Service Account–specific:
* Credential Type (API Key, Username/Password, Certificate)
* Credential Location (Vault, Encrypted Store)
* Last Reviewed Date
* Rotation Frequency

Test Account–specific:
* Current Assigned To
* Equivalent Role
* Access Scope

5 – Relationship Modeling
* Service Account CI → Used by → Application Service
* Test Account CI → Used by → Application Service
* Both can also link to:
* Specific environments (via relationship to Environment CIs)
* Owner groups (via standard Owned by field)
* If you use Impact Analysis, these relationships allow:
* Expiring account alerts → list impacted services
* Breach or compromise → list at-risk services

6 – CMDB Governance Considerations
* Since many accounts will be manually entered, use:
* CMDB Data Certification to enforce periodic review
* CMDB Health Dashboard to track completeness and correctness
* Use Read ACLs to limit visibility — service accounts often hold sensitive info.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[AJ-TechTrek]

Hi @PattenM1 ,

Here is one another approach which you can follow, might be helpful for you

1. Decision Framework — CI Class vs Custom Table
When deciding between a CI class and a standalone custom table, the key criteria are:

Factor	CI Class (extended from cmdb_ci)	Custom Table (not in CMDB)
Visibility in CMDB	Appears in CMDB hierarchy, discoverable in CMDB Workspace & CMDB APIs	Standalone, not part of CMDB
Relationship Mapping	Native cmdb_rel_ci usage, impact analysis, service mapping	Requires custom relationship logic
Alignment with CMDB Governance	Fits with ServiceNow’s CSDM model for services	Independent from CMDB governance
Use Cases	When the item is considered part of your infrastructure/application service landscape	When it’s purely operational/administrative data

Service accounts are part of the IT ecosystem, relate to services, and may have lifecycle & dependency mapping → This leans toward making them a CI class.

2. Recommended Approach
Create a new CI Class under the most appropriate CSDM domain — probably:
* Extend from cmdb_ci_account (if available in your instance), or
* Create a new subclass under cmdb_ci like cmdb_ci_service_account
Then:
* Sub-classes:
* u_cmdb_ci_service_account → For API/SGC/traditional service accounts
* u_cmdb_ci_test_account → For shared/non-prod/test accounts

Why CI Class makes sense here
* You can link accounts to business/application services via CMDB relationships
* Use impact analysis to understand effect if credentials expire or are revoked
* Easier integration into Service Mapping (e.g., show which APIs/services depend on which accounts)
* Native CMDB lifecycle management (install, in use, retired)
* Aligns with CSDM’s “Application Service / Technical Service” data modeling

3. Table Design
Parent Class:
* u_acct_register (extend cmdb_ci)
* Environment (choice: Prod/Dev/Test/etc.)
* Primary Business Function (ref to Business Service or cmdb_ci_service)
* Renewal/Expiry Date
* Status (Active/Expired/Review Due)
Subclass: u_service_account
* Credential Type (API Key, Username/Password, Certificate, etc.)
* Credential Location (Vault, File, etc.)
* Last Reviewed (date)
* Owner (ref to sys_user/sys_user_group)
Subclass: u_test_account
* Current Assigned To (sys_user)
* Equivalent Role
* Usage Restrictions

4. Population & Maintenance
Since you mentioned no API/integration monitoring for some systems:
* Use manual data entry forms in your scoped app or via CMDB Workspace
* Consider Flow Designer reminders for review/expiry
* Allow relationship mapping to:
* Application Services (cmdb_ci_service)
* Infrastructure CIs (Servers, APIs, etc.)

5. Reporting & Visibility
* Use CMDB Workspace dashboards to show:
* Upcoming expiries
* Accounts by service/application
* Review compliance %
* Create relationships in cmdb_rel_ci like:
* Service Account → Depends on → Application Service
* Service Account → Runs on → Server

 My Recommendation:
Go with a CI class approach with sub-classes for Service Accounts & Test Accounts.
It aligns with CSDM, supports relationships, reporting, and impact analysis — which a standalone table won’t give you without custom effort.