Extending the Catalog Task table (sc_task)

[bevo]

The last relevant community post I could find on this topic was from 2015.  And the consensus then was clearly "strongly advise against." I want to bring it up again to see if anything's changed.  I'm not so ambitious that I want to extend the whole Catalog/Catalog Item/Request/Request Item ecosystem.

But I am strongly considering extending the Catalog Task table (sc_task) to a new scoped app.  In my mind, this allows the segregation of labor required to fulfill, (and the reporting on labor) but maintains the native #itsm cart features and the catalog item (and RITM) can be maintained & accessed from the global scope.  I'm aware that I'll have to configure cross-scope access.

The Catalog Task table is not wildly different from the general Task table, yet is not extensible out-of-the-box.
Why shouldn't I extend the sc_task table? What am I overlooking or forgetting?

 

 

[Bert_c1]

Please don't recommend creating a Support Case for feature design questions. Support engineers do not participate in design and implementation of the Servicenow platform.  That is out-of-scope for the Support Team. If you want to interact with Servicenow Engineering attend a CreatorCon or Knowledge event. Making sc_task 'Extensible' is a customization, and is not supported.

[Uncle Rob]

@Bert_c1  - "Is a customization" simply isn't a satisfactory answer.
If we want people using the platform the best possible way, need to give better WHY answers when the easiest path LOOKS like the least recommended.

[Uncle Rob · Accepted solution]

The reason why sc_task is not extensible is because a lot of the underpinning code simply doesn't say "sc_task + any extension".  There are tons of places where functionality is looking for the sc_task table specifically.

ONE example is the variable editor and its obedience to client scripts and UI policies.  I extended sc_task years ago attempting to integrate a custom table into a legacy workflow.  I could never get the variables to display how I wanted.  

I treat Catalog Items as proto-apps.  Most of the time a catalog item is sufficient for a team's needs.
I then think of custom applications once some of the following conditions are necessary:
- Security and compliance considerations around data.  "ONLY X team should see these because legal/compliance says so"
- Significant data structure requirements that outpace OOB reporting or the necessity to relate to other tables in a way RITM/sc_tasks don't.

[bevo]

Thanks @Uncle Rob !
I'm glad that I'm not the only one who has been tempted to extend sc_task.  Our requirements fall into the 2nd category of structured data requiring custom tables.  So, I'm already building a scoped app, and I need a form in ESC/SP, and finally the fulfillers of the request are far outside IT service management.  They shouldn't get a standard ITIL role.  I'd like to design it with least privilege access. The bonus is the metrics run by IT against sc_task won't be diluted by this work. 

@Marcelo Pedreyr gave similar advice offline. 

I think where I'm settled is extending the base Task table, and then creating either classic record producer and/or create the new task from Flow Designer.

[Uncle Rob]

I think where I'm settled is extending the base Task table, and then creating either classic record producer and/or create the new task from Flow Designer.

---

This really is the best scenario.  If its important enough  you're tempted to extend sc_task, its important enough to be its own task type in the first place.

Back in the day the only REAL driver for my sc_task extension temptation was the participation of FOUR custom app types in a single Catalog item.  Each of the 4 teams tasks could be independent of that Flow as well.  Haven't had that situation since.