Tasks

Tasks is the project’s to-do list: the questions and instructions raised at site meetings, each owned by a company (the designer, the contractor, the operator), with a reply thread and files. It is what a project manager used to keep in a spreadsheet, and it is one list everyone updates in place.

Find it under a project’s Tasks entry in the sidebar. Every task is also an action item, so it appears on the Actions register and in the knowledge graph like any other action. In the graph a task is also linked to the company that owns it, the company that raised it, the meeting it was raised at, the decision its close recorded and any drawing it is pinned on, so those connections are there to follow on the Graph page. Ask chat “what is outstanding for STL?” and it answers from the tasks themselves — every one you can see that STL owns or raised.

The Actions register and the knowledge graph decide which tasks you may see exactly as this page does: a task your company owns that sits above your own clearance level is there too, and a task this page hides from you is hidden there as well.

What a task carries

• A number. T-0001, T-0002… issued by ddx PMO when the task is created. If it came from an imported list, the sender’s own reference (A-1) is kept alongside.
• An owner — the company that has to answer or act, shown by its participant code (STL, TRD). A task can also record who raised it. Both pickers offer the companies on the project: your own company (always — it runs the project, so it is on it even before any of your people has been added to the team), the client, delivery partners with a space here, the company that runs the list, anyone whose people hold a role on it, and any company a merged to-do list added — never the whole organisation book, which fills with the classifier’s spellings of the same firm. A company that is not yet on the project is added first, under Team or Partners. Raised by is offered on company tasks only: a person-owned action never shows in a partner’s portal, whoever raised it, so the side panel offers no company to raise one. A raiser already recorded on one (by an import, or over the API) shows there and can be cleared, never set.
• Due date, priority (Urgent / High / Normal / Low) and a status: Open, WIP (being worked on) or Closed.
• A forecast and a % complete — when the work is now expected to finish, and how far along it is, as last reported (see Forecast and % complete). The forecast never moves the due date.
• A thread of replies, each stamped with the person and their company (a reply merged from a spreadsheet shows the sheet’s stamp and company instead), and files (photos, drawing crops) on the task or on a reply.
• Who recorded it, and when — one line at the foot of the side panel: Added by Jane Smith (DDX), Pinned on a drawing by Taro Yamada (MAR), Imported by Jane Smith (DDX) · Design-actions.xlsx · sent by MAR, Found automatically in an email, or Added from an email by Jane Smith (a suggestion someone approved in Intake). The time is when ddx PMO wrote the task down; Raised is when it was raised on the project, which for an email or a workbook row can be earlier. Tasks recorded before this line existed show what could be recovered from the audit trail — sometimes just Added or Imported, with no name.

Lists

A project keeps one or more lists — “General”, “Design”, “Procurement” — shown as tabs above the table. Every task sits on exactly one list; a new project starts with “General”, and so did every existing project when lists arrived (all its tasks went onto “General”, and nothing any partner could see changed).

• Switch with the tabs. The open list is in the page’s address, so a link to “Design” opens Design. Each tab shows how many of its tasks are open.
• New list names one. Rename, Move left / right and the share and archive controls sit in the ⋯ menu on the open tab.
• Share with partners decides which delivery partners see the whole list from their portal — every task on it, whoever owns or raised it. A partner the list is not shared with sees only the tasks its own company owns or raised, or that came from its own to-do list (whoever the merge gave them to), as before. Sharing needs the managing company, a project lead or a workspace admin, because it changes what a partner sees; the boxes are disabled for anyone else. Only delivery partners with a space on the project are offered.
• Move a task to another list from its drawer (List field) — the same people who may share, for the same reason.
• Archive a list once its open tasks are closed or moved (the same people who may share, for the same reason); its tasks stay where they are, any partner it was shared with stops seeing it, and Show archived lists offers Restore. A project keeps at least one list.

New task, Merge a to-do list and a pin on a drawing all land on the list that is open, unless you choose another in the dialog. The one exception is a merged row that names no owner and gets no company in the dialog: it becomes an action, on no list (see Merge a to-do list). Print / PDF (in the ⋯ menu) prints the open list and names it in the heading.

