The delivery portal (what partners see)

When you invite a delivery partner or a tender bidder, they land in the portal — a separate, isolated sign-in from the main app. This page describes what they see, so you know what you’re offering and can answer their questions. It doubles as help you can point partners at.

Signing in and the engagement list

The partner claims their invite link, signs in, and sees their engagements — every space they hold with you, across projects, as a list. Each row shows who it’s with and what stage it’s at; with many engagements, a search box filters by title or client, and stage chips narrow the list. This is the portal’s home; the person’s name and email sit top-right, and nothing about your projects leaks beyond the spaces you granted.

A few conveniences worth knowing:

Invitations can be accepted in-app. If someone signs in and has a pending invitation on their email address, the portal home lists it with an Accept invitation button — no need to dig the emailed link back out.
One email can wear both hats. The same address can be a workspace member on one project and a delivery partner on another; sign-in routes to the right surface either way.
A link to a folder or file opens where the reader holds it. Whether it came in one of our emails, was copied from your own Files page, or was forwarded by another partner, it survives signing in first and opens the folder or file in the reader’s own space when they hold it. When they don’t, the portal says so in plain words — the link works, it just points at something not shared with them — rather than showing an error.
A partner’s link works for your team too. A workspace member who opens a link a partner copied from the portal lands on the same folder on the project’s Files page. If they belong to several workspaces and are in a different one, they’re switched to the workspace the link belongs to (when they can open that project there), and a notice says which.

What each person can do inside a space depends on their member role — viewer, uploader or editor; see People at the partner.

Notifications: the bell and the hub

A bell in the portal’s header shows how many alerts the partner has not read, on every portal page. It opens Notifications, one page across every project they work on with you (and anyone else), with three tabs:

Alerts — every notice you send them also lands here: a file issued or shared, a new revision, a withdrawal, a transmittal, a task given to their company, a reply. (Not the invitation itself. And someone who is also on your own team is told in the workspace’s notifications instead.) Each opens exactly where its email pointed — the file, the task, the transmittal — and opening one marks it read. A filter narrows the list to one project. Alerts start from the day the hub was switched on; anything older is under Emails. An alert keeps saying what its email said: if a task later moves to another company, the alert stays, but its link opens a page that no longer shows it.
Emails — every email we have sent them about their projects, newest first, with what became of it: sending, sent, bounced (their mail server refused it) or not delivered. They can open each one’s text. The invitation email is listed without a copy, because it carried a sign-in link we do not keep.
Settings — the address we write to and whether it is working. If it is bouncing, or they unsubscribed from a reminder’s footer, it says so (an unsubscribe can be undone here; a bounce is cleared by the DDX team, so the page asks them to check the address with you, and you raise it with DDX support if it is right). Below, every kind of notice they can receive, with a switch only where the switch is theirs: the task reminders and weekly summary (by email or here), and the task assignment and reply emails (by email only — the alert here stays, unless you turn the notice off for the whole project). The rest carry something they need to know, and the page says the project team decides those.

A partner stops seeing a project’s alerts and emails here once you remove them from it — the portal shows them nothing about a space they no longer hold. Their own inbox still has what was sent.

Inside an engagement

Choosing an engagement opens it with a left sidebar, mirroring the main app: pick a context, get its sections. An engagement switcher at the top jumps between spaces without going back to the list.

The sections depend on what kind of engagement it is:

A file exchange (a standing delivery partner):

Brief — what the engagement is, when you’ve written one.
To-dos — the project’s tasks their company owns or raised, and every task on a list shared with it or made by it, with the same reply thread your team sees. This is where a delivery partner lands. See The partner’s to-dos.
Decisions — the decisions recorded by closing those to-dos. See Decisions.
Files — the same file browser you use, over their granted folders (see What partners get in Files). They upload here and download what you’ve issued.
Transmittals — the numbered issues you’ve sent them, each with its documents and an Acknowledge receipt button; and, for an editor, the transmittals they have issued to you.
Company details — their legal name, registered address and key contacts.

A tender bid (a supplier bidding for work):

Documents — the checklist of what you asked for, each row with the reference file to download and a slot to upload their response. A sticky Submit bar tracks how many required items are staged; nothing reaches your team until they press Submit.
Questions — a clarification Q&A. Bidders never see each other or each other’s questions.
Company details — as above.

What a partner can and can’t see

Reassurances worth giving partners, all enforced by the platform:

They see only the folders you granted — the rest of your tree doesn’t exist for them. The one exception is names on the way down: the parent folders above a granted one show as greyed, context-only waypoints (no files, no uploads), so a partner working in several packages can tell same-named folders apart.
Their uploads stay private to them (WIP) until they choose to issue them to you.
On a tender, bidders are invisible to one another — no bidder list, no shared questions, no hint of who else was invited.
Everything is branded as your client, not ddx (unless you turned that off for the engagement).

What partners get in Files

The portal’s Files page is the same components as your own, gated by the partner’s role rather than reimplemented — so the two stay in step. That means a partner gets:

The folder tree with carets, resizable and scrolling independently of the file list, and Back/Forward through the folders they’ve visited.
Click a file for the details drawer, plus right-click / ⋮ menus on documents and folders.
Preview in place, the “3 versions” chip, and the full version history — open, download, restore, and reorder revisions — with the version switcher for comparing one revision against the last. See Versions and revisions.
Upload confirmations naming what landed, the same as on your side.
Who can see this folder — a line under every folder’s breadcrumb: you, the other delivery partners the project team has let in, and the project team. Only partners who have joined are named, only for folders inside the partner’s own slice, and never more than the company name — not their people, not their other folders, not their files. Someone who can upload is also told that a file stays private to them and the project team until they issue it, and the Issue section of a file repeats who it will reach. Folders shared with another partner show the names on their row and a people badge in the tree.
Pins on drawings — the same page viewer and pin markers as your Files page. A partner sees the pins whose task is on its To-dos, and an uploader or editor can drop one on a PDF or image it holds: the task it raises is owned by the company that originated the drawing and raised by the partner (the trade contractor pinning the architect’s sheet makes an architect’s task raised by the trade contractor), so the pin dialog shows the two companies as a line rather than pickers. A drawing whose clearance keeps it from partners cannot be pinned from the portal (the task would never reach the partner’s To-dos), and Drop a pin says so. Carrying pins onto a new revision is your team’s act; a partner’s marker simply reads on a superseded revision. See Pins on drawings.

What their role gates (viewer, uploader or editor):

Create subfolders — uploader and editor, right-click a folder or the empty space inside one, and only inside folders you have shared with them.
Delete — an editor may delete its own un-issued files, from the drawer or the file’s right-click / ⋮ menu (Delete…, the last item). Once a file has been issued or shared it is part of the project record and delete is refused. Their deletes are soft: the file goes to your pending-deletions queue, never straight to erasure, so you can put it back.

Uploading, from their side

A partner uploads by dropping files (or a whole folder — its contents upload into the open folder, flattened, with a notice) or using the upload button in a folder. A file whose name follows the project convention becomes a controlled document; anything else becomes a descriptive draft. Big files stream in chunks with a progress bar, exactly as on your side. Anything an upload wants to flag — a name that doesn’t follow the convention, a folder flattened on the way in — shows in an amber box above the file list: one line per kind of problem, with a count when it applies to several files. Clear at the box’s right closes it (it’s a button, so Tab reaches it too); it also clears on its own when they open another folder or upload again. When they’re ready to hand a controlled document over, they issue it — and that’s the moment it appears on your Files page, badged from partner.

If they hand over the wrong thing, an editor can de-issue their own document from the drawer — back to WIP, with a mandatory reason that reaches whoever was told it arrived. The same rules apply as on your side: once the file has been shared onward or pinned to a transmittal, de-issue is refused, and the hand-over stays on the audit trail either way. See Taking something back off issue. They can only ever de-issue their own uploads — never anything of yours.

Transmitting back to you

ISO 19650 expects formal issue in both directions: you transmit to the appointed party, and the appointed party transmits its deliverables into the CDE. An editor on a delivery space can pick their own issued documents, add a subject and an acknowledge by date, and issue a numbered transmittal to the project team.

It uses the same TX numbering, the same register and the same void rules as yours. On your side it lands in the Inbox on the Transmittals page — see transmittals from partners.

Deliberately narrow: a partner can only transmit documents it owns, and every transmittal it issues reaches the project team. It can address another delivery partner as well only where you have allowed it — May transmit to, under the partner’s access on the Partners page — so the recipients it is offered are only the partners you named for it.

The partner’s to-dos

A delivery partner opens on To-dos: the project’s company tasks its company owns or raised, the ones that came from its own to-do list (a list it sent, merged in by your team or by itself — whoever the task went to), and every task on a list shared with it or made by it (see Lists below), due date first, showing what is outstanding (Open and WIP). A person-owned action — a task with no owning company — never shows in a partner’s portal, whoever raised it: a Raised by recorded on one says where it came from, and shares nothing. Whatever is shown is listed in full, 100 to a page, with Previous / Next above and below the table.

Filters. Above the table are the filters your Tasks page has: a search (by number, or by words in the title or description as they were written — a reader who sees a task in translation searches the original’s words), the Status chips (Open, WIP, Closed), Owner, Raised by and the priority chips (see Priority and pins below), all in one bar. Each but the search takes several choices at once, and the list shows to-dos that match any of them. The Owner and Raised-by filters offer only companies the partner already sees in its portal — the ones its to-dos name, the ones on the lists it is on, the client and the managing company — never the rest of the project; the managing company is offered every company on the project, as its New task form already is. The list opens on Open and WIP, and the bar says how many closed to-dos that hides, with Show closed to bring them back (the other filters stay); once a filter is chosen, Clear filters shows every to-do on the list tab that is open (closed ones included). The filters, the list tab and the to-do open beside the list are in the page’s address, so a filtered view is a link another member of the company can open; closing the to-do takes it out. On a screen wide and tall enough the bar stays under the header while the table scrolls.

The list opens due date first (undated tasks last); Due turns it to latest first and back, and Status sorts it (a second click reverses, a third goes back to due date first). Opening one shows the item, who raised it, the due date, the outcome once it is closed, and the same reply thread and files your team works in on the Tasks page — a partner’s reply appears there stamped with the person’s name and company and marked partner. The foot of the item says who recorded it and when — Added by Jane Smith (DDX), Imported by Taro Yamada (MAR), Recorded automatically. Your team is named there by name and company only: never an email address, the file a list was imported from, or the email a task was found in.

Print / PDF. Any member can print the to-dos on the page shown, as filtered — or save them as a PDF from the browser’s print dialog. The sheet is headed with the client, the space, the company and the list, says which filters it shows and when it was printed, and lists each to-do in the reader’s language with its companies (by code), the number its sheet gave it (the company’s own or your team’s, when any to-do printed has one), due date, the progress reported, priority, status and last reply, and the outcome of a closed one. Only the page shown prints: turn to the next page to print that one, as on your Tasks page.

What a partner can do depends on their role on the engagement, and on whose list the task is on:

Any member reads the list, the threads and the Decisions page, and downloads files.
An uploader or editor replies and attaches files. While the to-do is open they can edit or delete their own replies (deleting asks for a reason) and remove their own files (permanently, after a confirmation). They can also drop a pin on a drawing they hold in Files, which raises a task (see above), and send the company’s own to-do list for your team to merge (see below). An editor can also choose which list the pin’s task goes on, among the lists their company runs (its own, and the project’s lists when it is the managing company); otherwise it goes on the project’s list, as always.
An uploader or editor can ask another company in a reply: typing @ lists the companies that can already see the to-do (of those the portal already shows them), and the company picked is told and the reply waits for its answer — see Asking another company in a reply. When a reply asks their company, the to-do reads Your answer needed on their To-dos until someone from the company replies on it.
An uploader or editor can open a photo or PDF on a to-do in the preview and pin a comment to a spot on it, on any file of the to-do, your team’s included. The comment is a reply in the same thread — see Comments pinned on a task’s files.
An editor can press Start work (mark WIP) on an item their company owns — “we are on it” — which your team sees on the Tasks page.
An editor reports progress on a to-do their company owns, raised or imported (it came from their own to-do list): a forecast date — when they now expect to finish — and a % complete, with an optional note. The due date does not move; the gap between it and the forecast shows as slippage, and every update is kept with who sent it and when, in a History everyone who can see the to-do can read. A % above 0 moves an Open to-do to WIP. When a forecast moves past the due date, the company that runs the list is told. See Forecast and % complete.
On a to-do their company raised or imported, an editor can also Edit wording — the title and detail, nothing else.
On a list their company runs — one it made for itself (see A partner’s own lists below), or the project team’s lists when it is the managing company (see When the partner IS the managing company) — an editor also gets the controls for running it: New task, Edit task, Mark WIP / Back to Open, Close… with an outcome note, and Reopen.

On any other list, a partner cannot close an item, reopen one, or change its owner, due date or priority, or reword a to-do it neither raised nor imported, however senior. That stays with the company that runs the list (see Closing a task). Nobody in the portal can delete a task, or touch another person’s reply or the files under it. Every partner reply, edit, file and download is on the audit trail as an external actor.

Lists. When the project keeps its tasks as several lists, the To-dos tab shows a strip of them — All lists, then one tab per list the partner may see — and each row carries its list as a chip. A list the operator has shared with the partner’s company shows every task on it, whoever owns or raised it (the tab says so on hover); any other list shows only the tasks the partner’s company owns, raised or brought in from its own to-do list. Sharing and un-sharing take effect on the partner’s next request; an archived list drops out of the strip.

Priority and pins. Each row shows its priority. Above the table there is a chip for each priority, Urgent first, with how many of the view’s to-dos have it. Choosing chips narrows the list to those priorities. A to-do pinned to the top by your team, or by a company that runs the list, sits above the rest, marked with a pin. A partner editor can pin and unpin to-dos only on lists its company runs.

A partner’s own lists. An editor can make lists for their company with New list — “Design coordination”, “Snags” — and tick the partners it is shared with. On its own list the company sees every task and runs it: New task (the owner picked from the companies it already works with here — the ones on its tasks and lists, the client and the managing company — never the whole project), Edit, Close… with a note, Reopen, Pin to top, and the list’s own ⋯ menu on its tab (rename or share, archive once its open tasks are closed, restore from Show archived lists). Your team sees every partner list on the Tasks page, always, and can share or archive it too. A partner the list is not shared with — the managing company included — sees nothing on it beyond the tasks its own company owns, raised or brought in from its own to-do list. A partner can share a list only with partners it already sees here; to open it to anyone else, share it from the Tasks page.

When the partner IS the managing company

A delivery partner can be the company that runs the project’s task list — a project manager appointed by the client, say, whose people all work from the portal. Name it under Who runs this list in your Tasks page’s Task settings (it is offered like any other company on the project) and its To-dos tab becomes the manager’s list:

Every member of its space sees every company-owned task on the project team’s lists, and every one on no list, not only its own company’s, under the same clearance ceiling as before (managing the list is not a clearance level). A list another partner made for itself stays that partner’s: the manager sees it only if it is shared with the manager, or for the tasks the manager’s company owns, raised or brought in from its own to-do list. The summary line names all of these and says the company manages the list, and Only ours narrows back to the company’s own items (it is the Owner filter set to the company itself, and nothing else).
An editor there gets the manager’s controls: New task (owner from the companies on the project, its own company as raiser by default, due date, priority), Edit task, Pin to top, Mark WIP / Back to Open, Close… with the outcome note and the Record in the Decision Log box, and Reopen (which withdraws the decision, as on your side). A viewer or uploader there reads the whole list and gets none of them.
The weekly summary and the overdue notices that go to the managing company reach these people, at their portal addresses — about the tasks their To-dos show them: never one on another partner’s own list that is not shared with them, nor a person-owned action. Every task notice names the task’s list.

Every one of these writes is refused to any company that does not manage the list — the check is the project’s setting, read on each request, so handing the list to another company takes effect on the partner’s next click — and each is on the audit trail as the company, an external actor. Nobody from the managing partner is added to your workspace for this. Deleting a task, and anything person-owned, stays on your side.

Decisions

A delivery space also has a Decisions page: the project’s Decision Log as the partner may read it. It lists the to-dos the partner’s company can see on its To-dos — the managing partner’s whole list, or an ordinary partner’s own, shared and raised tasks — whose close was recorded as a decision, newest first: the day each was closed, the outcome in the words the close wrote (the to-do’s own closing note), and the to-do, which opens on To-dos. It is read-only: a decision is recorded by closing its to-do with Record in the Decision Log ticked, and withdrawn by reopening it. A search looks only at what the page shows — the to-do’s number and title and the outcome.

The page shows the to-do’s words, never the Decision Log’s row: whatever your team edits on a recorded decision — its title, text or date — stays on your side. A to-do leaves the page when its decision no longer stands as it was recorded: withdrawn, archived, superseded or folded into another, given another status (proposed, rejected), or raised above the third-party clearance ceiling. The outcome note itself stays on the to-do. Decisions that were not recorded by closing a task — extracted from correspondence or entered by hand — are never shown. Every member of the space can read it; a bid has none.

A to-do raised at a pin shows Pinned on a drawing · rev P02 · page 3 · pin 4 in its drawer, with Open the drawing, which opens that document in the partner’s Files. The drawing’s name itself is not shown there — the partner reaches the drawing through Files, where what they may see is decided. A pin on a drawing their Files does not show them reads Pinned on a drawing you cannot open · page 3 · pin 4, with no revision and no link: a drawing never issued to them, in a folder they were not given, one whose access has ended (a grant run out, a folder taken away), one whose clearance keeps it from partners, or one that was deleted. The other way round, clicking a pin on a drawing in Files and then Open task opens the to-do beside the drawing — the same drawer as on To-dos, reply box, files and (for a list the company runs) the manager’s controls included — with Open in To-dos to go to the list. Switching to another revision of the drawing keeps the to-do open beside it.

Worth telling partners plainly: a reply is visible to everyone on your team who can see the task, and to every other partner whose To-dos show the task — the other company on the item (the owner or the raiser), a partner the task’s list is shared with, the partner that made the list, and the managing company when a partner runs the project’s task list. Your people appear to them by name only, never by email address. Files a partner uploads are download-only and are never read into the project’s knowledge (files the project team attaches are — the partner sees the file, never its knowledge page). To-dos belong to the delivery space: a tender bid has none, even when the same company is also a delivery partner on the project.

A partner’s uploaders and editors can also send its own to-do list from the To-dos tab (Merge a to-do list), saying which of the lists it sees the rows are for: the workbook waits as a submission that only your managing company (and project leads and workspace admins) can open, preview and merge or decline from the Tasks page. Every member of the space sees its status and the note you decline with, and an uploader or editor can withdraw a pending one. At preview an AI model may read the sheet’s headers and a few sample rows to suggest how its columns map, and the file is kept only until the submission is merged, declined or withdrawn — see Merge a to-do list. The one exception is the company named under Who runs this list: it runs the project’s task list, so its editors merge their own workbook themselves, straight onto a list they run, within what their portal shows them — see When the partner runs the project’s task list.

A partner is emailed when a task is given to their company, when someone replies on a task their company owns, raised or brought in from its to-do list, when a reply on a to-do they can see asks their company for an answer (@), and once when an item their company owns is due within a week or has just fallen overdue; the link opens the item on their To-dos tab, and each also appears under their notifications. A task they see only because its list is shared with them sends them nothing. (A managing partner also gets the weekly summary and the overdue notices for its whole list — see above — and a partner that runs a list is told when a forecast on it moves past its due date.) The reminder-type emails can be turned off from the footer of the email or the Settings tab; the assignment, reply, @mention and forecast emails can be turned off there too, by email only.

Visibility follows the project’s clearance settings exactly as for anything else a partner sees: an item crosses to the partner only at a level open to third parties, never from a compartment, never while awaiting confidentiality review, and never without a level — even when the partner’s company owns it. Hold an item at a narrower level and the partner does not see it until you open it. Another company’s items are visible only when the partner’s company raised them, when they sit on a list shared with the partner or made by it, or when the partner runs the project’s task list — and only company tasks: a person-owned action never shows in a partner’s portal, whoever raised it.

When two companies are merged

Merging two organisations in Clients & vendors — a duplicate of the same company, say — moves the merged-away company’s live partner spaces (a delivery space, and any bid) to the company you keep, so its people carry on in their portal: their to-dos (and, if it runs the project’s task list, that role), the files and transmittals shared with it, its company details (unless the company you keep has its own), the replies credited to it and the drawings it originated all follow, and a partner you allowed to transmit to it (May transmit to) may now transmit to the company you keep. Each space moved is recorded in the project’s audit trail. A space that was already revoked stays with the merged-away company, as history.

Where both companies were given the same file, the company you keep keeps what the other could open: if its own share had already ended by the merge, it takes over the other’s live one. A share of the kept company’s that you revoke after the merge stays revoked. A transmittal either company acknowledged counts as acknowledged. The merged-away company keeps its own records as history, and it can no longer be deleted itself (it is the record of the merge). The only thing removed is a May transmit to entry that would now name the company itself, or that repeats one the list already has.

If the company you keep already has a partner space — live or revoked — on a project where the other has a live one (or a bid on the same tender), the merge is refused and names the project: revoke and delete one of the two spaces first, then merge. Deleting a space ends the file shares that came with it; the other company’s live shares carry on through the merge, whichever of the two companies you keep.

If a merged company’s people find their portal empty afterwards, tell ddx: the last step of the move, which writes the portal’s own records, can be finished safely at any time.

Language

A partner chooses English, Japanese or Korean from the account menu in the portal header (Read in 日本語, Read in 한국어 or Read in English). The To-dos tab, its drawer and thread, the dates and the task emails follow that choice; it is kept on their account. A task written in the other language is shown translated, with Translated · Show original beside it — the original is one click away. A reply a partner writes in Japanese shows to your team in English on the Tasks page once translated, with the Japanese kept as the record; the reply email quotes it as written. Translations are produced by an AI model and count towards the workspace’s AI usage. The Documents, Files and Transmittals pages stay English in this release, but the preview a file opens in follows your language.