Designing Care Workflows: Six Questions That Shape Better Care Management

When a Simple Request Reveals a Deeper Design Problem

In care management software, you'll often hear a request that sounds deceptively simple: "When a care task moves from 'pending verification' to 'closed,' can we require the caregiver to fill in the verification outcome?"

That's reasonable. The person closing the task should explain whether the care was completed, couldn't be reproduced, or was refused. That information becomes part of the closure record.

But swap "verification outcome" for "root cause," and the rule changes. Root cause analysis usually happens during investigation, not at closure. For low-risk tasks, forcing a full root cause analysis might be overkill. A better design: make the verification outcome mandatory on closure, but only require a root cause if the severity hits a certain threshold.

This looks like swapping one field for another, but it reveals the core building blocks of any care workflow platform:

• What is a "care task"? That's defined by the task type.
• What data does it store? That's defined by attributes.
• What does the caregiver see when closing it? That's the transition form.
• Is the move from 'pending verification' to 'closed' allowed? That's the workflow.
• Which high-severity tasks must have a root cause? That's a rule.
• Where does this rule apply? That's the configuration scope.

So you're never just designing an input box. You're designing how an organization defines a category of work and how each individual care task follows the rules.

Six Questions Every Care Work Item Must Answer

A regular care task stores data. The metadata model defines how care tasks themselves should be structured. Start from first principles: every work item type must answer six questions.

First, what is this object? That's the type identity—stable ID, name, icon, description, and lifecycle management.

Second, what can this object store? That's the attribute model—text, people, enums, hours, attachments, relations, and computed values.

Third, how do users fill it out and read it in different scenarios? That's the form and page layout—new, detail, edit, transition, list, and card views.

Fourth, what changes are allowed? That's the workflow—states, steps, permissions, validations, post-actions, and auto-triggers.

Fifth, what other objects can it connect to? That's the relationship model—parent-child, dependency, blocking, and general links.

Sixth, where do these rules apply? That's the configuration scope—organization, space, work item type, business context, and config version.

These six layers can combine, but they shouldn't be mashed into one giant configuration table. Type identifies the object, attributes express facts, layout organizes interaction, workflow constrains change, relationships connect objects, and scope decides who's affected. At runtime, the platform resolves all six layers into the actual configuration a care task uses.

Why separate them? Because they change at different speeds and get reused in different ways. You might rename "care task" to "intervention," but API references can't break. The "responsible person" attribute can appear on tasks, incidents, and follow-ups, but the candidate pool might differ by team. The same set of attributes can form a simple creation form and a full detail page. One workflow can be reused across multiple teams, and an upgrade might only affect new instances.

If you copy everything into the work item type, admins end up syncing dozens of configs for one change. If you make everything independent config with no clear mapping, the platform becomes a maze only a few experts can maintain. The challenge is balancing reuse, isolation, and understandability.

Work Item Types Define Identity, Not Default Assignees

Many care platforms only ask for a name and icon when creating a new type. That makes it seem like a type is just a label. It's more than that: a type is the stable identity of a category of work, and the entry point where other configs attach.

A sturdy type definition includes stable ID, name, icon, description, and lifecycle rules. But here's the boundary: the type itself shouldn't have a default assignee.

The assignee is a person attribute on the care task instance. The default assignee, the candidate pool, and whether it's optional—those are rules for that attribute in a specific space, business line, or creation scenario. Baking them into the type causes three problems.

First, the same "care task" type might have different assignee rules across teams. One team defaults to the creator, another to the team lead, and another has no default. You don't want to create three separate types for that.

Second, the default value is a computed result at creation time, not part of the type's identity. When a fixed person leaves, the system should recalculate or prompt, not change the type definition.

Third, assignee eligibility intersects with permissions, space membership, and account status. "Can be an assignee" can be a type-level permission entry, but it constrains the candidate set, not the type's identity.

So the model is: the type answers "what is this object?" The assignee attribute answers "who is currently responsible?" And attribute rules answer "what's the default and who can be selected?"

From Fields to Attributes: A Unified Model

Older care tools call this "custom fields." The name is intuitive but limiting. Real care tasks are more than text boxes, dropdowns, and date pickers.

The assignee is a person object. Attachments are resources with file names, sizes, uploaders, and permissions. Hours include estimates, remaining time, logged entries, and who logged them. The parent task, iteration, and version are references to other objects. The subtask progress might be a computed result.

That's why I prefer "attribute model." The product configuration layer can adopt an extensible idea: everything is an attribute, and attributes form forms.

