Extending the Catalog Task table (sc_task)

bevo · 3 weeks ago

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?

Uncle Rob · 3 weeks ago

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.

View solution in original post

MortenPettersen · 3 weeks ago

Greetings bevo

Have you looked at this (fairly) new thing they have launched, called Creator Studio? It allows for companies to quickly create "Request-based apps". I might be missing the target, cause I am not 100% I understood what you want to achieve, but just in case you where not aware of this I would take a closer look.

bevo · 3 weeks ago

Thank you @MortenPettersen , I did see that they redid the Studio UX since I took the CAD training. I found Creator Studio when I was looking for product documentation on the Guided Application Creator (GAC) which is being deprecated.

Doesn't this feel like re-creating the wheel? There's already a whole framework in place to manage requests from ESC and SP. Have you used it yet?

MortenPettersen · 3 weeks ago

I actually think it improves the wheel. Task (table) oriented workflows are better suited for the "i need help, not an item" scenarios.

In my opinion, trying to manage the I-just-need-you-to-do-something-for-me tickets using Request, Requested Items, and SC Tasks will usually lead to a less efficient workflow. Even though the tickets in this case goes to a Task (child table) you can have the end users submit their tickets using Record Producers which they find in ESC or SP.

Ankur Bawiskar · 3 weeks ago

@bevo

ServiceNow didn't make that sc_task table as Extensible with some purpose.

I believe the best person to answer this is raise a Case with ServiceNow and they can dig deep in their earlier days why they disallowed it.

If my response helped please mark it correct and close the thread so that it benefits future readers.

Regards,
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader