> ## Documentation Index > Fetch the complete documentation index at: https://docs.parlehub.com/llms.txt > Use this file to discover all available pages before exploring further. # Integration Credential Scopes: Organization, Project, and User > What Organization, Project, and User scope mean for an integration credential — who authenticates, whose access the agent uses, and who ends up able to read the results. Every integration credential ParleHub stores belongs to exactly one of three scopes. The scope you pick when you connect an integration decides three things: **who authenticates**, **whose access the agent uses** for a given call, and **who can end up reading the result**. It's the most consequential choice in setting an integration up, so read this before connecting anything that reaches content not everyone in your organization should see. **A catalogue entry decides which scopes it even offers — you're never choosing from all three.** The right scope is a property of the system being connected, not of the admin's mood. [Confluence](/tools/confluence) can sensibly be any of the three, because a documentation space can reasonably be org-shared, project-owned, or personal. A personal mailbox or calendar integration would only ever offer **User** scope: a shared inbox credential handed to every project's agent isn't a sensible thing for any catalogue entry to permit, so the entry simply never offers Organization or Project for it. ## Organization scope **One connection, shared by every project the integration is enabled on.** An Org Admin authenticates once — approving OAuth access, or entering an API key — and from then on every project that switches the integration on uses that same connection. * **Who authenticates:** the Org Admin who connects it. * **Whose access the agent uses:** the connected account's, for every call from every project. * **Who can see the results:** anyone in any project the integration is enabled on. **Organization scope is the only one that survives unattended agent work.** Nothing else about ParleHub requires a person to be online for the agent to act, and Organization scope is what keeps that true for integrations too — there's always a credential available, because it doesn't belong to whoever happens to be in the conversation. Pick this for a service account, or a space every project may legitimately search. ## Project scope **Each project that enables the integration connects its own account**, separately from every other project. A Project Admin runs the connect flow from that project's Tools tab; a Project Admin never supplies a server address or any other outbound destination — that stays decided by the Org Admin who registered the integration in the first place. A project that hasn't connected shows the integration as switched on but **not connected**, and the agent can neither see nor call it there until someone does. * **Who authenticates:** a Project Admin, on behalf of that project. * **Whose access the agent uses:** that project's own connected account — never another project's, even for the same integration. * **Who can see the results:** anyone in that project's conversations. Nobody in a different project, even one enabled for the same integration, can reach this project's connection or its results. Pick this when different projects should each see only their own space in the connected system — a firm running Confluence for two separate client engagements, for instance, where one client's documentation should never surface in the other's project. ## User scope **Each member connects their own account** from **My Integrations** in their personal settings — see [My Integrations](/tools/my-integrations). The agent then acts with the asking member's own access: it can reach whatever that member's account could reach at the provider, and nothing more. * **Who authenticates:** each member, individually, for their own connection only. * **Whose access the agent uses:** the credential of the member whose turn triggered the call. * **Who can see the results:** everyone who can see the message the results landed in — which in a shared project conversation is every member of that project, not just the one who connected. ### The fan-out consequence, and why it's accepted User-scoped integrations are allowed in shared project conversations, and that has a real consequence worth stating plainly: if Alice asks a question that triggers a Confluence call, the agent fetches with **Alice's** credential, and the answer goes to **everyone in that conversation** — so a colleague may end up reading content their own account couldn't have retrieved themselves. Nothing about a shared conversation stops working because one member's connection reached further than another's would have. The alternative — restricting User-scoped integrations to personal, one-person conversations — was considered and rejected: project conversations are where ParleHub's collaboration happens, and walling User scope off from them would gut the feature for exactly the teams it's meant to help. What ParleHub does instead is disclose it, every time. **Whenever a reply used a member's own credential, the message says so** — for example, *"Retrieved using Alice's Confluence account"* — visible to everyone who can see that message, in shared conversations and personal ones alike. It's a permanent part of the message: reopening the thread tomorrow still shows whose access produced the answer, not just at the moment it happened. This is also recorded in your organization's audit log, but the label on the message is the control that matters here — there is no customer-facing audit screen or export today, so audit alone would make the disclosure invisible to the people it actually affects. There's no setting to turn the disclosure label off, and there won't be one. A label whose "off" position hides exactly the thing it exists to reveal isn't a control worth offering. If a member hasn't connected their own account yet, the integration still appears in the conversation — the agent tells them it needs a connection and links to My Integrations — rather than silently disappearing from the tool list, so the absence never looks like "this integration doesn't exist here." ## Changing scope Changing an integration's scope is a **disconnect and reconnect**, not a migration — there's no path that carries a credential from one scope to another, because a Project or User connection is a genuinely different account authenticating, not the same one relabelled. ParleHub tells you this before you confirm a scope change. ## If your plan changes Losing the Integrations entitlement never touches a credential you've already connected, at any scope — see [Plans & Billing](/plans-and-billing#what-happens-if-your-plan-changes). It only stops **new** connections and new tool calls; every member who already connected their own account can still see it and disconnect it themselves.