A partner’s own lists

A delivery partner can keep lists of its own, made from its portal (see the partner’s to-dos). Such a list shows on your Tasks page like any other, with a building mark on its tab and Owned by … on hover, and you can do everything to it that you can do to your own: rename it, share it with more partners, move tasks onto or off it, archive it. Its tasks are ordinary tasks — numbered, closed with a note, in the weekly summary. The partner sees every task on its list and runs it; another partner sees it only if it is shared with them.

A partner’s list is never the default. A plain visit to Tasks opens your team’s first list even when a partner’s sorts first, and New task, a pin and a merge land on your team’s first list unless you choose otherwise. Every list picker names a partner’s list as such — “Design — MI’s list (partner)” — because a task moved onto it is seen whole by that partner from then on.

Working the list

The table is the meeting view. The page has three parts, top to bottom:

• The lists and New task. The list tabs on the left; New task (and Pending merges, while a partner’s to-do list waits for review) on the right. On a phone they stay on one line: the tabs scroll sideways, New list is in the list’s ⋯ menu, and Pending merges shows as a merge mark with the count.
• The control bar. Search, then the filters — Status, Priority, Due, Owner, Raised by, Topic, Tag (and Section, where an import brought sections in) — and Include actions. A filter shows its name; once you choose something it shows the choice too and is shaded, so you can see at a glance what is narrowing the list. The ⋯ button at the far right holds the occasional actions: Compact rows, Print / PDF, Task settings, Merge a to-do list and Import history. Under the bar, the count of tasks shown, with Show closed and Clear filters.
• The table. Click a column heading to sort by it, and click again to reverse the order. Every heading except Sheet ref and Last reply sorts: the faint arrows beside a heading show it can be sorted, and the column the list is sorted by shows one dark arrow. Until you choose, the list is in due-date order, soonest first, and the Due heading shows it — click it for the latest first. A first click on another heading sorts numbers and text A to Z, and Priority and Progress most first. Priority sorts by urgency (Urgent, High, Normal, Low), not alphabetically. Owner and Raised by sort as they read: by the company’s code, then — after every company with a code — by name for a company without one.

A filtered or sorted view is a link you can paste into the meeting invite.

Status, Owner, Raised by, Priority, Due and Tag each take several choices at once, and the list shows tasks that match any of them: Owner set to STL and C&B lists both companies’ tasks. Topic and Section take one choice each — a section is where an import’s summary links to.

Status opens a list to tick — Open, WIP, Closed — each with how many tasks choosing it would list. The list opens on Open and WIP (the button reads Status: Open, WIP): closed tasks are hidden until you ask for them, and the count under the filters says how many, for example 24 of 31 tasks · 7 closed hidden, with Show closed to bring them back (your other filters stay). Tick Closed to see the closed tasks too, or untick them all to see every status. Clear filters clears every filter and shows every task on the list — closed ones included; it never goes back to hiding them.

Priority opens a list to tick, Urgent first. Each priority has a mark that shows the urgency (a red square for Urgent; three, two or one bars for High, Normal and Low) and a count: how many tasks of that priority the list holds with your other filters applied. The count only includes tasks you are allowed to see. Tick one or several and the list shows tasks of any priority you chose. Clear removes the choice.

Due finds tasks by their due date, in the same four windows the dates are coloured by: Overdue (red: due before today and still open or WIP — a task closed late is never overdue), Next 7 days (amber: due today or in the seven days after), Later, and No due date. Tick one or several; each shows how many tasks it would list with your other filters applied. “Today” is your own calendar day, where your browser is, so a date shown in red is one Overdue finds.

Topic is a box you type in: click it to see every theme and topic, or type part of a topic’s name, or a theme’s (bath finds every topic under Bathrooms), and pick from what matches — with the mouse, or the arrow keys and Enter. All of Bathrooms filters by the whole theme; Not under a topic finds the tasks nothing has placed yet. The × in the box clears it.