Common attribute types include text, number, date, person, enum, attachment, hours, reference, and computed. "Everything is an attribute" doesn't mean the database shoves everything into one value table. Attachments and hours still need separate resource tables and permission logic. But the product and API contract is unified: each attribute specifies its ID, type, value structure, cardinality, default rules, permissions, query capability, layout, and change history.

That brings a direct benefit: creation, detail, transition, and list views don't each implement their own field system. They pull from the same attribute resource library and configure different display and interaction modes. Open APIs, import/export, automation, and agents all understand data through the same attribute definition.

Attributes Are More Stable Than Controls

"Severity" might appear as a radio button on the page, but the platform also uses it for filtering, grouping, statistics, authorization, import, and automation. The control defines how users input; the attribute defines how the system understands and stores that fact long-term.

A complete attribute definition includes: stable ID, name, description, owner; data type, value structure, single or multi-value; options, units, precision, timezone, and valid range; default rules, null rules, and server-side validation; applicable spaces, types, and business scenarios; whether it supports filtering, sorting, grouping, statistics, calculation, and API writes; which layouts, workflows, reports, automations, and interfaces reference it; and decommission, migration, and historical compatibility strategy.

Once data exists, changing an attribute type isn't a simple edit. Changing a free-text priority to a dropdown means handling historical values like "high," "urgent," and "P0." Changing hours from "hours" to "person-days" requires a conversion rule. Changing a single-select to a person attribute might have no reliable conversion at all.

Take the assignee. The attribute definition is "single-value person." The candidate pool could be "research roles in the space." The default could be "the tech lead of the current business line." The null rule could be "allowed on creation, required before starting development."

The runtime candidate set is usually: active org accounts ∩ space members ∩ specified roles or groups ∩ what the current operator can assign. That's not overcomplicating. It avoids three common mistakes: assigning to someone who can't see the task, a default assignee who left still generating dirty data, and APIs bypassing the candidate list to set an invalid assignee.

If the default rule doesn't hit a valid candidate, the system should fall back to empty and show a clear message, or block the config from publishing. It shouldn't silently widen the candidate pool to the whole org.

Field Scope: Global vs. Space Attributes

Many platforms historically used "global fields" and "project fields" because a project was the config container. If your product has defined a long-term container as a Space, you shouldn't add another "project field" layer underneath. The naming changed, but the model still has two containers.

In the model I'm describing, attributes come from two main sources: the organization provides cross-space reusable attributes, and the space maintains team-specific or business-domain attributes. A one-off delivery needs things like "migration batch" or "special acceptance number," but those remain space attributes, limited by version, iteration, goal, or condition layout. They don't become a third kind of project field.

So attribute scope reduces to two config layers and one runtime data layer. The governance principle: the organization maintains a common language, the space maintains its business language, and work item instances only store current facts.

A special initiative shouldn't copy an attribute just because it's temporary. And a space shouldn't promote every local concept to a global attribute. Feishu's public model has both cross-space aggregable fields and space-specific fields. The real question isn't where the menu is; it's how cross-space queries maintain semantics. Same-named fields aren't necessarily the same attribute. Only when data types and business semantics match should attributes map to a unified metric.

Here's a direct test: can their values go into the same cross-space report? If one space's "client" means the contracting entity and another means the end user, they shouldn't share an attribute ID just because the name matches.

Page Layouts Are Scenarios, Not Data Definitions

With a unified attribute library, page layouts no longer define data. They answer: what does the user see, fill, and do in this scenario?

Take closing a care task. On creation, verification outcome and root cause shouldn't be barriers. During investigation, you can fill in root cause and fix plan. On the transition from "pending verification" to "closed," the form requires the verification outcome. If severity is "critical" or "high," validate that a root cause exists before closing. After closure, both fields remain visible but read-only for most members.

A mature layout model distinguishes at least five interface types: new, detail, transition, list, and card. The new layout should first ensure the object can exist: confirm space, type, title, and necessary context. Then set initial responsibility and workflow routing. If "business line" determines the workflow, it must appear at creation. If "root cause" only comes after analysis, it shouldn't be a creation barrier.

In the detail layout, users first judge what the task is, where it's stuck, who's responsible, and what they can do next. Then they read the description, acceptance criteria, subtasks, related items, and history. So the detail page has a stable skeleton: top for identity, status, and legal actions; main area for description and key business attributes; sidebar for assignee, priority, iteration, and other high-frequency info; bottom or tabs for subtasks, dependencies, attachments, comments, and change logs.

