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?

[guythatusesserv]

Good insight.  You're definitely bringing up some good points.

[DirkRedeker]

Hi

Task is one of the very core tables.

Of course, you do not need to use that table as parent, but anyhow, it brings a lot of fields and logic, that you can inherit, without inventing the wheel once more.

There are not only the fields and rules on task, but also e.g. some Workflow Activitys, that are only available for task based tables.

Furthermore, all task derived tables also write to the task base table, which makes a central point of tasks to work on, in the system. I may compare that with log tables.

Some apps have their own logs, but wouldn't it be nice to have all logs in one place.

Nevertheless, there are more log tables in ServiceNow thab the system log.

This can be compared with taking task as a base table.

I think it does not depend, if the idea is 5 years old, or we talk about the Paris release.

It all "depends"... On your scenario.

There is no such "always do like that" rule on that.

For me, still I always think first, if task is a good friend, before repeating to develop what is already there.

Let me know if that answered your question and mark my answer as correct and helpful.

BR Dirk

[Community Alums]

I am a huge fan of 'not inventing the wheel', but in my experience of developing many custom apps for clients, I notice that the Task derived fields and associated code have to often be overwritten to accommodate the app requirements. This, I notice, sometimes requires more effort than effort to replicate Task table data/code in a new table.

I absolutely agree with the 'it depends' answer. I was hoping for guidelines where we could say for this situation, usually, vs. for that situation, rarely.

Can you talk about the 'logs' differentiation between a table that extends task vs a custom created task? I am not familiar with table specific logs.

[James Branagh]

Additional thing that springs to mind is the use of SLA definitions.  If you want ot use SLAs to track your tasks then you need to extend from Task.

[Community Alums]

I think this would be a 'usually' case, if your table will have SLAs associated to it, you would almost always want to create a table extended from task.

Thank you:)