Pin to top. Anyone who can change a task’s priority can pin it. Use the pin beside its number, or Pin to top in its side panel. A pinned task sits above the rest of the list whichever column you sort by. Everyone who can see the list sees it pinned, including partners on their To-dos, and the printed pack marks it Pinned. Unpin it the same way. When a task closes it stops sitting at the top, and it goes back to the top if it is reopened. You cannot pin a closed task.

The Owner and Raised by filters list every company on the project, plus any other company a task names: one that a merged to-do list created, which has no role or partner space here yet, or a partner whose space was revoked. Those are marked not on this project (or archived), so you can still filter to their tasks. Open a filter to tick as many companies as you need; the filter names them. When a filter has more than eight to choose from — companies, or the project’s tags — it opens with a box at the top: type part of a name to narrow the list (what you have ticked stays listed), and press Enter to tick the first match. The pickers for giving out a task still offer only companies on the project. Workload has a chip per company that counts the same open and WIP tasks as this filter, across every list.

• Compact rows (in the ⋯ menu) hides the detail lines and badges so more rows fit on screen — for running a meeting from the list. A tick beside it shows it is on.
• Include actions folds in the person-owned actions from the register (the ones ddx PMO extracts from emails and minutes); by default the list shows company-owned tasks only. Its box is ticked while it is on.
• Print / PDF (in the ⋯ menu) prints the current page as the meeting pack. Use your browser’s Save as PDF; Japanese text prints with the browser’s own fonts.

Writers can change the due date, priority and Open ↔ WIP directly in the row, and pin or unpin it. Click a task’s title to open it: edit the title and detail, change the owner, read and add to the thread, attach or download files.

Some tasks can’t go to every company. A task whose clearance keeps it from partners — one pinned on a drawing kept inside the project team, or read out of a restricted email — can’t be given to a company that works through the partner portal, because that company could never see it. The drawer’s Owner list leaves those companies out and says why. They can still be Raised by. If, at the moment you save, the company you choose is being made a delivery partner on this project — invited, or merged with a company that works here through the partner portal — the change waits a few seconds; if that is still going on, nothing is saved and you are asked to try again.

The same goes for a task that comes back:

• Restoring an archived task that belongs to a company working here through the partner portal is refused when its clearance keeps it from partners. The task stays archived; if the work is still needed, raise it again for a company inside the workspace.
• Deleting a task sends it to the Bin (see Deleting a task), and brings nothing back. The system’s own clean-up is different: removing or re-classifying an inbox item removes the tasks read out of it, and a task one of them replaced or duplicated would come back. When that is a task like this one, it is archived instead, so the clean-up goes on. If one of those tasks, a task it replaced, or the company that owns one is being changed at that very moment, it tries three times, then stops before it finishes and says so; running it again finishes it. A task archived this way can’t be restored while its company still works through the partner portal on the project and its clearance keeps it from partners.
• Re-resolving relations (Re-resolve registers, the nightly clean-up, and the automatic pass after new records arrive) leaves such a task as it was — still superseded, or still a duplicate. Re-resolve registers on the Relationships page names each task it left, and says why.

Forecast and % complete

The due date is the date the project agreed. The forecast is the date the work is now expected to finish, and % complete is how far along it is. The company doing the work reports them — from its portal if it is a delivery partner — and so can anyone who may edit the task here, for example to record what a supplier said on a call.

• In the task’s panel, under Progress: a bar for the %, and the forecast against the due date in words — Forecast 5 Oct 2026 · 4 days after the due date, in red when it is late. Update progress takes a new forecast date, a new %, and a note (optional) saying why. Only what you change is sent.
• Every update is kept. History lists each one, newest first: when, who and for which company, what moved (Forecast 28 Sept → 5 Oct · 4 days after the due date · 20% → 40%) and the note, translated like a reply. Everyone who can see the task sees the history, partners included.
• In the list, the Progress column shows the % and the forecast, with (+4d) when it is after the due date. The print sheet has it too.
• On the Workload board each task’s row shows the forecast and % beside its due date too. My Work does not.
• A % above 0 moves an Open task to WIP — someone is evidently on it.
• 100% does not close a task. It reads Ready to close (a ✓ beside the status in the list) for the people who may close it, who then close it with an outcome note as usual.
• A closed task’s forecast and % are final; reopen it to report again.
• A merged to-do list with forecast or % columns records them the same way, marked from a merged to-do list in the history (see Merge a to-do list).