Here's a useful division of labor: attribute config handles long-term data rules, page layout handles interaction presentation, and workflow steps handle entry conditions for specific actions. "Title is always required" is an attribute rule. "Fill verification outcome when closing" is a close-step rule. "Where the verification outcome appears on the detail page" is layout.

Rules that affect data validity must be enforced server-side. Marking an attribute as required only in the frontend means batch operations, imports, APIs, automation, and agents can bypass it.

Workflows Define Lifecycle, Steps Define Legal Changes

A workflow isn't a side config of page layout. A state represents a stable phase. A step or transition represents an action that moves the task from one state to another.

"Pending verification" and "closed" are states. "Verify and close" is a step. That step can require a tester role, open a transition form, collect the verification outcome, check that high-severity tasks have a root cause, update the closer and close time, and write an audit record.

An executable step includes: start state and target state; action name; which roles can execute; what the transition page shows; preconditions and server-side validation; and post-actions like field updates, notifications, automation, and audit. If you only configure states, users can flip back and forth arbitrarily. With steps, the platform can explain who did what, under what conditions, and why the task moved.

Jira calls these transitions. ONES configures a step connecting start and target states, with validation, step attributes, and post-actions. The product model is the same: a step isn't another state; it's a constrained business action.

Multiple Workflows: Three Different Meanings

When people discuss "one type supports multiple workflows," they often mix up three things: whether the config layer allows multiple candidate workflows for the same type; how the system selects one at creation; and whether a single selected workflow supports parallel nodes.

Jira maps a type to a workflow via a workflow scheme in a project. One project can have several workflows, but a given type uses one. An instance has exactly one current state. Different teams get different workflows through different projects or schemes.

ONES configures one workflow per type within a project, with a default that admins can adjust or copy. In our model, that's a space-level boundary.

Feishu uses a business line field to route. The same type can have workflow templates for different business lines. On creation, the business line determines the workflow, so the user doesn't have to understand all options. The key isn't that a type binds to several workflows simultaneously; it's that a business field routes the same type to different templates.

TAPD lets categories select workflows, and workflows support serial or parallel modes. In serial mode, it's close to a single current state. In parallel mode, a task's collaboration is split into independently progressing nodes, dynamically generated by fields, with multiple nodes processed at once.

These aren't about who's better. They're three modeling choices: fixed mapping is simple and auditable; conditional routing lets one type serve multiple business lines but requires handling rule priority and versioning; in-flow parallelism expresses cross-role collaboration but introduces node owners, merge conditions, rollback boundaries, and progress calculation.

Whichever you choose, the running instance must save the workflow or workflow version. Otherwise, after an admin changes config, live tasks suddenly lose their state, nodes, or actions.

How a Care Task Gets Produced

Defining types, attributes, layouts, and workflows isn't enough. The real runtime chain connects admin definition, publish validation, creation-time resolution, and runtime execution.

Admins define type identity, then attach attribute sets, layouts, workflow mappings, relationships, and permissions. Before publishing, the platform checks that the initial state is unique, required attributes have an entry point, the default assignee falls within a valid candidate range, workflow routing has no duplicate hits, and relationship rules don't conflict.

When a user clicks "new," the system resolves the unique config based on org, space, type, and business context. It computes attribute defaults and assignee candidates, matches a workflow version, and only then creates the instance. After creation, every change goes through step permissions, action inputs, business validation, atomic updates, and audit records.

Layout isn't the source of runtime rules; it translates them into a UI. Pages, batch operations, import, API, automation, and agents must all go through the same server-side capability. Otherwise, "required," "permissions," and "workflow" only apply to manual page interactions.

Relationships Turn Forms into Networks

Care tasks aren't isolated records. A care plan breaks into assessment, intervention, and follow-up subtasks. One task might block another. An incident might link to a plan, a test case, and a release version.

Distinguish at least two kinds of relationships: hierarchical (decomposition, ownership, rollup) and associative (named business links). Dependencies, blocks, preconditions, and postconditions are directed and constrained; they shouldn't be mixed with parent-child just because both draw a line.

Hierarchy needs more than a parent_id. You must define which types can be parents and children, whether a task can have multiple parents, maximum depth, cross-space allowance, how progress and hours roll up, and whether completing a subtask triggers parent validation.

Associations need a name and reverse name, direction, allowed types on each end, cardinality, cross-domain scope, permissions, and business effect. "Blocks" and "is blocked by" are two sides of the same directed relationship. "Similar" is usually undirected. "Predecessor-successor" might participate in scheduling conflict and critical path calculations.

