A subtask’s result must be brought back into the main flow
Aliases: return value to parent · picker result · write back to slot
What it is
Someone leaves the main flow to pick an address, an invoice, a permission. The object they finished must appear in the slot that was waiting for it, not only inside the subtask’s own “saved.” Bringing the result back is a data return: the subtask’s output is the main task’s input. Landing in place with an empty slot still makes people believe the pick failed, or they go hunting in the subtask’s list to see whether another copy was stored.
Why it happens
In the user’s model the subtask is a call with a return value, not an independent submit. An address picker means “hand this address to the order being filled,” not “add a row to the address book and please pick it again on the order.” If the subtask writes only its own store and does not write a reference into the parent field, two submission worlds split: the book has it, the order does not. Parent validation then says “please fill in an address,” and the work just done is invisible.
Return also fails on shape: the subtask yields a full object, the slot wants an id or a formatted string; drop the mapping and the slot shows [object Object] or nothing. Cancel must return “no change”: it must not write a half-finished value into the slot, and it must not clear a value the slot already had. People judge subtask success by “is that item in the slot,” not by a success toast inside the subtask.
Studying it
Leave one slot empty on the parent form. In the subtask, pick a known object. After completion, allow looking only at the parent form.
- Independent variables: return path (write the field / save only in the subtask / write back with the wrong shape), whether cancel mutates the parent slot.
- Dependent variables: whether the correct object appears in the slot, whether people re-enter the subtask to check, whether the parent can validate using that value.
- Methodological note: a success toast makes participants report “done” even when the slot is empty. Score the slot, not the verbal completion. Add a contrast “create a new object inside the subtask”: the new object must also become the slot’s value, not merely appear in the object list.
Where it stops holding
If the subtask’s purpose is an independent submit (create a project unrelated to the current form in another module), the parent should not be written; this leaf does not apply. Read-only preview subtasks have no result to bring back. If permission prevents the chosen object from being referenced by the parent, bring back the failure reason and leave the slot empty; do not write an id that will explode on parent submit. If the slot can hold only one item and the subtask is multi-select, the return must say which one is kept; silent drop is not a return.
Applying it
- Treat the subtask as a call with a return value: on Done, send the object id and display text into the parent slot and run that slot’s validation; on Cancel, send a no-op.
- Show the selected object’s readable name in the slot immediately; do not change only a hidden field.
- “Save to the address book” inside the subtask may happen; it must not replace writing the parent slot.
- Verify: from an empty slot open the picker, choose one, Done. The slot shows that name; the parent can submit. Cancel leaves the slot empty. Then create a new object inside the picker: it must appear on the slot, not only in the address list.