Merge a to-do list

Most projects start with a to-do list someone already keeps in a spreadsheet. Merge a to-do list brings it into the project’s task list once, and then again whenever a newer revision of the same file arrives: rows are matched on their number, so a revision updates what it finds and adds what is new. Nothing is kept in sync with the spreadsheet afterwards — the task list is the record from the day you cut over.

From the Tasks page

Open Merge a to-do list (in the ⋯ menu on the Tasks page) and either upload the workbook (.xlsx, up to 25 MB — for a CSV or pasted rows use the register’s Import) or pick one already filed in the project’s Files. Anyone who can write tasks on the project can run it. ddx PMO reads the sheet, finds the header row itself (even under a legend and a title), and shows a preview:

• Columns. Each column is mapped to a task field — number, item, responses, owner, status, due date and so on. Headers it recognises (in English, Japanese and Korean) are mapped at once. When a sheet arrives in a shape it cannot read, an AI model reads the headers and a few sample rows and suggests a mapping, including what the sheet’s own status words mean; the suggestion is shown in the preview for you to check and change, and nothing is written until you merge. You can also ask for a suggestion yourself with Suggest mapping.
• Parties. Owner and raised-by codes (STL, TRD, MI…) are matched to the project’s companies; anything unmatched is mapped by hand, or created on the spot by a workspace admin.
• Rows. Every row shows what the merge will do — create, update, close — with problems and warnings. A new row whose title reads like a task already here is flagged as a possible duplicate: create it anyway, leave it out, or merge it into that task so its responses and files land there.

Merge writes the tasks, their reply threads (each ⇒ entry a reply, with the sheet’s stamp and company where it has one) and any images anchored to rows; the area column becomes a tag. The mapping you confirmed is remembered for that shape of sheet — for the partner that sent it, or for the whole workspace when you uploaded it — so the next revision previews with it and asks the model nothing.

Closing a task a company owns needs closing authority on the project, and so does moving such a task to another company. Closing an action (a task with no company), or giving one a company, does not. Each row is judged on the task as the merge will leave it: a row that gives an action to a company and closes it closes a company’s task, and a new closed row with no owner is a company’s task when you pick a company for such rows (or the list is a partner’s). If you don’t have closing authority, the preview marks each row that needs it.

A task already here whose clearance keeps it inside the project team can’t be given to a company that works through the partner portal, because that company would never see it. A row that would do that is marked as needing attention, says why, and is left out of the merge; the rest of the list still merges.

Merging again

Rows are matched on their own number (A-1, B-07), so merging a newer revision of the same file updates what it finds and adds only the replies and files it has not seen — never a duplicate (but see the two kinds of older row just below). A number belongs to the company whose list it came from: a partner’s submission, and the managing partner’s own merge, match the tasks that company’s earlier lists numbered (and the project team’s), never another company’s task that happens to carry the same “A-1”. Numbers already on tasks before this was introduced count as the team’s.

Your own uploads match the project team’s numbers — unless the list is a partner’s. When a partner’s list reaches you by email or in Files and you merge it here, say so in Whose list is this? at the top of the preview. It offers the companies with a partner space on the project; anyone else’s list — your own company’s, the client’s — is merged as the team’s own. Named as a partner’s, the list is merged exactly as that partner’s own submission would be (see From the partner portal): its numbers are matched against the tasks that partner’s own lists numbered, among the tasks that partner can see through the portal; its new rows are numbered as its; and rows with no owner become that partner’s tasks. So neither its next submission nor your next upload brings them in twice. (A submission never asks: it is its sender’s list.)

Two kinds of older row are not found by a partner’s next list, and come in again as new tasks: rows merged from that partner’s list before 16 September 2026 (they carry the project team’s numbers) that the partner cannot see, and rows with no owner from a list you named as that partner’s before this change (they were left as actions, which no partner sees).

A number you change or clear by hand on the Tasks page becomes the project team’s. When two companies are merged in Clients & vendors, the numbers the merged-away company’s lists gave, its pending submissions and the mappings remembered for its sheets all move to the company kept; a company whose numbers tasks still carry cannot be deleted — merge it.

On a task already here the sheet refreshes the item text, detail, due date and raised-by; a status only moves forward (Open to WIP, or to Closed), so a task being worked on here is never pulled back, and a sheet with no priority column leaves priorities alone. A row the sheet marks closed is closed here with its last reply as the outcome, dated as the sheet says and recorded in the audit log under the name of whoever ran the merge. A task that is closed when the merge reaches it stays closed even if the sheet now says otherwise — one closed while the merge was running included — and keeps its own close: its note, its date and any decision it recorded. A row whose owner code is not mapped is held back; a row with an empty owner cell becomes an action with no company, on no list (shown only with Include actions), unless you pick a company for such rows — or the list is a partner’s (its submission, or one you name as its), whose rows with no owner become that partner’s tasks. The list you merge into holds the rows a company owns. When a later revision names an owner for such an action, merging it gives the action to that company and puts it on the list you merge that revision into; that needs no closing authority.

