[object Object]

Every junior architect’s instinct is to extend task. Every senior architect has at least one war story about regretting it. The decision is not religious — it is a tradeoff, and the tradeoff has a clear shape.

What you get for free by extending task

Workflow context, SLA engine compatibility, the assignment model, work notes, approvals, the activity stream, and visibility on the homepage filters and global search. None of these are trivial to rebuild.

What you inherit forever

Every Business Rule on task runs against your records. Every ACL on task applies. Every UI Action shows up. Performance Analytics aggregations across task include your rows. Most importantly, every upgrade that touches the task table touches yours.

The three-question test

  1. Will this record participate in the standard work assignment lifecycle? If a fulfiller picks it up, works it, and closes it, lean toward extending Task.
  2. Will SLAs apply? The SLA engine targets the task table by default. Extending makes attachment trivial.
  3. Is the dataset bounded — under one million rows in five years? If yes, the task overhead is acceptable. If you are modeling telemetry or events, build a standalone table.

Custom tables done right

If you go standalone, do three things up front:

Prefix: u_  (always — never x_ unless scoped app)
Auto-number: enabled with a meaningful prefix
sys_id strategy: GUID default, no business keys

Add created, updated, created_by, updated_by even though they are inherited from sys_metadata. Future reporting will thank you.

The naming mistake everyone makes

Do not name a custom table u_request. Within six months a vendor app or an upgrade will introduce a request collision and your table joins start failing with cryptic errors. Use a domain prefix: u_facilities_request, u_legal_review.

Migration is brutal — choose once

Going from “extends task” to “standalone” later is a six-week project with downtime. Going the other way is worse. Spend the hour up front to choose correctly.

What to do this week

For your next data model proposal, write the three-question test answers in the design doc. If you cannot answer all three, you are not ready to build.

[object Object]
Share