Now with Paris, what is the benefit of extending from task for a custom scoped application?

[Community Alums]

For ServiceNow 'Old Timers'...

I would like to revisit the tribal knowledge tradition where we extend the task table for custom scoped application request/case management forms. I wonder if there is no longer a benefit to this, given ServiceNow's expanding capabilities with each release?

Recently I built an entire workflow using OOB activities that worked just as elegantly as they do for a task extended table, on a table that was NOT extended from task. I also found myself peer reviewing UI actions where a developer had to create new Approve and Reject UI actions for a table that DID extend from task (I expected task table UI actions to automatically show, we used Flow Designer for this one).

With ServiceNow's every expanding capabilities, is there any benefit to extending from task for a custom scoped app request form table? And if yes, what specifically?

[Daniel Draes]

I still go with task as parent for most of what I do as a custom app. Why? Quite some capabilities are already there and I do not intent to change it. Examples are around

• Status fields and management (e.g. auto close)
• Widgets / Worklists etc. automatically work (My Work, My Open Cases, My ....) for fulfillers as well as end users
• Reporting for the enterprise overall is simple as we have the same base table
• Approvals just work
• Easy to find in a support scenario - think your customer is raising a HI case for something not as intended. Our support will need way more time to understand the separate table / process as if it is linked to task
• Benefit from newer functionality more quickly (not done it yet, but I would think that Agent Workspace, Agent Assist, etc. are easier to reuse in task tables then somewhere else)

Just a few thoughts on my head.

[Community Alums]

So, playing devils advocate, based on the fact that Task derived fields and associated code have to often be overwritten to accommodate custom app requirements. This, I notice, sometimes requires more effort than effort to replicate Task table data/code in a new table. Here are a couple things I think might change your list.

• Status fields and management (e.g. auto close)

Not sure what you mean by this? In my experience with task derived table record closure, this always needs to be explicitly defined. Is there an 'auto-close' functionality tied to a UI action that could be used without additional coding / customization?

• Widgets / Worklists etc. automatically work (My Work, My Open Cases, My ....) for fulfillers as well as end users

I think this is a good point, but my experience is that non task derived tables usually work well with OOB widgets (have not had an issue yet), but you are right that custom filters / relationships would need to be created for views to include a custom app table with other task derived task table records, but this to me is a light lift, so might be less effort than the above 'overrides' that usually need to be done for a task derived table.

• Reporting for the enterprise overall is simple as we have the same base table

UNLESS the company does not use ITSM at all, or uses it very little.

• Approvals just work

I have had no issues in approvals working with non task derived tables. To me they work the same in both a task derived table as a non task derived table

• Easy to find in a support scenario - think your customer is raising a HI case for something not as intended. Our support will need way more time to understand the separate table / process as if it is linked to task

I have never had a HI case where the tech support person had a hard time finding a table or tracking down an issue for a table derived from task. I am not sure how this one applies at all, really. Maybe you could clarify?

• Benefit from newer functionality more quickly (not done it yet, but I would think that Agent Workspace, Agent Assist, etc. are easier to reuse in task tables then somewhere else)

I am interested into how Agent Workspace, Agency Assist will work for any custom created tables, extended from task or not. It is my understanding that right now, these features are only tied to OOB modules and have very few customization options. Do you have a different view?

[Daniel Draes]

Somehow I missed that reply... sorry, just came up again in my inbox 😄

Wanted to answer at least to some points from above.

• Status fields and management (e.g. auto close)

Auto close was probably a misleading trigger, it meant the active/inactive part which you can control with dictionary attributes. This automatically sets a record to inactive in defined states. I believe it to be important to have active/inactive for tables with large volumes like task. This includes also table indexes to have good performance on querying the table. Which kind of is missing on custom tables setup steps - define the proper indexes.

• Reporting for the enterprise overall is simple as we have the same base table

Not getting why using ITSM or not would changes this. If I think about a customer on the Enterprise Service Management journey where you want to have a central place for all your employees requests, it is good to be able to manage them similarly. Spreading them out on lots and lots of independent different tables will not really help in streamlining your processes.

• Approvals just work

Indeed, approval do work on all kinds of records these days.

• Benefit from newer functionality more quickly (not done it yet, but I would think that Agent Workspace, Agent Assist, etc. are easier to reuse in task tables then somewhere else)

With custom workspaces in Rome you can create workspaces for pretty much any table (yes, also non-task tables 🙂 ), but all our templates will be using a task table. It should be much simpler to change to another task table then a non-task one for similar activities. Same with Agent Assist.

[DirkRedeker]

Hi

If your question is answered, can you please mark the best answer as correct to close this thread?

Thanks & BR

Dirk

[Community Alums]

I plan to have 'for this situation, usually, vs. for that situation, rarely' answers with some explanation to address functionality in ServiceNow that has improved / changed with recent releases. That to me, will answer my question.

I myself have been testing this in Orlando, but need to pivot to Paris, so more to come from me. 

I am very interested in thoughts from other devs / architects.