Governance or Compliance Implications of Using Service

[thalessanto]

In a hypothetical ServiceNow implementation, external customer-facing processes (within the CSM scope) were implemented as Service Catalog items (sc_request / sc_req_item) instead of being handled through the standard CSM Case data model.

These catalog items are used to manage interactions with external customers but do not

From a platform governance and compliance perspective:

• Would this be considered a deviation from architectural best practices (

• Or could it represent a potential compliance or audit risk (e.g., data segregation, reporting integrity, control traceability, or licensing considerations)?

The objective is to understand whether this type of implementation should be viewed primarily as a design/governance matter or if it may carry broader

[Uday Damaraju]

Hello @thalessanto - Yes this can be classified as a very high risk architectural deviation- because its breaching the fundamental CSM logic. 
(sc_request) SRM process > centered around sys_user table that contains user that consume processes internal to the Org, on the other hand CSM process is centered around > Account and (respective) Contact that are considered external to your Org.
Because of this deviation we tend to loose the CSM features like Accounts & Subsidiaries, Contracts, Entitlements etc. 
Hence this is a fundamental architectural deviation of very high risk in my opinion, sooner this is corrected is better for platform.
Such deviations will also have negative implications from:
a. Risk and compliance point of view (data separation & segregation, Reporting integrity etc. )
b. License management (during SN license audits, leveraging ITSM tables for CSM cases can be viewed as breach of license usage)

Suggestion: Leverage CSM Case framework, CSM portal to wrap catalog requests within a Case shell, ensuring the proper Account/Contact relationship is maintained.

"If this is helpful, mark it so, helps others" 

BR, UD