Working with another vendor workspace

Cygnetree treats vendor collaboration as a project permission, not an invitation to either business's entire account. Any business you work a job alongside — a subcontractor, a supplier, a specialist, a coordinator — can participate as a guest, keep a durable account, and optionally represent their own Cygnetree workspace.

Start with project-scoped access

Open the project, add the vendor under Vendor partners, and choose the exact permissions they need. Timeline, project details, messages, shared files, uploads, and requests or approvals are independent choices. A request asks the vendor to complete work; an approval asks for an explicit approve, decline, or request-changes decision. Client contact information, internal notes, contracts, invoices, payments, automations, and unrelated projects are never part of the vendor grant.

Use Portal previews before sending or re-sending the invitation. The preview uses the live permission model without recording a vendor view or changing message state.

Claim guest access

The vendor can use the time-limited magic link without creating an account. If they choose Keep my access, creating or signing into an account automatically attaches every active guest grant before the temporary cookies are cleared. Declining an account never reduces the original project access.

Connect an existing workspace

A signed-in vendor sees Connect your business workspace only when they manage another Cygnetree workspace. They deliberately choose one eligible workspace for each collaboration. Cygnetree does not reveal or suggest cross-tenant matches based on client names, dates, venues, or domains.

The inviting workspace sees the connected business name and stable collaboration code. It does not gain membership, team, billing, client-list, or subscription information from the vendor workspace.

Create a business workspace

If the vendor does not manage a Cygnetree workspace yet, Create or open a business workspace opens the regular guided setup. Sign-in and onboarding preserve the current vendor invitation, then return to the vendor portal so the new workspace can be connected. The return flow accepts only the invitation identifier; it never follows a caller-provided web address.

Link a local project

The vendor may connect the workspace by itself or select one existing local project. A local project remains owned by the vendor workspace and appears there with a clear shared-project connection. This link is not a project merge.

The stable collaboration code lets both sides confirm they mean the same engagement without exposing fuzzy cross-tenant search results.

Open Shared schedule, tasks, and files on either linked project to choose individual tasks, milestones, confirmed appointments, and clean project files. Messages, vendor requests, and vendor uploads are registered when they are created. Turning on timeline access does not expose every internal task, and marking a file “vendor” does not make it available to every vendor on the project.

Shared-object synchronization is source-authoritative: Cygnetree reads a safe projection from the workspace that owns the record. It does not copy the record into the other tenant, and private local fields never win merely because they are newer. Stop sharing removes the projection without deleting the source record.

Understand what stays separate

Each workspace retains its own:

• people and client records;
• internal notes, tasks, pipelines, and automations;
• contracts, invoices, payments, and margins;
• files that were not deliberately shared;
• team roles, activity, notifications, and engagement state.

The inviting workspace may see when the external vendor views an artifact it shared. The vendor workspace cannot see whether the inviting team viewed vendor-originated work.

Disconnect or revoke a workspace

The vendor can choose Disconnect from the vendor portal. The inviting business can choose Disconnect workspace from the project. Either action ends the business-to-business link, records the decision for both workspaces, and leaves the original project-scoped vendor portal grant unchanged.

Removing the vendor from the project is the broader revocation. It ends portal access and any active workspace link while preserving the collaboration and audit history required to explain what happened. Re-adding the vendor reactivates the same stable collaboration identity.