A delivery partner reports on the tasks its company owns, raised or imported (the task came from its own to-do list), and may reword the title and detail of the ones it raised or imported. The due date, owner and status stay with whoever runs the list.

When an update moves the forecast later and it now falls after the due date, whoever runs the list is told (see Who gets told). Other updates tell nobody; the weekly summary lists every open task whose forecast is after its due date.

Deleting a task

Delete is for mistakes, such as a task raised twice or read out of an email by error. Archive is for finished work you keep for the record, and it hasn’t changed.

A deleted task goes to the Bin. Nothing is destroyed:

• Only your workspace’s admins can see the Bin, and only they can put a task back. It stays there until they do.
• To everyone else the task is gone: the Tasks page, My Work, Workload, the partner portal, chat, search, reports, reminders and notices. Admins don’t see it there either. Nobody is told that it was deleted.
• Its older versions and the copies merged into it go with it, so its text doesn’t stay visible through them. So do its replies, files, pins and tags. Its files’ text leaves search and chat too. The records the system drew from its files stay.

Anyone who can archive a task can delete it: deleting asks the same permission, Project settings → write. There is no separate permission for deleting tasks. If the task has copies you can’t see, the delete is refused, and a workspace admin can delete it. Partners can’t delete tasks.

Deleting a task in chat works the same way: the task goes to the Bin, and chat’s Undo doesn’t apply to it.

Removing an item from the inbox (Intake → Remove), or re-classifying it, is different: a task read only out of that item is removed for good, even if someone has worked on it since. A task from that item that is already in the Bin stays there.

Closing a task

Closing is deliberate. A company-owned task closes only through Close…, which asks for an outcome note — what was decided or done. The note is stored on the task, written to the audit log with your name, and shown as the task’s outcome.

Decisions. Some outcomes are decisions — a choice the project will live by, such as keeping the bath apron where it is — and some are plain closes: contact details handed over, a drawing received, work confirmed done. As you write the note, the close dialog asks an AI model which it reads as, shows its answer — and, when it reads as a decision, the words it relied on — and pre-ticks Record in the Decision Log accordingly. You can tick or untick it either way; your choice is what counts. When it is ticked, closing writes a decision to the project’s Decision Log with the note as its text, word for word, pointing back at the task; the task shows Recorded in the Decision Log, and the decision carries the task’s clearance level and compartment (a partner that can see the task reads the decision on its portal’s Decisions page). Reopening the task withdraws the decision (it is archived and marked Withdrawn, never deleted). The model’s answer counts towards the workspace’s AI usage and is logged in the audit trail as the model’s own act; if the model cannot answer — the AI allowance used up, or the model unavailable — the dialog says so and the box stays unticked. A merged to-do list never records decisions on its own — its closed rows can be reopened and closed again by hand where one is wanted.

Who may close is set per project under Task settings — in the ⋯ menu, under Print / PDF — as Who runs this list: one company for the whole project (on RCT, the project manager), covering every list the project team keeps. Its people with write access, project leads (project managers and co-managers) and workspace admins can close and reopen tasks, change a task’s owner, move a task to another list, and share, archive or restore a list. Everyone else with write access can raise tasks, edit a task’s title, detail, due date and priority, move it between Open and WIP, reply and attach, and make, rename and reorder lists. Person-owned actions keep their existing rule — the assignee or any writer can complete them.

The managing company’s people are wherever that company’s people are on the project. If the manager is your own company or another consultancy whose staff are workspace members, they are the member rows under that company in Settings → Team, and they work from this page. If the manager is a delivery partner — a company that works from the supplier portal, as a project manager appointed by the client usually is — its people are the members of its partner space, and they run the list from the portal’s To-dos tab: they see every company-owned task on the project team’s lists (under the same clearance ceiling as anything else a partner sees), raise tasks, change owner, due date and priority, close with an outcome note (and the Decision Log box), and reopen — never on a list another partner made for itself, which stays that partner’s. Nobody from that company needs to be added to your workspace. Your own team keeps this page as it is; closing here stays with project leads and workspace admins.

