Portablemind
Portablemind
Docs
Open Portablemind
Collaboration

Workspace Sharing

Give users from other organizations access to your workspace.

Workspace sharing lets users from one Portablemind organization work with another organization's content — with real, role-controlled permissions. Two companies collaborating on a project can grant each other's people exactly the access they need, while each organization's data stays isolated and under its own control.

This is the right model when your collaborators already have their own Portablemind organization — partners, service providers, agencies. If you're bringing in someone who's new to the platform entirely, start with Guest Users instead; that page also has a side-by-side comparison of the two models.

What workspace sharing gives you

  • A formal request/accept flow — sharing between organizations is established deliberately, by mutual agreement, never unilaterally.
  • Resource-level access — you share the specific things the collaboration needs — a conversation, a project, a folder — not your whole workspace.
  • Role-based permissions — everything a visiting user can see or do is controlled by the access levels on each share and the security roles and capabilities the host grants.
  • Work from your own login and your own workspace — content shared with you appears inside your own workspace, and when a partner admits you to their workspace you work with it from there. You never need a second login, and you never switch away from your own workspace.

Core concepts

Sharing relationships

A sharing relationship is a formal link between two organizations. It moves through a small set of statuses:

StatusMeaning
PendingRequested, awaiting the other organization's acceptance
ActiveAccepted and functional
SuspendedTemporarily paused
RevokedPermanently ended — the access it granted is removed

Tip: Revoking is permanent — it's a hard unshare, and re-establishing access afterwards requires a brand-new invitation.

Hosts and partners

In any relationship there are two sides:

  • The host organization is the one granting access to its content.
  • The partners are the people from the other organization who receive that access. They're marked Partner · their organization in chat, sharing and assignment lists.

Host users only ever see their own workspace — they provide access, they don't receive it. Partners work from their own workspace, where the content shared with them appears alongside their own.

Guest means something else in PortableMind: someone you invite into a single conversation with Invite Guest to Conversation. A partner is a person from another workspace.

Roles and shares control everything

A relationship on its own is not enough to see a host's content. What a visiting user can actually reach is determined by what the host shares and the permissions attached — each share carries an access level, and the host's security roles and capabilities govern everything beyond it, using the same permission system that governs the host's own members.

The sharing workflow

Establishing a partnership between two organizations works like this:

  1. Invite — from the Partners page (Administration → Partners), an administrator clicks Invite Organization and enters the email address of a contact at the other organization. There's no directory to browse — invitations always go to a specific email address.
  2. Accept — the other organization sees the incoming request in the Pending section of its own Partners page and accepts (or declines) it. The relationship becomes active.
  3. Share and grant — access to actual content is granted by sharing specific resources — conversations, projects, files — with the partner, and by the roles and capabilities the host assigns. Until something is shared, there's nothing for the partner to see.
  4. Access — the partner's users now see the shared content from inside their own workspace, within whatever their access levels allow.
Request and accept a workspace share

For API-level details, see the API guide.

Sharing an individual item with a partner

Day to day, most cross-organization sharing happens from an item's own Access dialog — open it with Share on a project, task, chat, or file. (If you can't change who has access, the channel menu says Who has access instead and the dialog only shows the list.) The dialog lists everyone who can open the item, the access each one has (Can view, Can comment, Can edit, Full access, Owner), and where it Comes from: a direct share, a folder or project it sits in, a team, or a membership. Rows that come from somewhere else are changed there, not here.

Its add box (Add people, teams or partners…) groups what it finds under People, Teams, Partners and Email:

  • A person — anyone you can see, including people from partner organizations (marked Partner · organization).
  • A team — one of your own teams.
  • A partner team — under Partners, each active partnership offers its designated manager team, shown as "Organization — team". Sharing with it grants access to the members of that specific team, at the access level you pick. This is the usual way to hand a whole partner working-group access to something in one step.
  • An email address — for someone who isn't in your workspace yet. An admin can Invite and share; anyone can Share by email, and they get access when they sign up.

Which flow do I want?

You want…Do this
One partner person to see or edit an itemShare the item with that person
A partner's working team to see or edit an itemShare the item with the partner team from the Partners group
A partner organization to file tickets against a project without seeing itDon't share — publish the Application for ticket intake
A partner team to work the tickets you receiveThe partnership's standing ticket share

Tip: a share always grants real visibility at the level you choose — Can view and up. If what you actually want is "they can raise tickets against this, nothing more," that's intake publishing, not sharing.

Giving a partner's people working access to your apps

Sharing item by item works for a handful of things. When a partner's person needs to work in your workspace — a consultant running an engagement, an agency producing your content — give them access to whole apps instead:

  1. Click Add person — the icon next to your notifications in the top bar, or the button on Administration → Users. It is shown to your workspace's administrators.
  2. Enter the person's email address. The dialog says whether they're already here (then the button reads Open their page), new to your workspace, or joining as a Partner — a guess from the email's domain that you can switch under Joining as. A partner keeps their own account in their own organization.
  3. Pick the apps they need: Chat, Plan & Track, Files, Tickets (a colleague starts with the first three). A partner can start with none — sharing a file, chat or project with them turns its app on.
  4. Click Send invite. In Files they reach only what you share with them — whole folders or single files — at the level you choose. Removing the partnership removes the access.

