Not sure what CI to use

[Mike LHCG1]

I am creating  a catalog item for Release of Records and/or Information, and am not sure what CI  the team completing the SCTASK should use and am wondering if someone has had to come up with a CI for something similar, and if so, what you used.

[Maik Skoddow]

Hi @Mike LHCG1 

why do you think you have to use a CI? Please provide more context information as it's pretty unclear where you are and what you want to achieve.

Maik

[Mike LHCG1]

Hi @Maik Skoddow ,

In order to close an SCTASK we need to specify a CI because it's a required field. I believe the out-of-box default is that it's not required, but a decision was made before my time that it be required. We don't have a currently defined CI for a records request/request for information, and I thought maybe someone here may have encountered a similar situation, and if so, might be willing to share what they use as the CI.

[Maik Skoddow]

Hi @Mike LHCG1

requiring a CI on every SCTASK without a clear, valid CI type for records requests can introduce unnecessary complexity and long‑term technical debt. Below is a concise overview of why fighting past decisions with “patchwork” workarounds is risky, followed by four constructive options you can explore to address the root cause and keep your CMDB healthy.

Why a Workaround Increases Technical Debt

1. Data Integrity and Reporting Issues
   Forcing a bogus or generic CI onto SCTASKs pollutes your CMDB with meaningless entries, undermining confidence in data quality. Over time, this leads to mistrust in reports and dashboards built on CMDB data.

2. Maintenance and Upgrades Become Harder
   Custom scripts or client‑side logic to “fake” a CI requirement typically live outside the standard upgrade path. Every ServiceNow upgrade or patch then risks breaking these ad‑hoc solutions, raising your support burden.

3. Obscured Business Processes
   Workarounds hide the true business intent—why should a records request be tied to a CI at all? This ambiguity makes onboarding new team members harder and complicates process documentation.

Four Constructive Paths Forward

1. Remove the Mandatory CI Requirement

• How: Update the dictionary entry on the cmdb_ci reference field of the sc_task table. Simply toggle off “Mandatory,” or use a UI policy to conditionally require CI only when truly needed.

• Benefit: Keeps the data model clean and aligns the form with real business needs, avoiding fake CIs altogether.

2. Create a Legitimate “Record Request” CI Class

• How: Extend an existing OOB CI class (e.g., cmdb_ci_service) to create cmdb_ci_record_request with minimal custom attributes. Define identity rules so that only your team can instantiate it.

• Benefit: Provides a valid, discoverable CI that represents your process, preserves CMDB integrity, and surfaces in dependency maps and service contexts correctly.

3. Leverage a Custom Table Instead of CMDB_CI

• How: If records request isn’t truly a configuration item, model it in a separate custom table (e.g., u_record_request) and remove the CI reference from SCTASKs. Use related lists or record producers to tie into your catalog flows.

• Benefit: Keeps CMDB focused on infrastructure and application components, while your records‑request processes live in the proper domain.

4. Introduce Conditional Logic in Catalog Workflow

• How: Enhance the Catalog Workflow or Flow Designer to require CI only for those tasks that genuinely need it (for example, when the request pertains to an existing system). For other tasks, skip the CI step entirely.

• Benefit: Balances strictness with flexibility, enforcing data requirements where they add value and avoiding them where they don’t.

Next Steps and Recommendations

1. Discuss with Configuration Management: Bring these options to your CMDB owner or CAB to decide which best fits your organization’s governance.

2. Prototype in Lower Environments: Build quick proof‑of‑concepts for each option in DEV or TEST. Evaluate impacts on reporting, forms, and upgrade safety.

3. Document and Communicate: Whichever path you choose, update your process docs and inform all stakeholders to ensure a smooth transition.

By tackling the underlying decision—rather than layering on more “hacks”—you’ll reduce future support costs, keep your CMDB trustworthy, and enable clearer, more maintainable processes. Let me know if you’d like detailed steps or examples for any of these approaches!