A new project starts with Who runs this list set to your own company — the PMO runs the list — so closing works from day one. Task settings is for anyone who can edit the project’s settings (by default a project manager, co-manager or client lead, or a workspace admin): they can change it to any company on the project in the same dialog, or set it back to Leads only. Nothing changes until Save, and Save sends only what you changed there. A company can be named before its people have joined: the dialog then says nobody from it is on the project yet, the ⋯ button and Task settings inside it carry an amber dot saying the same, and closing stays with the leads until it has people — member rows under Settings → Team for your own or another consultancy’s staff, or a delivery-partner space for a company that works from the portal (see Delivery partners). Because a company runs the list, the weekly summary also runs from the first week (Monday 08:00 in the project’s timezone unless changed) and goes to that company’s people on the project; change the day and hour in Task settings, or set Leads only to stop it. Anyone whose role on the project sits under the managing company and carries action_items:write can close — by default the client lead, project manager and co-manager roles; a consultant, finance, viewer or client viewer role under it cannot.

Tasks your company owns also appear on your My work page with the company’s chip; the chip opens the task here.

Chat and the Claude connector see the same tasks this page shows you — including the tasks your company owns that sit above your own clearance level — and no others.

Merging an existing to-do list

Merge a to-do list on the Tasks page brings a spreadsheet’s rows in as tasks — uploaded, or picked from the project’s Files — and a partner can send its own list from the portal for the managing company to review under Pending merges. When the company that runs the list is a delivery partner, its editors merge their own list themselves from the portal, onto a list they run and within what their portal shows them; it appears here like any other merge. Columns are mapped once (an AI model suggests a mapping for a shape it has not seen; you confirm), parties are matched to companies, likely duplicates are flagged, and the confirmed mapping is remembered for the next revision. The full walk-through is on Merge a to-do list.

Pins on drawings

A task can be raised at a spot on a drawing. Open a PDF or an image from Files (Preview), turn on Drop a pin in the viewer’s toolbar and click the page where the task belongs (an image is one page). The pin dialog opens with the drawing, revision and page already filled in:

• Instruction — what you would have written on a marked-up print. It becomes the first reply in the task’s thread.
• Item, Area and Detail — proposed from the instruction by an AI model a moment after you stop typing (the hint says Suggested from the instruction — check before saving). Edit anything; a field you have already typed in is never overwritten. When the model is not available the item takes the instruction’s first sentence.
• Owner (company) — the company that originated the drawing, by default: a pin on the designer’s sheet is the designer’s task. Raised by defaults to your own company. Change either before saving.

A pinned task gets the drawing’s clearance. When that clearance keeps the drawing from partners — a level above the partner-visible bands, or a compartment — a company that works through the partner portal could never see the task, so it cannot own it. The dialog says so, leaves those companies out of Owner (they can still be Raised by), and starts the owner at your own company instead of the drawing’s originator. To give the task to one of them, change the drawing’s clearance first.

The pin gets a number (pin 7 on the L8 wet-areas sheet) that is never reused on that document, and it shows on the page as a numbered marker coloured by the task’s status. Click a marker to see the task’s number, name and state; Open task then opens the task’s full drawer beside the drawing — the same drawer as on the Tasks page, thread, files, owner, due date and Close included — so the spot the pin points at stays in view while you read or work the task. Open in Tasks, at the top of that panel, is the way to the list when you want it. The task’s drawer shows On drawing with the drawing, revision, page and pin, a small picture of the pinned page with the marker on it, and Open at pin takes you back to the spot. On the Tasks page a pinned task carries a small 📍 P02 p.3 badge. (The picture is in the drawer rather than on the list on purpose: it is drawn from the drawing itself, which can be tens of megabytes, so it is fetched once you have opened the task, not forty times for forty rows.)

When a new revision is uploaded

A pin belongs to the revision it was made on. When a newer revision is uploaded the pin reads on superseded revision: Open at pin opens that older revision so the marker is where it was. Nothing moves on its own — a re-issued sheet may have moved the very thing the pin points at.

