A new process needs records with an assignee, a state and an audit trail. Extend task, build a standalone table, or add fields to a table we already have?

The first data-model workshop on any custom application.

One of 39 decision guides. Each is a flat recommendation, the reasoning behind it, the conditions that reverse it, and the mistake people actually make — with the symptom you would see on the instance.

Recommendation

Extend task when the records are work someone is assigned and moves through states. Build a standalone table when they are not. Add fields to an existing table only when the record genuinely is that record.

Why

Task brings number, state, assignment, approvals, SLAs, work notes and the audit trail. Rebuilding that on a plain table takes months and never quite matches.
Everything that already understands task keeps working. My Work queries task and returns every child type, SLA definitions attach at task, and approvals target task.
Extension is not free. sys_db_object.extension_model decides whether your rows sit in their own storage or share the family's, and it has varied by release and table setting. Check yours.
Adding a column to task alters the shared parent and every child inherits it. Put the field on the child, and promote it to task only when three or more children need the same meaning.

What flips it

Advice that never reverses is a rule you memorised, not judgement. These are the conditions under which the recommendation above is the wrong answer.

The records are reference data or high-volume log rows, not assigned work.

InsteadBuild a standalone table. Millions of rows with no assignee have no business inside the task family.

The volume is large and the process uses almost none of task's machinery.

InsteadBuild a standalone table and add the three fields you actually use. Extension you do not use is a permanent tax on every query against the family.

The requirement is one extra attribute on records the business already calls incidents.

InsteadAdd the field to incident. A parallel table shadowing incident is far worse than a column.

The application will be installed on instances you do not control.

InsteadKeep the table inside your own scope. Extend task only if you are willing to ship a table into someone else's task family and own what that does to their queries.

The common mistake

Teams build a custom table to keep things clean, then spend two sprints re-implementing state, assignment and notification by hand. The symptom is a custom table with fields called assigned_to, state and short_description, plus a business rule that emails the assignee.

Where this sits. In the app this guide links through to the modules that teach the mechanism — ServiceNow Foundations, Performance & Instance Health, Scoped App Development — and to the architecture assessment domain it supports, so a weak domain score leads straight here. Those links go into the app, which is behind the invite.

608 more pages are behind the invite.

This sample is 4 pages — this one and 3 others — generated straight from the corpus behind the app: 31 modules, 335 lessons, 238 how-to guides and 39 architecture decision guides. The rest is behind an invite.

Access is invite-based and free, and requests are read by a human — expect your invite by email within a day or two.

Request access What LearnSN is The rest of the sample