Delivery partners

A delivery partner is an outside organisation that exchanges files with your project continuously — a contractor, a consultant, a supplier post-award. Instead of emailing files back and forth, you give them a delivery space: their own portal onto exactly the folders you choose.

This is different from a share link (one document, one recipient, expiring) and from a tender (a structured bid with a checklist). A delivery space is a standing, two-way exchange.

Inviting a partner

On the project’s Partners page, press Provision partner and fill in:

• Organisation — picked from (or added to) your organisation list.
• Email — the first person at the partner; they’ll claim the space and become its first member (you can add more people afterwards — see People at the partner).
• Project name — what this partner’s portal calls the project; it also heads their invitation email. It starts as your project’s own name, because everything you exchange with them sits under it; change it before you press Provision partner if you want something else, as it can’t be changed afterwards. Emails that mention the project in passing — the invitation’s closing line, task notices — use the project’s own name from its settings, so keep the two alike.
• Presented as — the client name the partner sees (white-label: they see the client’s brand, not ddx, unless you choose otherwise).
• Brief (optional) — a short note shown at the top of their Files view.

The partner receives an email — “You’ve been invited to a file exchange” — with a claim link. The link is also copyable from the Partners page, so you can send it yourself. Claiming it, they sign in (or create a sign-in) and land in their delivery space. Until they claim, the row shows invited; you can resend a fresh link or revoke the invitation at any time.

“…owns these tasks on this project”

Provisioning is refused while the organisation owns a task on this project whose clearance keeps it inside the workspace — a task pinned on a drawing kept inside, say. Once it’s a partner it sees the project only through its portal, which never shows such a task, so the task would sit with a company that can’t see it, won’t be told about it and can’t close it. The message names the tasks you can open (and says when there are others). Give each to a company inside the workspace — or re-class the drawing it’s pinned on to a level partners can see — then provision again. Nothing was sent and no space was made.

While organisations are being merged

Provisioning waits for a merge of the organisation it names:

• An organisation being merged into another. Once the merge is done, provisioning stops and names the organisation it was merged into — provision that one instead. Nothing was sent and no space was made.
• The organisation others are being merged into. Once the merge is done, provisioning goes on, judged with the tasks the merge has just given it: you may be told it owns tasks here it could never see, as above.

If the merge is still running after a couple of seconds, you’re asked to try again in a moment; nothing was sent and no space was made.

Choosing what they see

Each partner row has a folder access editor — tick the folders that make up their slice of the tree:

• A ticked folder covers its whole subtree.
• Inside those folders they see Shared, Published and issued documents — never anyone’s WIP, never unissued drafts, and never a folder you didn’t tick. The rest of the tree is structurally invisible to them — with one deliberate exception: the parent folders above a granted one show in their portal as greyed, context-only waypoints (name only, no files, no uploads), so a partner with folders in several packages can tell which 00_Reference belongs to which package.
• Their own uploads are always visible to them, whatever the state. If you re-class one above the partner ceiling, they still see it — but only the versions they uploaded, not versions your team (or anyone else) adds to it.
• Saving a folder they didn’t have emails them a link to it — see emails the partner receives. You don’t need to send them a link yourself.
• Need to share most of a folder — a package minus the other partners’ WIP folders, say? Use ⋯ → Share folder… in the file browser and untick what they shouldn’t get; see Sharing with delivery partners.

The folder list is empty?

The project predates the filing standard and has no tree yet. A workspace admin can instantiate trees for existing projects with one button — see Filing standards.

Seeing who has a folder

A folder any delivery partner can see carries a small people icon — beside its name when it is open, and on its row in the tree. Hover the icon for the list of companies; click it (on a phone, tap) to open the list, which also marks a partner whose invitation is still out as not yet joined. No icon means no partner can see the folder.

The same answer shows up wherever it matters:

• In Share folder…, a partner who already holds the folder is greyed out with the reason — already has access via 30_CDE names the parent folder the access comes from — rather than offered a tick that would change nothing.
• A file’s Sharing panel says which partners can see that file through the folder — and says when none can: a pocketed file, or one above the partner ceiling, is hidden from every partner whatever their folder access, until it is re-classed.
• A folder whose documents default to internal says so at the foot of the list: a partner holds the folder but sees nothing in it until a document is re-classed to a partner-visible level.

Partners see the same names from their side. Every folder in their portal says who else can see it, so nobody issues into a shared folder without knowing who is there — see What partners get in Files. Granting one folder to two partners is what introduces them; keep partners that must not know of each other in separate folders.

People at the partner

A partner organisation is rarely one person. The People panel on the partner’s detail page manages everyone at that organisation who can enter the space — add a colleague by email, and they get their own claim link and their own sign-in. Each person carries a role, Drive-style:

