Make To Do management robust enough to run cross-departmental workflows

Integrators are using To Dos in D-Tools Cloud to coordinate work that spans departments — sales, design, engineering, programming, installation, and service all touch the same project and need a way to see, sort, and route the work that's on them. Today's To Do system is built around a flat list of items with a fixed set of fields (name, description, priority, due date, status from a system list) and a checklist of simple sub-items. That's enough for a personal task list. It's not enough to run an operations workflow.

Dealers comparing the current capability to general-purpose task platforms (Asana, ClickUp, Monday, and similar) consistently identify the same gaps:

• No custom fields, so there's no way to capture department, work type, customer-specific identifiers, internal reference numbers, or any other data the dealer's process depends on.

• No tenant-defined To Do statuses, so every dealer is locked into the same fixed status set regardless of how their workflow actually moves.

• No nested sub-tasks — only flat checklist items — so a larger To Do can't be decomposed into ownable, scheduleable child items.

• No dependency or predecessor relationships, so the system can't express "B starts when A is done" or surface blockers when an upstream item slips.

• Sorting and filtering are limited to the default column set, so there's no way to organize a board by department, work type, owner group, or any custom attribute a dealer might add.

Why this matters

• To Dos are how integrators coordinate across roles. A real project hand-off — design completes, programming picks up, install schedules, service follows — is exactly the kind of work where custom statuses, dependencies, and per-department views earn their keep. Without them, dealers run that coordination outside D-Tools in a parallel tool.

• The current model leaks work to external systems. When the To Do system can't carry the dealer's process, the dealer adopts Asana, Monday, ClickUp, or a homegrown spreadsheet alongside D-Tools — and now the project record and the work record live in two places that have to be reconciled by hand.

• Larger dealers feel this most. Single-tech shops can live with a flat list. Multi-department operations — sales, engineering, programming, install, service — need filtering, ownership, and dependencies that match how the org actually runs. As D-Tools moves upmarket, the To Do system becomes a bigger gap.

• Custom fields and custom statuses unlock everything else. Once dealers can define their own attributes, downstream capabilities (reporting, automation, board views, integrations) have something to hang off of. Without them, those features stay limited to the system-defined dimensions.

Open questions

• What's the right scope for v1 — custom fields and custom statuses on their own (foundation), or also sub-tasks and dependencies (full Asana-style upgrade)? These can ship together or in phases.

• Should custom fields apply only to To Dos, or also to Projects, Opportunities, Service Calls, and other work records that share the same coordination problem?

• What field types should v1 support — text, single-select dropdown, multi-select, numeric, date, user picker, currency, checkbox? Each adds UI and reporting complexity.

• For sub-tasks, do nested To Dos inherit ownership, due date, or status from the parent, or are they fully independent records with their own lifecycle?

• How deep should nesting go — one level of sub-tasks, multi-level hierarchy, or configurable?

• For dependencies, are we modeling simple "blocks / blocked by" links, or full predecessor types (finish-to-start, start-to-start, finish-to-finish) like a Gantt-style scheduler?

• How should custom statuses interact with system-defined logic that currently keys off the fixed status set (overdue notifications, scheduling, reporting)? Mapping custom statuses back to a small set of system meta-statuses (Open / In Progress / Done) is one approach.

• Do custom fields need to be reportable and filterable in existing report builders, or is in-place filtering on the To Do view enough for v1?

• How does this interact with the existing Project Task system (scheduled labor work) — are these two systems converging, staying separate, or sharing custom field infrastructure?

• Permissions: who in a tenant can define custom fields and custom statuses? Admin-only, or any user?

Possible directions

Exploratory only — not commitments.

• Phase 1 — foundation. Tenant-defined custom fields on To Dos (text, dropdown, numeric, date to start), tenant-defined custom statuses, and sorting/filtering that includes both. This alone closes a large portion of the gap and is the cleanest sequencing because everything else depends on it.

• Phase 2 — structure. Sub-tasks (nested To Dos with parent-child relationships) and dependencies (blocks / blocked by). This is where the "run a real workflow" feel comes in.

• Phase 3 — views and automation. Saved views per user or per tenant (filter + sort + group presets), board / kanban view keyed off custom status, and rules that update fields or trigger notifications based on status transitions.

• Cross-entity consideration. If custom fields are built as a reusable platform capability (not just a To Do feature), the same investment extends to Projects, Opportunities, Service Calls, and other records over time. Worth weighing the upfront design cost against the long-term leverage.

• Adjacent ideas to fold in or link. Custom task statuses, column view for Tasks, comments-inside-To Dos with timestamps, To Dos via the API, overdue notifications, PM filter on To Dos — all reinforce the same underlying gap and should be tracked against this umbrella idea.