From the unified attribute model, parent and related versions can appear as reference attributes in forms. But whether a reference is legal is validated by the relationship model. Attributes carry the relationship entry point; the relationship model defines the semantics.

Configuration Scope: From Project to Space

Let's clear up a common model mistake: in this article's terminology, Space and Project aren't two nested containers. In Jira Cloud's current definition, a Space is the old Project—the same work container, not "a project inside a space."

Atlassian explained the rename in 2025: a traditional project has a start, end, and scope, but Jira's Project is actually a container for work items that isn't bound to a single project lifecycle. The rename was mostly a term swap, but it highlights a modeling problem: when a container is meant for long-term collaboration, calling it "project" makes people think it should end when a delivery ends.

Space better expresses a long-term work boundary. A product team, business line, or function can live in one space for years. Work item types, attributes, workflows, layouts, views, roles, automation, and the work items they create are all managed by the space. People change, versions release, special initiatives end, but the team's language and history remain.

Where does a specific delivery go? Not into a new "project" entity. You organize a group of work items with shared goals and time boundaries inside the space. Use goals, versions, iterations, milestones, tags, parent work items, or combined views. For example, "payment internationalization phase 1" could be a goal, two versions, and a set of requirements and defects. When it ends, those items are archived or closed, and the space continues for the next iteration.

So configuration scope should converge to three layers: organization standards, space active config, and delivery context (versions, iterations, special goals). Delivery context can participate in filtering, routing, permissions, and stats, but it shouldn't become another config container. Otherwise, every special initiative copies fields and workflows, leading to same-named fields with different meanings and unreconcilable cross-initiative reports.

At runtime, the platform reads org standards, resolves the space's active config, selects rules based on type and business context, and overlays user permissions to produce the unique page and behavior. It should also explain the result: which attributes come from org vs. space, why this type hit this workflow, why only three people are selectable, and whether it's running workflow v3 or v4. Without that diagnostic ability, the more flexible the config, the more you rely on a few experts to debug.

Configuration Changes Are Rule Changes, Not Form Saves

Attributes, workflows, layouts, and relationships are referenced by many existing care tasks. Making "verification outcome" required on close might break a batch close API. Deleting the "pending verification" state might strand existing tasks. Changing a 1:n hierarchy to n:n changes rollup and permission semantics.

So the metadata model needs a lifecycle for configuration itself. Stable IDs and reference analysis: types, attributes, states, steps, layouts, relationships, and config schemes all need stable IDs. The config center should show which spaces, filters, reports, automations, APIs, and running instances use them. Without reference data, impact analysis is guesswork.

Draft, publish, and versioning: high-risk changes shouldn't go live immediately for all spaces. Adding an optional attribute or tweaking help text can propagate fast. Deleting a state, changing an attribute type, adding a required transition field, modifying routing rules, or changing relationship cardinality should default to a new version, with clear rules about which spaces and instances upgrade.

Deprecation, migration, and historical compatibility: when a field, enum option, or relationship is no longer needed, prefer deprecation over deletion. Type conversion and cross-space moves must handle attribute, state, workflow, hierarchy, association, and permission mappings. Workflow upgrades should specify whether existing instances stay on the old version or map to the new one.

Converting a "task" to a "bug" looks like a dropdown change, but it's actually a constrained data migration. You have to re-resolve target attributes, layouts, workflows, and relationships: what if required attributes are missing, how do source states map to target states, is the parent-child relationship still legal, and are attachments and hours preserved?

Summary: Type Is the Entry, Attributes Are Facts, Workflow Is the Rule

On the surface, configuring a care platform looks like creating types, dragging fields, adjusting pages, and drawing a flowchart. What really determines the platform's ceiling is whether the boundaries between these capabilities are clear.

Type defines the stable identity of a category of work. Attributes use a unified contract to carry titles, people, hours, attachments, references, and computed results. Layouts compose them into creation, detail, and transition forms. Workflow constrains how the object changes. Relationships decide how objects decompose and connect. Space separates long-term team rules from one-off delivery scope. Config versions protect running care tasks from being suddenly changed by a backend edit.

Back to the opening question. "Require verification outcome when closing a care task" isn't adding a required box to the detail page. It's adding an action input to the "close task" step. "High-severity tasks must have a root cause before closing" isn't making root cause globally required. It's adding a conditional server-side validation. They can appear on the same transition form, but they belong to different rule types.

When a care platform can stably answer "what is this object, what facts does it store, how does it interact now, what changes are allowed, what can it connect to, and where do rules apply," it moves from a configurable table to an enterprise-grade care work platform.