Open the drawing’s current revision in the preview and, if open tasks still have their pin on an older one, a strip across the top says so (3 open pins sit on a superseded revision) with Carry forward…. The dialog lists them, all ticked; untick any that no longer mean what they meant, and confirm. Each carried pin is re-anchored at the same spot on the current revision and keeps its number; the older marker stays on the older revision as the record of where it was, and the task’s drawer marks the new one carried forward. Closed tasks are never offered — their pins stay where they were made. Carrying forward needs the same access as dropping a pin, and is the project team’s act: partners see on superseded revision but cannot carry.

From the partner portal

A delivery partner can pin a drawing it holds, from the portal’s Files (see Supplier portal). The task it raises is owned by the company that originated the drawing and raised by the partner’s company — the trade contractor pinning the architect’s sheet makes an architect’s task raised by the trade contractor — so the partner’s dialog shows the two companies as a line rather than pickers. The task appears on the project’s Tasks page like any other, with the pin, and on the partner’s own To-dos (their company raised it). In the portal, as here, Open task on a pin opens the task beside the drawing. A partner’s editor can put the pin’s task on a list their company runs — its own list, or one of the project’s while it manages the task list; without a choice it goes on the project’s first list, as before.

A partner cannot pin a drawing whose clearance keeps it from partners — which can happen for its own upload, since a partner always sees what it uploaded, or for a drawing re-classed after it was shared. The task would take that clearance and never appear in the partner’s To-dos, so Drop a pin is switched off and says why; the project team can raise the task instead.

Pins go on the current revision, on PDFs and images, and need write access to tasks; a drawing you cannot open in Files cannot be pinned. A task pinned on such a drawing shows only the page and the pin number (📍 p.3 on the Tasks page): not the drawing’s name, not its revision, not whether a newer revision replaced it, and no link or picture. A pin carried onto later revisions of that drawing shows once. A drawing waiting on the deletions queue keeps its revision but not its name or link, because nothing opens on one. Pin numbers can have gaps: a number belongs to a task you may not be able to see.

Replies and files

Anyone with write access can reply. You can edit or delete your own replies; deleting asks for a reason and leaves a marker in the thread, never a silent gap. Every download is recorded. Removing a file is permanent, so it asks first.

Chat can find and quote replies. Ask “what did Strickland say about the bath apron?” and chat searches the replies on every task, quotes the one that answers, and lists it under Sources; clicking that source opens the task with the reply highlighted. Three things to know:

• A reply is exactly as visible as its task. Chat never shows a reply to someone who cannot see the task it sits on — the same in the Claude connector. Restrict a task and its replies are restricted with it, at once.
• A deleted reply leaves chat straight away, and an edited reply is searched by what it says now, not what it used to say.
• Searching by words works straight away, including on old threads. Matching by MEANING — a question worded differently from the reply — needs the reply to be read into the search index first. That happens as each reply is written; replies from before this arrived are filled in by a background sweep that runs every six hours and works through a limited number each time, so a long thread history can take a few passes.

A document you attach is project knowledge, the same as a file you upload through Intake → Import: within a minute or so it appears under Intake → Attachments, the classifier reads it, and chat can answer questions about it. The file’s row in the drawer gains an In knowledge link to its Intake page, and that page names the task it came from. Three things to know:

• Only document types are read — PDF, Word, PowerPoint, Excel and Markdown, the same set Intake → Import accepts. A photo, a video or an archive stays a download on the task and never gets an In knowledge link.
• The file inherits the task’s confidentiality. A file on a task only three named people can see is readable by those three, nowhere else; a file on an ordinary task is readable by everyone who can read the project’s inbox. Restricting a task after attaching a file does not move the file — remove it and attach it again.
• Removing the file from the task removes it from knowledge too, along with anything the classifier drew from it. Deleting a task takes its files to the Bin with it: their text leaves search and chat, and what the classifier drew from them stays. Removing the item from the inbox instead (Intake → Remove) is permanent: the file stays on the task as a download and is never read again.
• A file that was not read is picked up later. The read happens in the background, and if it could not even be queued (a hiccup in the queue at the moment you attached it) the file is still attached — a sweep every six hours finds every operator file with no In knowledge link and reads it, retries any read that failed, and finishes any removal that did not go through. If a file has no In knowledge link a day later, ask an administrator: the sweep reports on the workspace’s Activity page as Task file sweep.

A file a partner uploads from its portal is different: it stays download-only and is never read into knowledge, because partner files are not trusted material — see The partner’s to-dos.

Once a task is closed, its thread and files are the record of how it was closed: you can still add a reply or attach a file (the drawer says the task is closed), but nothing already there can be edited or removed — by anyone, partners included; the portal hides those controls on a closed to-do. Reopen the task to change the record.

Delivery partners answer in the same thread from their portal: a partner’s reply shows the person’s name and company and is marked partner. A partner’s editor can also mark an item its company owns as WIP. Closing stays with the company that runs the task’s list: a partner closes only on a list it made for itself, or on the project team’s lists when it is the company named under Who runs this list — see The partner’s to-dos.

Asking another company in a reply

A reply can ask a company for an answer, even when the task belongs to someone else. Type @ in the reply box (or press the @ button beside Reply) and pick the company: @C&B, can you confirm the ceiling height? The company you pick sits as a chip above the box (Asking @C&B, with × to take it off again); you can ask more than one.

When you send it:

• Everyone at that company who can see the task is told — by email and, for your own team, in the in-app feed — that they were asked. The owning company and the company that raised the task still hear about the reply as usual; anyone who was asked gets only the “you were asked” notice, not both.
• The reply waits for their answer. It shows Asked @C&B · waiting for an answer in the thread, the task shows ⏳ on the Tasks page (hover it for who is still to answer), and on the company’s own To-dos in the partner portal the task reads Your answer needed.
• It stops waiting as soon as anyone from that company replies on the task — the reply then reads @C&B · answered. Deleting the reply that asked withdraws the question, and a closed task waits for nobody (reopen it and it waits again). A reply from a spreadsheet merge counts as that company’s answer too, when the sheet credits the reply to them and it is dated after the question.

You can only ask a company that can already see the task — the owner, the company that raised it, a company the task’s list is shared with, the company that runs the list, and your own team — and only when someone there would actually be shown it. Anyone else is not offered, and asking never shows a task to a company that could not see it before. If the question is for a company that cannot see the task, share its list with them or change the owner first; the list says No other company can see this task when there is nobody to ask. You cannot ask your own company.

What is asked is fixed when you send it: editing a reply changes its words, not the companies it asked. Only companies can be asked, not a named person.

Comments pinned on a task’s files

A photo or a PDF attached to a task opens in the same viewer as a drawing in Files: press Preview beside it (a Word or Excel file stays a download). To comment on a spot — the crack starts here, move this outlet — turn on Drop a pin, click the spot, write in the box that opens beside the file and press Post comment.

• The comment is a reply. It goes into the task’s thread like any reply, is told to the same people, and can @ask a company too. Under it the thread says where it is — Pin 3 on plan.pdf, page 2 — and Open at pin opens the file on that spot. The emails and alerts about it say the same.
• Pins are numbered per file — 1, 2, 3 — and a number is never reused. The panel beside the file lists every comment pinned to it; click one to jump to its pin.
• Who can pin: anyone who can reply on the task, and partners on the to-dos they can see in their portal — on any file of the task, yours included.
• Removing a pinned file warns you how many comments are pinned to it. The comments stay in the thread and say Pinned on a file that has since been removed. Deleting a comment takes its pin off the file.
• Undoing a to-do list merge leaves a file the merge attached if someone has pinned a comment to it since — it is listed as worked on since.

Who gets told

Notices go to companies, not to a named person: everyone at the company on the project — your colleagues holding a role under it, and the company’s partner members in their portal — by email and, for your own team, in the in-app feed. Each reader’s link lands where they work: the Tasks page for an operator, the To-dos tab for a partner.

