> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.
# What your partners can see, and what they cannot
> The rules behind a partner's view: what is isolated by default, what one contact sees of their colleagues' records, what they can edit, and what decides all of it.
> For anyone who has been asked "what will our partners actually see?" and wants the rules, not a screenshot.
Everything else in these docs is written from your side of the program.
This page is the other side: what a partner lands on, what is hidden from them without you configuring anything, what one of their colleagues sees of their work, and which setting decides each of those.
It is the question that comes up in every demo and every security review, and the answer is a model with only a few moving parts.
## What you'll achieve
A precise mental model of the partner's view: the three boundaries that are always enforced, the one visibility choice you actually make, and where each decision lives.
Enough to answer a partner's IT team, or your own, without guessing.
## What a partner needs on their side
Nothing you have to buy, install, or migrate for them.
| They do **not** need | Why not |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A seat in your CRM | Partners are portal users, never CRM users. See [Provisioning](/features/access/provisioning) |
| A CRM of their own | The portal works standalone. A partner who has HubSpot or Salesforce can connect it, but it is optional. See [Introw for partners](/features/partner-connect/partner-crm/guides/introw-for-partners) |
| Their own Introw contract | There is no charge to the partner for a portal, a chat channel, or an assistant |
| Software to install | The portal runs in a browser, and installs as a mobile app only if they want one. See [Install Introw on mobile](/features/portal/mobile/guides/install-introw-on-mobile) |
| A password to remember | Sign-in is a one time password by default, or your own identity provider. See [Portal SSO](/features/access/sso) |
What they do need is a work email address that you have given access to, which is the whole onboarding step.
See [Invite partners and their teams](./invite-partners-and-their-teams).
## The three boundaries that are always up
These are not settings. They hold before you configure anything, and there is no switch that opens them.
1. **One partner never sees another partner.**
Partner-level isolation is enforced on every partner-facing read, independently of segments, experiences, and permissions.
Two resellers on the same experience, looking at the same tab, see their own pipeline and nothing of each other's.
2. **A record that is not shared with them does not exist for them.**
Partners see the CRM records attributed to them, plus what you deliberately share on a record.
Your direct pipeline is not filtered out of their view, it is never in it.
3. **Only the fields you open are visible, and fewer are editable.**
A field must be made visible on the embed before it can be made editable, and anything you have not opened stays hidden or read-only.
See [Set up a reseller pipeline](/features/deal-registration/shared-pipeline/guides/set-up-a-reseller-pipeline).
Free email domains are also refused where access is granted by domain, so a `gmail.com` address can never inherit a partner's access.
## Inside one partner: who sees whose records
This is the one visibility question that is genuinely yours to decide, and it is the one most programs get asked about first.
When several people at the same partner have portal access, either they all see everything shared with their company, or each sees only what they are a collaborator on.
| Setting | What that contact sees | Use it when |
| ------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------------ |
| **See all shared records** on | Every record shared with their company, whoever it came from | The partner works as a team, and a manager needs the whole picture |
| **See all shared records** off | Only the records they are a collaborator on | Reps at the same partner should not see each other's registrations |
Notifications follow the same line, so a contact is never emailed about a record they cannot open.
You set the baseline organisation-wide and override it per segment.
Where a contact matches several overriding segments, the most permissive one wins: one segment granting **See all shared records** is enough, and the others do not have to agree.
See [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment) and [Layer segments to progressively unlock](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
The same cascade carries **Invite colleagues**, which decides whether a partner can bring their own coworkers in rather than asking you.
## What decides everything else
Six controls, each in one place.
| The partner's question | What decides it | Where you set it |
| ------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| "Which tabs and sections do I get?" | The experience they are on | [Experience builder](/features/portal/experiences) |
| "Why can my colleague at another partner see a tab I cannot?" | A tab restricted to a segment | [Restrict a tab to segments](./restrict-a-tab-to-segments) |
| "Which deals are mine?" | Attribution in your CRM | [Attribution](/features/integrations/crm/attribution) |
| "Which fields can I change?" | Visible and editable properties on the embed | [Shared pipelines](/features/deal-registration/shared-pipeline) |
| "Can I get in at all?" | Portal access on the contact, or a CRM property that drives it | [Drive contact portal access from your CRM](/features/integrations/crm/guides/map-contact-portal-access) |
| "Who is my contact, and who signs my emails?" | Your team's roles on that partner | [Partner team](/features/partners/team) |
Tiers change what a partner is entitled to rather than what they can technically reach, so use a segment, not a tier, when the intent is to hide something.
See [Tiers](/features/partners/tiers).
## Introw does not inherit your CRM's sharing model
Worth being explicit, because it is assumed in most security reviews.
Salesforce sharing rules, HubSpot teams, and record-level CRM permissions govern who inside *your* company sees a record in *your* CRM.
They do not carry over to partner-facing reads, because a partner is not a CRM user and no CRM licence is involved.
Partner visibility is decided entirely by the model above: attribution, what you shared, the experience, segment permissions, and the fields you opened.
A field your team edits in the CRM is visible to a partner within about a minute where that field is visible on a shared record.
There is no quiet window, so treat every visible field as partner-facing the moment you open it.
See [How the sync behaves](/features/integrations/crm/technical).
## What they see when they never open the portal
Partner adoption does not depend on the portal being opened, so plan for the partner who lives in their inbox.
* **Email** carries deal movement, tasks, approvals, announcements, and course reminders, and a reply lands back on the record for everyone on it. See [Every notification Introw sends](/features/engagement/notifications/guides/every-notification-introw-sends).
* **Slack and Teams** carry the same signals into a shared channel, where a partner can register a deal without opening anything. See [Channels](/features/engagement/channels).
* **Their own CRM card and assistant** put your shared deals inside their stack, for the partners who want that. See [Partner Connect](/features/partner-connect).
## Whose brand they see
Yours, on every surface a partner touches.
The portal takes your logo, colours, and fonts; the address can be a domain of your own; and notification email can be sent from your own domain.
One honest caveat: partner-facing surfaces carry a small "Powered by Introw" mark unless you have the white-label add-on, which removes it from the portal, forms, the asset library, and generated certificates.
See [Branding](/features/portal/branding), [Custom domains](/features/portal/custom-domains), and [Email domain](/features/portal/email-domain).
## Check it yourself
The honest test is to look at a real partner's portal rather than an editor preview.
In the experience builder, **Preview** lists the partners on that experience and opens the one you pick in a new tab, rendered with their pipeline, tasks, tier, and assets.
It shows the published state, not your unsaved draft.
See [Draft, publish and preview](/features/portal/experiences/guides/draft-publish-and-preview).
Give an internal address portal access on a copy of the experience and use it as the account you sign in as.
It is the only way to see the login, the emails, and a collaborator-only view exactly as a partner does.
Open a deal as that partner and confirm only the fields you opened are editable.
Then check a second contact at the same partner sees what your **See all shared records** decision says they should.
## Troubleshooting
Check attribution on the record first: an unattributed deal is invisible to them by design.
If attribution is right, check whether their contact is collaboration-restricted and simply is not a collaborator on that record.
The tab is on their experience but the section behind it has nothing for them, which is what previewing as that specific partner is for.
See [Every portal section](/features/portal/experiences/guides/every-portal-section).
They match different segments, and the permission cascade resolves most-permissive.
See [Layer segments to progressively unlock](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
Portal access is off on the contact, or the CRM property that drives access does not have the value you mapped.
See [Set up portal access](./set-up-portal-access).