To review or change what a partner's person holds later:

  • Administration → Users, turn on Include partner users. Partner people are listed with a Partner tag. You can view them and Manage Roles (the roles they hold in your workspace). Their profile, password, admin status, spend limits and account belong to their own organization, so edit, reset password, the admin switch, spend limits and delete aren't offered, and a partner is never shown as an admin of your workspace because they're an admin of theirs.
  • Administration → Assignments, turn on Include partner users to find them in the Assign To search. A partner person is given your workspace's security roles, never individual capabilities: roles are the reviewed bundles, and they end with the partnership.

Working inside a partner's workspace

You always stay in your own workspace — there is no switching. When a partner admits you to their workspace (adds you with Add person), what they share shows up where you already work:

  • Channels, files and tasks shared with you appear in your own Chat, Files (under Shared Files) and Plan & Track, labelled with the partner's name. Folders you see are the ones shared with you, or that hold files you can open — never the rest of their folder tree. A folder shared with you gives you the same access to the files in it — Can view, Can edit or Full access — except their private files, which stay private.
  • Their memories — pick their workspace in the Workspace select on AI Studio → Memory Graph. The graph then shows that workspace's memories you can access (its shared memories and the ones you saved there), says Memories of workspace · you're a partner here, and Forget, edit and links act there. Pick Your workspace (home) to go back. See Memory.
  • Saving to memory from a partner's channel asks which workspace it goes to (see below).
  • A connected AI app acts in a partner's workspace through that workspace's own connection URL — see Acting in a partner's workspace.

Content shared with you item by item works the same way, filtered by the permissions you hold on each shared resource.

@ai in a partner's channels

When a partner has admitted you to their workspace, @ai in their channels answers as their workspace: it searches their files, memories and conversations, works with their tools, and their workspace pays for the AI. The chip above the message box says so (see Which workspace your AI and memories use). It never brings your own workspace's material into their channel. Your messages still count toward your own plan's monthly message allowance.

If you only have a channel or item shared with you (you haven't been admitted to the workspace), @ai there keeps running on your own workspace, as before. Direct messages always run on the sender's own workspace.

A workspace's administrators decide this under Administration → Partners → Partners' @ai uses this workspace (on by default). The same panel has Learn from partners' posts in our channels (off by default): with it on, background memory capture may learn from your public channels that admitted partner people post in (see How memories are created). Turn it off and partners' @ai in your channels uses their own workspace and AI budget again.

Connected AI apps work the same way — see Acting in a partner's workspace.

Which workspace your AI and memories use

Every channel shows it, so you never have to guess:

  • Above the message box — a chip such as AI · Trustworks — their tokens, files and memories in a partner's channel, or AI · your workspace — your tokens, files and memories in your own.
  • On AI replies — an AI · workspace label naming the workspace that reply actually ran as. In a partner's channel every AI reply has one, including replies that ran as your own workspace, so you can tell them apart; in your own workspace's channels only a reply that ran as another workspace is labelled. It's recorded when the reply is written, so it stays right if the setting changes later, and it shows as soon as the reply arrives. Replies written before this existed carry no label.
  • When tokens run out — the alert names the workspace whose tokens ran out. If that is a partner's, it doesn't show their balance or offer you a purchase; their administrators top it up.
  • When a partner's subscription is paused — working in their workspace (the Memory Graph, saving to their memory) shows a notice such as Trustworks's subscription is paused — its administrators can reactivate it. It never locks your own app.
  • Saving to memory — the dialog says Saves to: workspace before you save. In a partner's channel it saves to their workspace by default; choose My workspace instead to keep it in yours.
  • Memory lists — the Memory Graph names the workspace it shows (Memories of workspace), and its Workspace select picks another one you were admitted to. Settings → Memory is always your own workspace's.
  • Usage — AI Studio → Cost Analysis answers two questions:
    • AI across workspaces — who paid: what other workspaces paid for in your channels, and what yours paid for in theirs. A partner's @ai in your channel is normally paid by you, so it isn't listed here.
    • Partners' AI in this workspace — who asked: AI that people from each partner workspace asked for in your channels, with its requests, tokens and cost.
    • AI you ran in partner workspaces — how many AI requests your people made in each partner's channels. It shows the count only, because that cost is on the partner's workspace and is theirs to see.

A connected AI app gets the same answer in its results: chat, memory and usage tools name the workspace they acted in.

To give a partner's people working access to your apps, files and memories, use Add person (see above). Roles given under Users or Assignments add to that access; they don't replace it.

Where shared content appears

Content shared with you from another organization appears inside your own workspace — in Files under Shared Files, in Chat, in Plan & Track — labelled with the owning organization's name.

If someone shares content with a person who doesn't have a Portablemind account yet, the share invitation email walks them through creating their own workspace — and the pending shares activate as part of signup.

Accept a workspace share

Ending a share

Relationships don't have to be forever. From the Partners page, opening a partnership's Manage dialog offers Revoke — a permanent, hard unshare: the access granted through the relationship is removed in one step. If the organizations want to collaborate again later, they start over with a new invitation.

Security model

Workspace sharing is designed so that collaboration never weakens isolation:

  • Deliberate grants required — no user can touch another organization's data unless that organization explicitly shared it with them.
  • Role-gated access — every action a visiting user takes is checked against the access levels, security roles, and capabilities the host granted. There is no implicit access.
  • Explicit granularity — access is granted share by share, or app by app through roles — never silently to an entire workspace.
  • Audit trail — every relationship change and access grant is logged.
  • Clean revocation — revoking a relationship removes the access it granted in one step, so nothing lingers.
  • Guest Users — invite brand-new users into your workspace with scoped access, and see how guests compare to workspace sharing.
  • Tickets and Partners — partner onboarding and cross-organization ticket management built on top of workspace sharing.
Guest UsersVideo Meetings (Meet)