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?

[DirkRedeker]

Hi

Understood.

Do you have some use cases, that you plan or need to implement so that I can give you my feedback and idea on how I would decide to implement?

Maybe that would also answer your question, because there may be hundreds of use cases that are implemented by members here.

Anyhow, I do NOT think, that changed throughout the last releases and will also not change for upcoming releases.

This is a very basic decision (done at the database level and reaches up to business logic).

So, feel free to mark answers as helpful and I am looking for more to come from you - as written from you above.

BR

Dirk

[Community Alums]

Super late response, but here is the summation of what I came up with...

SUMMARY

EXTEND FROM TASK IF

• You will be utilizing parent/child form cross-dependency functionality (workflow approval activities related to these are pre-built, but only work for tables that extend from task)
• Your instance uses ITSM and itil roles
• Your user base is very familiar with ServiceNow and it used to working with task based tables and fields
• You will be using OOB SLA / Service Levels / Inactivity Monitor functionality (although these could be built out manually using scheduled jobs with a custom 'SLA Tracking' type of table)
• You will be using OOB Assignment Rules

EXTEND FROM TASK NO LONGER NECESSARY TO HANDLE

• Approvals, the user approval workflow activity accommodates groups, users in any combination. If you are using child task approvals in conjunction, you will want to extend from task as before.
• Task workflow activities, these can now be scripted in a couple lines of code and added to a run script workflow activity.

ADDITIONAL DEVELOPMENT EFFORT COMPARISON NOTES

THINGS I HAD TO DO IN TASK EXTENDED REQUEST TABLE/FORM THAT I DID NOT HAVE TO DO IN CUSTOM TABLE

• for state field, override to set default value
• Created ACL field level read overrides, one each, for all fields I used, short description, description, assigned to, work notes (read and write), * (to allow field level overrides)
• ***Remove the UI action 'Follow', not sure how to even do this

THINGS I HAD TO DO IN CUSTOM TABLE/FORM I DID NOT HAVE TO DO IN TASK EXTENDED REQUEST

• Make Assigned To dependent on Assignment Group
• Create fields State, short description, description, assignment group, assigned to, work notes, parent

THINGS I HAD TO DO FOR BOTH

• Create state field choices and make it read only
• Make number read only
• Create a custom UI action 'Submit' which changes state that triggers workflow

[Daniel Draes]

THINGS I HAD TO DO FOR BOTH

• Create state field choices and make it read only
• Make number read only
• Create a custom UI action 'Submit' which changes state that triggers workflow

Correct... but on task you do it ONCE and it works for all inherited tables UNLESS you overwrite it again. 

THINGS I HAD TO DO IN TASK EXTENDED REQUEST TABLE/FORM THAT I DID NOT HAVE TO DO IN CUSTOM TABLE

• for state field, override to set default value

You would do the same on your non-task table, just differently.

• Created ACL field level read overrides, one each, for all fields I used, short description, description, assigned to, work notes (read and write), * (to allow field level overrides)

Why is that? Maybe I am missing the point.

• ***Remove the UI action 'Follow', not sure how to even do this

This is a regular UI Action if I am not mistaken - or are you pointing on something else?

[Alan So]

It's really nice to read the summary from @christinemayfield 

Anythings are different regarding approval if Flow designer is used instead of Workflow editor?

Thanks.