CSM to ITSM model: Can we use RITM as primary instead of always creating SCTASK?

[DKrish]

Hello Community,

We currently use CSM for external client facing support & services and are implementing ITSM to support those client requests, with an automated flow from Case to Request (CSM to ITSM).

There is a design debate internally:

Implementation team is recommending that all fulfillment must happen through Catalog Tasks (SCTASK) for every request, stating it aligns better with ServiceNow standard and avoids customization.

Delivery team is proposing a different approach:

• Use RITM as the primary fulfillment and ownership record
• Work directly on RITM for simple or single team requests
• Create SCTASK only for complex or multi team work

My understanding is that ServiceNow allows fulfillment to be defined via workflows and tasks are created as part of that design, not necessarily required for every request. 

Questions:

1. Is using RITM as the primary working record considered against best practice? (in out business case of supporting external clients)
2. Does forcing SCTASK for every request really reduce customization, or just add overhead?
3. For CSM to ITSM models, what approach have others successfully used?

Thanks in advance!

[vkachineni]

For consistency,  stick with SCTask as agents will be working in SOW. They will not need to guess whether to work at RITM level or SCTask level. 

[DKrish]

Thanks for the response,

We are not trying to remove SCTASK, just use it based on complexity instead of for every request.

In our model, forcing SCTASK everywhere creates a few challenges:

• SLAs sit at RITM, tasks can split accountability
• We need one clear owner for the full client request
• With parallel open tasks, handling waiting on client gets messy
• Teams still have to check RITM or Case for customer context

So our approach is:

• RITM = lifecycle, SLA, ownership
• SCTASK = only for complex or multi team work

How do you usually handle SLA ownership when there are multiple tasks? If a request is waiting on the client, where do you track that cleanly across tasks? Do your teams actually get all customer context from the task, or still go back to RITM or Case?

Looking forward your thoughts and response,

[Tanushree Maiti]

HI @DKrish 

ServiceNow’s out-of-the-box (OOB) request fulfillment framework is designed around fulfillment occurring at the Catalog Task (SCTASK) level rather than directly on the Requested Item (RITM). Bypassing SCTASKs and fulfilling work directly from the RITM circumvents the standard ServiceNow Request Management lifecycle and introduces significant complexity.

While direct fulfillment at the RITM level is technically possible through extensive customization, it is generally not recommended for the following reasons:

 

• Deviates from the OOB Design Model
  ServiceNow structures requests similarly to an online shopping process: the Request (REQ) represents the overall order, RITMs represent individual requested items, and SCTASKs represent the fulfillment activities. Eliminating SCTASKs disrupts core platform capabilities, including approval handling, variable processing, and upgrade-safe functionality.
• Reduces Operational Granularity
  A single RITM often requires multiple fulfillment activities such as procurement, asset preparation, security provisioning, or delivery. Catalog Tasks allow these activities to be distributed across different teams or assignment groups, providing better control and accountability.
• Creates Communication Challenges
  End users typically require high-level status updates, while fulfillment teams need the ability to maintain internal work notes. Managing all fulfillment activities directly on the RITM often requires custom solutions to separate internal communications from customer-facing updates.
• Introduces State Management and SLA Risks
  RITM states are governed by numerous OOB business rules and lifecycle processes. Customizing fulfillment directly on the RITM can lead to unexpected state transitions, inaccurate SLA calculations, stuck records, and premature or incorrect closures.
• Impacts Reporting and Governance
  ServiceNow reporting, SLA tracking, and operational metrics are designed to aggregate fulfillment data from task records. Departing from the standard SCTASK-based model can negatively affect reporting accuracy and overall governance.
• Increases Upgrade and Maintenance Risk
  Significant customization of the request fulfillment framework can result in conflicts with future platform upgrades, broken business rules, and increased long-term maintenance effort.

Recommended Approach

The recommended best practice is to keep the actual fulfillment activities at the Catalog Task (SCTASK) level and use those tasks to manage the detailed execution of work. If RITM status updates are required based on task progress, this can be achieved through standard mechanisms such as Business Rules or Flow Designer, preserving alignment with ServiceNow's OOB architecture while still meeting business requirements.

[DKrish]

Thanks for response and I agree with aligning to the standard model.

We are not trying to remove SCTASK, but use it based on complexity rather than mandating it for every request.

In our third party client support model, a few challenges with forcing SCTASK everywhere:

• SLA ownership: SLAs sit at RITM level, adding SCTASK can fragment tracking, especially for multiple tasks
• Ownership clarity: we need one clear owner for the full client request, multiple SCTASK can dilute this
• Waiting for client state: with parallel SCTASK it is unclear how to consistently manage “waiting for client” at overall request level
• Customer context: teams do not always see client comments on SCTASK, so they still rely on RITM or Case

We fully agree SCTASK is required for complex or multi team work.

So our intent is:

• RITM as primary lifecycle, SLA, and ownership record
• SCTASK used selectively for execution when needed

Question:
In a CSM to ITSM external client model, is this selective use of SCTASK acceptable, or is enforcing SCTASK for every request still considered best practice?