When	Who hears
A task is given to a company, or moved to another	The company now responsible
Someone replies	The owning company, the company that raised it and the company whose to-do list it came from, except the author and anyone the reply asked (they get the notice below instead) — on a person-owned action, only the raising company’s people in your workspace
A reply asks a company (@)	Everyone at each company asked who can see the task, except the author
A task is due within seven days	The owning company, once per task and due date
A task passes its due date	The owning company and the managing company, once per task and due date, in the week after it fell due; the weekly summary keeps repeating it
A progress update moves a task’s forecast later, past its due date	Whoever runs the task’s list — the managing company (the company that made the list, for a partner’s own list; the project leads when no company runs it) — except the person who sent it. One notice per update, with the new and the old forecast and the note
Once a week	The managing company gets a summary: everything overdue and due this week, every open task forecast to finish after its due date, and what was recorded, replied to and closed in the seven days before — on the weekday set in Task settings, at the reminder hour, in the project’s timezone (UTC if none is set)

Every notice names the list its task sits on, and each line of the weekly summary names the task’s company and its list.

You are only told about tasks you can see. Your own team hear about a task when they could open it on the Tasks page, so a task kept inside the project team — for example one raised on a drawing in an internal folder — is announced to the people on your side who can open it, and never on the partner portal.

A company’s people on the partner portal are told only about the tasks their To-dos show them. No company’s portal people hear of a person-owned action, whoever raised it: it is on no partner’s To-dos. For the managing company it matters too: its portal people never hear of a task on a list another partner made for itself (and has not shared with it) unless their company owns or raised it, or it came from their to-do list — they are left out of those notices, and those tasks out of their weekly summary, as the tasks are left off their To-dos.

The weekly summary follows the same rules: each reader’s copy leaves out the tasks they cannot see, and anyone who can see none of the week’s tasks gets no summary.

Merging a to-do list is quiet on purpose: the rows it creates show up in the next weekly summary’s “new” section (they count from when they were recorded, not from the meeting date in the sheet) rather than as one email per row. A project admin can switch any of these off for the project under Settings → Notifications. Everyone can also make their own choices: your own team under their notification settings, a partner on the Settings tab of the portal’s notifications. The reminders and the weekly summary can be turned off entirely; the assignment, reply, @mention and forecast-past-due emails can be turned off by email only — they still appear in the app (or the partner’s portal), so nobody who wants a quieter inbox stops being told. Those emails end with a link to where that switch is. The unsubscribe link at the bottom of a reminder still turns off every reminder-type email to that address. Nothing is sent when there is nothing to say.

Language

Everyone reads the task list in their own language — English, Japanese or Korean — and writes in whichever they like.

• Your language is set from the account menu (Read in 日本語, Read in 한국어, Read in English — one entry for each language you are not reading). It changes the words of the Tasks page, the drawer, the To-dos tab on the partner portal, the dates, and the task emails you receive; it is remembered on your account, so every device follows.
• Working languages are set in Task settings on the Tasks page by anyone who can edit the project’s settings: tick the languages the project’s people write and read in (a Korean client’s project: English and Korean; RCT: English and Japanese). A new project starts with English only. Every task title, description and reply is translated into each ticked language in the background within moments of being written, so a reader in one of them rarely waits. A reader whose language is not one of them is served on first read, with a Translating… marker until the translation lands; if it has not arrived after three minutes the page shows the words as written.
• Translations are produced by an AI model (Claude) and count towards the workspace’s AI usage. At the monthly ceiling, texts show as written until it resets.
• The original is the record. A translated text shows Translated · Show original beside it; one click shows the words as written, which is where product codes, drawing references and exact wording live. Nothing is ever written over the original: translations are kept separately, keyed by the text itself, so the same reply translates once and an edit simply translates again.
• What is not translated: operator notes, closing notes, the merged workbook itself, file names and attachments, and the task titles and reply excerpts quoted inside a task email or the weekly summary (a notice goes out the moment something is written, before its translation exists; the words of the email itself follow your language). The rest of the operator app — Files, Documents, settings — stays English for now. The one exception is the file preview (the window a file opens in, on Files and on a task), which follows your language.