Role	Can do
Viewer	Browse and download everything the space can see; read the company’s to-dos, their threads and files, the pins on drawings, and the portal’s Decisions page.
Uploader	…plus upload files, and create subfolders inside the granted folders. On to-dos: reply and attach files, and edit or delete their own replies and files while the to-do is open; drop a pin on a drawing, which raises a task; and send the company’s own to-do list for your team to merge.
Editor	…plus add versions, hand documents over (issue), transmit them to your team, and delete their own un-issued files (soft — the file lands on your pending-deletions queue). On to-dos: mark one their company owns as WIP; report a forecast date and % complete on one their company owns, raised or imported, and reword the ones it raised or imported; make lists for the company and run them — raise, edit, close and reopen the tasks on them, rename, share and archive them; and choose which of those lists a pin’s task goes on. If the company is the one named under Who runs this list, they run the project team’s lists the same way, and merge a to-do list themselves.

You can change a person’s role, resend their invitation, or revoke just that person at any time — revoking one member never touches the rest of the space.

What the partner can do

In their portal (see The supplier portal for the full tour) a partner can:

• Browse and download what you’ve issued, shared or transmitted to them.
• Upload files into their granted folders. Uploads with a valid container name register as controlled documents (starting at WIP — private to them until they hand them over); anything else files as a descriptive draft.
• Hand work over — issue their own document at a suitability, which is when your team first sees it, marked from partner.
• Acknowledge transmittals you issue to them.
• Work their to-dos — see the project’s tasks their company owns or raised, the ones that came from its own to-do list, and every task on a list shared with it or made by it; reply and attach files (uploader or editor), mark an item their company owns WIP, and report a forecast date and % complete on one their company owns, raised or imported (editor) — never the due date. Closing, reopening and changing a task belongs to the company that runs the task’s list. A partner’s editors do that on the lists their company makes for itself, and on the project team’s lists only when their company is the one named under Who runs this list (the Tasks page’s Task settings). See The partner’s to-dos.
• Keep company details current — legal name, address, contacts.

Emails the partner receives

When	Email
You invite them	You’ve been invited to a file exchange with the claim link. Below the button, one line tells them what DDX PMO is, naming your project as it is named in its settings — for a project called Harbour Tower fit-out: DDX PMO is the delivery platform for RFQs, file transmittal and sharing for the Harbour Tower fit-out project. So give the project the name you want partners to see.
You issue/share files their way	One email per burst, not per file: A file was issued to you: … or A file was shared with you: … for a single file, or 4 files were issued or shared with you listing each file with its own link (the folder, with the file’s details open). It goes out once your shares to that person have paused for fifteen minutes — a single file waits the same — so a set sent over half an hour arrives as one message. Each person gets one per delivery space; a file deleted, withdrawn or archived before it goes out is left off, and someone removed from the space gets nothing. Unticking notify on a share still applies per file and is recorded in the delivery log, which shows one row per summary; each file’s own history records the summary it went in.
You give them a folder	The same email, listing the folder with a link that opens it: A folder was shared with you: 24_Mock-ups…, or A folder and 2 files were shared with you when files went in the same burst. It goes out whichever way you gave the folder — Share folder… in the file browser, or ticking it in their folder access on this page — but only for a folder they could not already see: a folder inside one they already hold, or a save that changes nothing, sends nothing. A folder you take away again (or retire) before it goes out is left off. Taking a folder away is not emailed yet.
You send a transmittal	Transmittal RCT-TX-0001 with the acknowledgement ask.
A task is given to their company	T-0007: … — assigned to … with a link to their to-dos.
Someone replies on a task their company owns or raised, or that came from its to-do list	T-0007: reply from … with the opening of the reply.
A task their company owns is due within a week, or overdue	A reminder, once per task and due date, at the project’s reminder hour.
Their company runs the project’s task list	The weekly summary, and the overdue notice for every task on their To-dos, not only their own.
Their company runs a list, and a progress update moves a task’s forecast past its due date	T-0007: forecast now after the due date — … with who moved it, the new and old forecast, and the note.

A task their company neither owns nor raised, which they see only because its list is shared with them, sends them nothing (unless their company runs the project’s task list, as in the last row).

All of it is branded with the presented-as name. Replies to an invitation go to the inviting operator; the task emails are notices, and the place to answer is the link they carry. See who gets told for the full rules.

Housekeeping

• Revoke ends access immediately (their uploads stay on the project).
• One organisation can hold several spaces on one project (e.g. separate packages) — each has its own folder access.
• Everything a partner does is audited and feeds the exchange register with an external actor label, so provenance survives.