Shared Pipelines

​

Where it lives

Shared Pipelines sits under Track, at Deals.

​

Before you start

​

How it works

A shared pipeline is the same set of CRM deals shown to both your team and your partners, scoped by attribution. Attribution links each deal to the partner who should see it. Once deals are attributed, you add a pipeline view to a partner experience so partners see their deals in the portal, and your team reads the same deals from the deal overview, either org-wide or filtered to a single partner. Each deal - and any other attributed CRM object - can also be opened as a collaboration surface, with a shared Activity feed for comments, a Files area, Tasks, and a set of properties you decide to show. Your team opens it from an overview page, a partner record, or the CRM embed; partners open it from the portal. You control scope in a few places: attribution decides which deals belong to which partner, the pipeline view’s filters decide which of those deals appear, collaborators decide which partner contacts are in the loop on a record, and property visibility decides which fields partners can see and which they can edit.

​

Settings & configuration

Attribution is configured in CRM setup; the pipeline view and embed are configured in a partner experience; and your team reads pipeline from Deals.

​

Deal attribution

Attribution links deals to partners so they can appear in a shared pipeline. It is set up on your CRM connection in Settings, then Integrations, where you define how deals relate to partners. Until deals are attributed, there is nothing to share.

​

The pipeline view in the partner portal

In a partner experience, add a pipeline view (a CRM list of deals) and configure it: pick the pipeline and record type, choose the properties partners see, and set the filters that scope which deals appear. The view can be shown as a board by stage or as a table, and you can save more than one view.

​

Totals on the property you choose

Board columns and the pipeline bar total on the deal amount by default. Point them at a different numeric or currency property instead - MRR, ACV, a partner-facing value that differs from the revenue your team books - and both the stage totals and the value on each card follow it. The same setting exists on the internal deal overview, where the property is flagged as the aggregation property on the view.

​

Saved views and filters

One embed can carry several named views, each with its own filter set, so a single tab covers “open”, “closed this quarter”, or one view per currency without a second embed. Filters accept any CRM property, and every property type offers Is known / Is not known, text adds does-not-contain, and dropdowns add Is any of / Is none of.

​

Which stages partners see

Configure stages lists the pipeline’s stages in the order partners read them. Drag to reorder, rename any stage to partner-facing wording (display only, with your CRM’s own label kept as a tooltip), and remove a stage from the view entirely. Removing a stage does two things at once, which is what makes it a guardrail rather than a cosmetic choice. The stage stops being a column on the board, and it also stops being an option anywhere a partner changes the stage: the board’s drag targets, inline editing in the list, and the stage picker on the record. Drop Closed Won and partners can move a deal forward through the pipeline without being able to close it themselves. Add stage brings a removed stage back.

​

Editing from the board

Partners edit the fields you marked editable inline in the list view, and drag a card between stages on the board when stage editing is allowed on the view. Every edit is written straight through to the CRM, and your CRM’s own property validation rules are applied first - a value the CRM would reject is refused in the portal with the property named, rather than failing silently later.

​

Reading pipeline in Introw

Your team reads pipeline from the deal overview, which can be viewed org-wide or scoped to a single partner from that partner’s record. Saved views let you set the columns and filters your team needs.

​

Collaborating on a record

Share opens an object up for partner collaboration and takes you to its collaboration view. Collaborators are the partner contacts in the loop on a record; add or remove them to control who can see and act on the object. The Activity feed carries comments, Files holds shared attachments, and Tasks tracks next steps. Comment visibility. Your team members choose per comment whether it goes to Everyone or stays Internal, using the control on the composer. Everyone is the default. An internal comment is hidden from every partner-facing surface and never triggers a partner notification, and it is marked as internal in the activity log so your team can tell shared notes from private ones. Partner contacts have no such control; everything they post is visible to both sides. Comments from your own systems. The same comments can be posted over the API, targeting a deal, ticket, task, submission, payout, or the partner directly - including internal ones. See Nudge partners at scale via the API. Which objects can be shared. Collaboration is not limited to deals. Any CRM object type you have mapped to partners can be opened up the same way, which is what lets a program run on the record its business actually lives on: tickets for a support-led partnership, orders or line items for a reseller, and custom objects for anything your CRM models itself. Installations, projects, sites, assets, subscriptions and renewals are all common, and a partner sees them as a scoped list or pipeline in the portal exactly as they see deals. Two things to know. Custom-object collaboration is a plan module, so check what yours includes at introw.io/pricing. And the object needs an attribution method before it can be shared, since collaboration resolves through the partner link. See Configure deal attribution and add the object on the Object Linking screen of your CRM integration.

​

Visible, editable, and renamed properties

Property visibility is set on the CRM embed configuration for the object - and on the pipeline view for deals. For each object you can:

• Add any synced CRM field - standard or custom, from the deal (or any attributed object) - not just a fixed default set.
• Choose what partners see and edit - mark each field visible and, independently, editable, so partners get the context they need without exposing internal fields.
• Rename each field to partner-friendly terminology - override the label a partner sees (for example show dealstage / StageName as “Stage” or “Where we are”). This is display-only: the value keeps coming live from the CRM, and the original label is kept as a tooltip. It’s what lets the portal read in your partners’ language instead of your internal property names.

Related items like contacts and line items can be shown or hidden the same way, with line items and quotes depending on your plan. The same add-any-field-and-rename model applies to Introw’s internal tables and object overviews too - see Show and rename CRM fields.

​

Custom actions

Editable properties decide what a partner can change directly on the record. Custom actions put your own buttons on that record, each opening one of your forms in a dialog, already carrying the record’s context so the partner does not re-pick the deal they are looking at. The two are independent, and that is the useful part. A form writes the properties you map on it whether or not those properties are marked editable here, so a field can be read-only on the record and still changeable through a form. That is how you make a change conditional: leave the property non-editable, so inline editing, dragging a card between stage columns, and the built-in Edit dialog are all off the table, and route the change through a form that can narrow the options, ask a follow-up question, and make it mandatory. Marking the same property editable as well simply reopens the unguarded path beside the guarded one. Configure them on the embed’s Configuration tab, under Custom actions. Each action takes two things:

• Form - the form the button opens. Anything in your form list qualifies, so the same update form can serve several pipelines.
• Button label - what partners read on the button. Write the action, not the object: Request an order, Update the deal, Ask for support.

Add action button adds another, so one record can carry several actions side by side. Because the form is a form, it brings the whole form builder with it: fields you choose, a narrowed set of dropdown options, conditional fields that appear only when they are relevant, an optional approval gate, and a CRM automation that writes the answers back onto the same record. That combination is how a request that needs a reason, a document, or a second pair of eyes stays a real request instead of a silent field edit. See Let partners update a deal with guardrails for the whole recipe.

​

Show a button only when it is relevant

An action’s three-dots menu carries Configure visibility, which opens Custom action visibility: Show <label> button when, followed by the same condition builder used elsewhere in Introw. Conditions read that record’s own properties, limited to the ones you exposed on this embed, and group with and / or. An action with no conditions is always shown, which is the default. Once an action has conditions, the list shows a small count beside it so you can see at a glance which buttons are conditional. A record whose only actions are all hidden shows no empty action bar at all. This is what turns a generic button into a stage-aware one. Request an order appears only from the stage where an order makes sense, and Update the deal disappears once the deal is Closed Won or Closed Lost, so partners are never invited to reopen a decision that is already made.

​

Collaborating from the CRM

With the Introw embed installed in HubSpot or Salesforce, your reps open the same collaboration view from inside the CRM record, so they never leave the tool they work in.

​

How-to guides

​

Troubleshooting