Forecast and % complete columns

If the sheet has a forecast column (the date the work is now expected to finish: Forecast, Expected completion, ETA, 完了見込み, 예상 완료일…) or a % complete column (% complete, Progress %, 進捗率, 진척률, or a progress heading with (%) after it), the merge reads them too. A column called Target date, 完了予定日 or 완료 예정일 is still the due date: the forecast never moves it. A sheet you merged before these columns were read picks them up on its next merge; a column you set to ignore since stays ignored.

• The preview shows each row’s forecast and % under its due date.
• On merge, each row whose forecast or % differs from the task’s is recorded as a progress update — the same as one typed in the task’s panel, in the task’s History marked from a merged to-do list, under the name of whoever ran the merge. A % above 0 moves an Open task to WIP.
• A blank cell changes nothing: a merge never clears a forecast. Merging the same sheet again records nothing new.
• A % cell may say 60%, 60, or 0.6 (read as 60%, and the preview says so); in a column of fractions (0.25, 0.5, 1) the 1 is 100%. A cell formatted as a percentage is read as it shows. Nothing short of 100 reads as 100. A value that cannot be read is left out, with a warning on the row.
• A task that is closed here keeps its forecast and %; the preview says so.
• A merge tells nobody that a forecast has slipped past the due date — as with everything else it writes. The weekly summary still lists every open task whose forecast is after its due date.

From the partner portal

A delivery partner’s uploaders and editors can send its own list from the To-dos tab of the portal with Merge a to-do list: upload the workbook with a note for the project team. It is not merged by the partner — it waits as a submission that the managing company (its members, project leads and workspace admins: the same people who can close tasks) opens on the Tasks page (Pending merges), previews exactly as above, and merges or declines with a note the partner will see.

A partner’s list only ever lands on tasks that partner can see through the portal. Its rows are matched, offered as likely duplicates and merged into only among those tasks — never a task the partner cannot see, even one you can. A row whose number belongs to a task the partner cannot see comes in as a new task, in the partner’s own numbering, so nothing the partner reads afterwards (its counts, its To-dos) tells it that task exists. The same goes for a list you merge from the Tasks page and name as that partner’s under Whose list is this?. A row you choose to merge into a task the partner cannot see is refused, saying the partner can’t see that task.

If what the partner can see changes between your preview and Merge — a list shared with it or un-shared, say — the merge goes by what it can see at that moment: a task it can no longer see is not updated (that row comes in as a new task), and a row you chose to merge into such a task stops the whole merge before anything is written; preview it again. And if the partner loses sight of a task while the merge is running, that row is not saved: its result says the partner can no longer see the task, and — for a submission — the partner is told only that a row needs your attention.

Every member of the partner’s space sees the status of each submission on the To-dos tab, and an uploader or editor can withdraw one that is still pending. Once one is merged, the partner sees how many tasks it created and updated, and how many of its rows need the project team’s attention — never which rows, or why: the team merged it with its own access, and a row’s problem can say something about the project only the team may know (on older merges, even about a task the partner cannot see). Rows in a partner’s list that name no owner are given to the partner’s own company when merged, unless the reviewer picks another. The partner can say which of the project’s lists it is for — any list it sees on its To-dos — and the review starts on that list (Into list), which the reviewer can still change; a list archived since is flagged. The partner’s own list of submissions names that list only while the partner can still see it. The submitted file is kept until the submission is declined or withdrawn — and after it is merged too, so that undoing the merge can send it back for review.

When the partner runs the project’s task list

The company named under Who runs this list (the Tasks page’s Task settings) runs the project’s task list, so its editors merge their own workbook themselves: Merge a to-do list on their To-dos opens this same merge — columns, parties, likely duplicates, Into list — and merges it straight away, with no submission and nobody reviewing it first. Everyone else, including that company’s uploaders and any other partner (even onto a list of its own), still sends a submission as above.

What that company’s merge can reach is what its portal shows it:

• New rows go on a list it runs: one of the project’s lists, or one of its own.
• A row matches only a task it can see. A number already used by a task it cannot see is not matched, so that row is added as a new task, and nothing tells the partner the hidden task exists.
• Likely duplicates, and the tasks it may merge a row into, come only from the tasks it can see.
• A matched task on a list it does not run (another partner’s list shared with it), or on an archived list (even its own), is marked as needing attention and is not changed. So is a task that changes while the merge runs — moved out of its sight or onto a list it does not run, or its list archived, or the company no longer running the project’s task list — right up to the moment the merge saves that task: none of its row is written, and previewing the list again shows where the task now stands.
• Party codes resolve only to companies it may give tasks to, each row judged on its own list: a new row on the chosen list, a task already here on the list it is on. A company it picked for a code, and may not name on a list it then moves the merge to, is dropped, and the code is read again among that list’s companies. It cannot create a company; you add companies to the project.
• Rows that name no owner become its own company’s tasks, and rows that don’t say who raised them are recorded as raised by it.
• Replies in the sheet are recorded as that company’s, with the sheet’s own stamps shown beside them as written. The platform can’t vouch for who a stamp says spoke, so it never credits the reply to that company.
• The area column tags a task only with tags the project already has.

The merge is recorded in the project’s history as that company’s (it can undo it from Merge history on its To-dos while it still runs the list), and the shape of its sheet is remembered for its next merge — the columns, and the companies for the owner and raised-by codes it was asked about. Party choices you made for its sheet while reviewing its submissions stay as you left them wherever they name a company it cannot name, and a code its sheet uses only to stamp replies keeps whatever you chose for it.

Undo a merge

A merge can be undone: straight away with Undo this import on its result, or later from Import history (in the ⋯ menu on the Tasks page), which lists every merge into the project with who ran it and what it wrote — to anyone who can close tasks there; everyone else sees only the merges they ran. The person who ran a merge can undo it, and so can anyone who can close tasks on the project (the managing company’s members, project leads and workspace admins). The company that runs the project’s task list can undo its own merges from Merge history on its To-dos.

Undo takes back what that merge wrote, and nothing else:

• Tasks it created are deleted — with the replies, files and tags it gave them.
• Tasks it changed get their old values back: item, detail, due date, priority, raised-by, owner company and list, status. A task it closed is reopened.
• Replies, files and tags it added to tasks that were already there are taken off.
• Progress updates it recorded from the forecast and % columns are taken back: the forecast and % go back to what they were, and a task its % moved to WIP goes back to Open. If someone has reported progress since, the merge’s update stays under theirs, and so does the WIP it started. A task closed or archived since keeps its forecast and %. If a later import has updated the progress too, the task waits: undo that import first, then press Undo on this one again to finish it.
• Companies it created for a party code are deleted, and tags it created go once nothing carries them.
• The column mapping it saved goes back to what it was, and a partner’s submission it merged goes back to Pending merges for review.

Anything somebody has changed since the merge stays as they left it, and the undo tells you each thing it left and why:

• A field someone has changed since keeps their value; the task’s other fields still go back.
• A task the merge created that someone has worked on since — replied to, attached a file, pinned, tagged, edited, reported progress on, linked to a decision or another task — is kept whole.
• A reply the merge wrote that someone has since edited or deleted stays.
• A task the merge created that someone has deleted since stays in the Bin. The undo leaves it alone and says it changed since the merge. So does a task that was deleted and then put back.
• A company or tag still used elsewhere, or renamed, stays.
• A mapping confirmed again, or a submission reviewed again, since the merge stays.

A task the merge took from a company that works through the partner portal goes back to that company only if the company could see it. When the task’s clearance keeps it inside the project team — the company was given a partner space after the merge, say — the task keeps the owner it has now, and the undo says why; its other fields still go back. Nobody can give that owner back, so it does not leave the merge Partly undone. If the task’s clearance is widened later, give it to that company from the task itself.

There is no time limit: the older a merge, the more of it has usually been worked on, and the more the undo leaves alone.

Some things need more access than the person undoing may have: a task they cannot see, reopening a company’s task (closing authority), deleting a company (workspace admin). The undo does the rest and leaves those; the merge then reads Partly undone in the history, and someone with that access can press Undo again to finish it. Reopening an action the merge closed needs no closing authority, just as closing it didn’t.

A task can also change at the very moment the undo is saving it — its clearance is changed just then, say. The undo leaves that task as it is and the merge reads Partly undone. If you can still see the task, the undo says it changed while the undo was saving it: press Undo on the merge in the history again, and the undo reads the task afresh and picks up where it stopped. If the change took the task out of your sight, the undo says you cannot see it, and someone who can finishes it.

Nobody is notified — as with the merge itself — but every task deleted or put back is recorded in its history, and the undo is recorded in the project’s audit trail. Only merges made since undo arrived (September 2026) can be undone; earlier ones kept no record of what they wrote.

What a model is used for

Only the column mapping and the status words: one call per new shape of sheet, on the headers and a handful of rows, audited in the project’s audit trail as the model’s own act, counting towards the workspace’s AI usage. The rows themselves are written from the mapping you confirmed, never from a model’s reading of each cell. A saved mapping means the model is not asked at all.