> ## 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.
# August 2026
> August 2026 releases: the Workflows canvas, conditional visibility on forms and shared deals, persisted segment membership, one organisation-wide default for permissions and notifications, per-platform partner chat, CRM-backed MDF objects, and free API credits on every plan.
> August shipped in two halves. The first made partner governance readable: one organisation-wide default that segments override only when you say so. The second made the program act on its own, with a Workflows canvas you build your automations on and conditional rules that decide what a partner sees.
June made segments the one audience model. July put the partner's own tools at the centre. August did both ends of the same job. Early in the month the answer to "what does this partner actually get, and why" became a three-layer cascade you can read on one screen. Later in the month that same model became something you can act on: a workflow watches for a change and does the work, and a form field or a deal action can decide for itself whether it belongs on screen. Both halves are the [low total cost of ownership](/why/low-tco) bet, which is that the person who understands the program is the person who should be able to change it.
### Build your own automations on a canvas
Introw automated a lot already: partners detect themselves from CRM filters, segments keep themselves current, forms write your CRM records, notifications and nudges go out. What it could not do was the handful of rules that are specific to your program, the ones that live in a partner manager's head. **Workflows** is where you build those, on a canvas, with no code.
You pick a trigger from twelve of them: a task assigned or completed, a journey started or finished, a course started or finished, a certificate earned, a partner or contact created or updated, or a partner entering or leaving a segment. You narrow it to the partners and events you actually mean, with segments or the partner's own Introw and CRM fields for the partners, and conditions on the event's own fields for the events. Then you lay out what happens: write fields on the partner, move them to another portal experience, add them to a segment, enroll them in a journey, give them or your own team a task, issue a certificate, book a commission line, email their contacts, post a Slack or Teams nudge, or log a note on their CRM record.
Between those actions you can wait and you can branch. A wait can be a plain pause or it can be anchored to a due date, which is what makes "three days before it is due" expressible at all, because that instant is not knowable when you write the workflow and it moves when someone edits the date.
So the reminder chain everyone builds by hand becomes one workflow: nudge the partner before the deadline, nudge again after it slips, escalate to the partner manager, and check at every step whether the work has since been done.
Nothing goes live by accident. A workflow saves as a draft, Introw tells you which node is unfinished, you rehearse it against one real partner without writing anything, and every run afterwards is painted back onto the same canvas so you can see the path a partner took. Building the program's own rules without a consultant, a dev ticket, or a roadmap queue is the [low total cost of ownership](/why/low-tco) bet at its most direct, and getting the first one live in an afternoon is [time to value](/why/time-to-value). This first version carries a subset of what is coming and is being switched on per organisation, so ask your Introw contact if **Workflows** is not yet in your navigation. See [Workflows](/features/automation/workflows/technical) and [Chase a task to its due date and escalate](/features/automation/workflows/guides/chase-a-task-to-its-due-date).
Before you build anything, it is worth reading what already runs without a workflow: [Every automation that runs out of the box](/features/automation/built-in-automation/guides/every-automation-that-runs-out-of-the-box).
### Fields and deal actions that decide for themselves
A form field can now be shown only when other answers on the same form match a rule. Open the field, add one or more visibility conditions pointing at sibling fields, and the field appears when they match. Fields with conditions carry a **Conditional** pill in the builder so the branching is visible without opening anything.
Two things make this more useful than a show-and-hide toggle. Required follows visibility, so a field marked required is only enforced while it is on screen, which is how "State is required, but only for US" and "answer A or B" become buildable rather than aspirational. And conditions chain, so hiding a field hides everything that depended on its answer, and a stage to reason to sub-reason cascade collapses in one step instead of leaving orphaned questions behind. The same rules run in all three places a submission can come from: the form the partner sees, the validation on submit, and the CSV batch upload. A hidden field is never submitted, never validated, and never written to your CRM.
The same idea reached shared deals. Each custom action button on a shared deal can carry conditions on that deal's CRM properties, so **Update deal** can disappear once the deal is Closed Won and **Request order** can appear only from the stage where it makes sense. A deal whose only action is hidden shows no empty action bar.
Put the two halves together and you can write a real rule onto a partner's pipeline: partners may move a deal forward, may close it lost as long as they say why, and never close it won. See [Pipeline rules](/release-notes/pipeline-rules) for how the controls compose, and [Let partners update a deal with guardrails](/features/co-selling/shared-pipelines/guides/let-partners-update-a-deal-with-guardrails) for the build.
Conditional visibility is a relevance feature, not an access-control or security one. It decides what is worth showing, and it should never be described or sold as a permission. What a partner is allowed to see and do is governed by [segments and permissions](/features/partners/segments/technical); on a shared deal, conditions apply to custom action buttons only and do not lock the deal, its stage, or its properties.
Asking partners twelve questions to collect four is how a deal registration form gets abandoned, so cutting a long form down to the branch that applies is worth real submitted deals. Configuring that yourself, per form and per deal action, is the [low total cost of ownership](/why/low-tco) bet applied to the forms your program runs on. See [Show fields conditionally](/features/forms/form-builder/guides/show-fields-conditionally) and [Shared pipelines](/features/co-selling/shared-pipelines/technical).
### One default, and overrides you opted into
Partner permissions and email notifications now resolve through one cascade: an organisation-wide **All partners** default, then only the segments that switched on **Override the default for this segment**, then the contact's own opt-outs. The default is pinned as the first row of your segments table and opens its own **Default settings** editor, so you no longer create a conditionless segment to stand in for "everyone".
The practical change is that a segment carries nothing until you say it does. Creating one to target an announcement used to be able to switch notifications back on for your whole program; now it has no side effects at all. That holds per setting, not just per segment: a segment states a permission only when you move it off the default value, so one that grants invites says nothing about record visibility and cannot change it by accident.
Where a segment does state something, that value replaces the default in either direction. Where a contact matches several segments that disagree, the most permissive one wins on every setting, so qualifying for more groups never takes a capability away. Both columns on the segments list are a live diff against the current default, so a segment that changes nothing reads **Default** and a segment that changes something tells you exactly what, and auditing forty segments is one screen rather than forty.
The two permissions were rebuilt as cards that state the rule, list what it means in practice, and preview the partner-side result as you toggle them, and both were renamed to read as grants: **Invite colleagues** and **See all shared records**. Seeing the partner's portal move as you flip a switch removes the change-publish-impersonate-check round trip, which is the [low total cost of ownership](/why/low-tco) bet applied to configuration. Governance that stays legible as your segment count grows is the [enterprise-grade](/why/enterprise-grade) bet applied to the same place.
Walk it yourself, from the pinned default through to a segment that has the override switched on:
Read the full change, including what we migrated for you and what to check: [Segment defaults and overrides](/release-notes/segment-defaults-and-overrides). See also [Segments](/features/partners/segments/technical) and [Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
### Partner chat is its own system now, per platform
Which partner events reach a partner's Slack or Teams channel used to ride on the same per-event checkbox as email. It is now configured on the chat integration itself, on its **Partner channels** tab, one setting per platform.
That split is deliberate rather than cosmetic. An email is addressed to a person, so it takes the full cascade including that contact's own preference; a chat channel belongs to a whole partner organisation, so it has no per-person layer and its config belongs with the integration that owns the channel. The upside is immediate for anyone running both platforms: Slack and Teams can now differ, which one shared checkbox could never express. See [Channels](/features/engagement/channels/technical) and [Control who gets notified](/features/engagement/notifications/guides/control-who-gets-notified).
### Why a contact gets what they get
A partner contact's **Notifications** tab is now a derived view that shows its own reasoning. A card at the top walks the three layers for that contact: how many events the default leaves on, which override segments they matched and how many events each decides, and how many they opted out of themselves, each segment a link straight to it. Every event row carries a badge naming the layer that decided it, and rows your policy switched off are locked with a tooltip saying which layer locked them.
Only the contact's own opt-outs are editable there, which is the honest version of that screen: it used to offer toggles that could not actually grant anything. The rule is enforced on save, not just hidden in the interface, so no screen can record an opinion on an event a higher layer owns.
### Segment membership is stored, not recalculated on every read
Segment membership used to be worked out from scratch every time something asked. It is now a stored snapshot that Introw keeps in step as segments and partner data change, and every product read comes off it: portal access gates, the counts on the segments list, and everything scoped to a segment. The builder's own preview still evaluates live, so what you see while writing conditions is the current answer.
The reason to care is what happens at scale. A gating read on a portal page load no longer costs more because your organisation has more partners in it, which is the difference between a portal that stays fast at three thousand partners and one that degrades as the program succeeds. That is the [enterprise-grade](/why/enterprise-grade) bet in the least glamorous and most useful place.
Two behaviour changes came with it, both worth knowing before you audit your own segments. A static segment that hand-picks contacts **and** carries a partner filter now requires the contact row: a contact you deliberately left out no longer gets in through their partner. Segments that only enroll partners are unaffected, and all of that partner's contacts still match. And a notification lock set by a segment now applies to a brand-new invitee at the moment they are invited, rather than being dropped because their row was a fraction of a second old. See [Segments](/features/partners/segments/technical) and [Layer segments to progressively unlock capabilities](/features/partners/segments/guides/layer-segments-to-progressively-unlock).
### Channel conflict arrives with the notification
When a partner submission overlaps a deal already in your CRM, the AI's assessment no longer waits for someone to open the Submissions inbox. The **Form submitted** notification your reviewers already receive leads with a **Channel conflict** section carrying the assessment and recommendation, and its button reads **Resolve conflict** instead of **View submission**.
Conflict is time-sensitive in a way most notifications are not: the cost of finding out late is a partner dispute, not a slow reply. It reaches your internal reviewers and internal chat channels only, never a channel shared with the partner who submitted. Detection and triage are the agent's; the decision stays with your team, which is the [AI-native](/why/ai-native) bet with the human where it belongs. See [Catch and resolve channel conflict](/features/ai/channel-conflict/guides/catch-and-resolve-channel-conflict).
### MDF requests and claims can live on your own CRM objects
If your finance team already tracks marketing funding on a CRM object of their own, Introw can now use it instead of its own. Point **MDF requests**, **MDF claims**, or both at one of your HubSpot or Salesforce objects and that object owns the record end to end: its schema, its properties, its record creation, and its label, which then replaces "MDF Request" everywhere the object is picked.
Introw keeps running the program on top, so a CRM-backed object gets two extra pieces of setup: object linking, so its records attribute to the submitting partner, and a field mapping, so the fund budgets, the ROI and Claims bars, and the timeline deadlines read the right properties. Not forcing a program onto Introw's data model when the customer already has one is the [CRM-native](/why/crm-native) bet at its most literal. See [Store MDF requests and claims in your CRM](/features/mdf/funds-allocation/guides/store-mdf-requests-and-claims-in-your-crm).
### Affiliate links provision themselves
A partner who could see an affiliate section but had no link to share was the most common way an affiliate program quietly failed. Links are now minted automatically: publishing an experience that carries a campaign's affiliate block gives every partner in that publish a link, and a partner who opens the block without one gets it created on the spot, so campaigns and portals that predate this heal themselves without a republish.
Both routes are safe to repeat, never issue a second link, and never reissue a link you revoked. **Generate links** stays on the campaign for pre-provisioning partners you want to reach before they ever open the portal. See [Launch an affiliate campaign](/features/affiliate/campaigns/guides/launch-an-affiliate-campaign).
### The CRM connection tells you who it runs as
A CRM integration's detail header now names the **CRM user** the OAuth grant authenticates as, with their id, the portal or instance it points at, and the connection date behind it. That is the identity every Introw call to your CRM runs under, so it is the first thing to check when an object syncs for some records and not others, or a write-back silently does nothing, and it is how you confirm a connection is on your dedicated integration user rather than whoever happened to click connect.
**Reconnect** is now always available rather than appearing only once something breaks, so moving a connection to a different user is self-serve. It and **Disconnect** moved into a three-dots menu, leaving the header one call to action. See [Troubleshoot a CRM connection](/features/integrations/crm/guides/troubleshoot-a-crm-connection).
### Videos in forms
The form builder's **Add to form** menu, and the `/` command inside the form body, now offer **YouTube**, **Loom**, **Vimeo**, and **Vidyard** embeds, plus **Embed other** for anything else. A deal registration form can carry the thirty-second explainer of what qualifies, where it gets read, instead of in an enablement email nobody opens. See [Build and publish a form](/features/forms/form-builder/guides/build-and-publish-a-form).
### Free API credits on every plan
Every Introw plan now includes API access with a **free monthly allowance of API credits**. There is no add-on to buy and no commercial conversation to have first: create a scoped key in **Settings > Developers > API keys** and start calling. The allowance belongs to your organisation rather than to your plan, so an integration that outgrows it can have it raised without changing anything else you pay for.
The Developers sidebar now carries an **API Credits** bar showing the share of this month's allowance you have spent, and clicking it gives you the date your credits reset, in UTC. Integrations get the absolute numbers where they can act on them instead: every metered response carries your allowance and what is left of it, and once the allowance is spent, requests return `402` with the reset time rather than failing vaguely.
Being able to build against the API before anyone signs anything is the [low-TCO](/why/low-tco) bet applied to the platform: the building block is there when your team needs it, not after a procurement cycle. See [API Keys & REST API](/features/developer/api), [API credits](/general/api-credits), and [Authentication](/general/authentication).
### Table reports, and record tables on a dashboard
A report's **table** visualization now renders the report's own records with the columns you pick on the **Data** tab, rather than a two-column summary of a grouping and a metric. So "the deals my partners registered this quarter" can be a dashboard tile that lists the deals, instead of a chart you have to click through to reach them.
It is the same table the Data tab and the chart drilldown already showed, which is the point: one table, one set of columns, one query, wherever it appears. Because a table aggregates nothing, its **Configure** tab drops Metric, X-axis and Breakdown and sends you to the **Data** tab where the columns actually live. Getting the underlying CRM records onto a dashboard, with your own columns, rather than only a rolled-up number, is the [CRM-native](/why/crm-native) bet applied to reporting. See [Report builder](/features/reporting/report-builder/technical) and [Build a dashboard](/features/reporting/dashboards/guides/build-a-dashboard).
The partner data source stays off partner-facing surfaces. A table report on your partner roster is organisation-only data, so a partner viewing a dashboard gets an explanation rather than a list of your other partners.
### Also in this release
* **The invite permission holds everywhere.** **Invite colleagues** is now enforced on every route a partner has to add someone, including their own team page at partners.introw\.io, where the action explains why it is unavailable rather than failing after the fact.
* **Archiving a segment stops it applying immediately**, its grants and its restrictions alike, so the default decides for its members again. Restoring brings its policy back with its targeting.
* **An override segment has to target a subset.** A dynamic segment with no conditions matches everyone, so it can no longer set policy for your whole program. It keeps working for targeting announcements, tabs, assets, courses, forms, and reports.
* **Partner Notifications became a report.** It still tells you what went out, who it reached, and what they did with it, and it now says in a banner where recipients are configured instead of offering a second place to write them.
* **A returned submission can actually be resubmitted.** Returning a submission asks the partner to revise it, and the notification deep-links them into it, but the partner had no way to edit from there. The submission now carries a returned-for-changes card with **Update and resubmit**, and saving the revision puts it back in your queue. See [Run a submission approval workflow](/features/forms/submissions-approvals/guides/run-a-submission-approval-workflow).
* **Team role and CRM owner columns are editable on the partners list.** Pick the person straight in the column, with the same picker and replace-confirmation the bulk edit and the partner's own team dialog use, instead of opening each partner. Covers linked team roles and CRM owner fields on either CRM. See [Wire partner ownership](/features/partners/team/guides/wire-partner-ownership).
* **Goals follow your fiscal year.** Yearly and quarterly KPI periods now bucket on your organisation's fiscal year start, so a February to January goal is one FY2026 column rather than being split across two calendar years. Calendar-year organisations are unchanged. See [Launch a partner goal](/features/reporting/goals/guides/launch-a-partner-goal).
* **A CRM event that omits a property no longer clears it.** A sync payload that simply did not mention a partner's tier was being read as "clear the tier". An omitted property is now left alone, and only a stated empty value clears one. See [CRM integrations](/features/integrations/crm/technical).
* **Deleting a form field no longer wipes that form's CRM automation.** Removing one field used to take the form's CRM object mapping with it. See [CRM automations](/features/forms/crm-automations/technical).
* **SCORM scores show on portal course cards.** A SCORM module's reported score now appears where partners see their progress, instead of only inside the player. See [Progress tracking](/features/courses/progress-tracking/technical).
* **Files uploaded through a form are clickable in the activity feed.** The filename links to the file rather than reading as plain text. See [Sharing and submitting](/features/forms/sharing-submitting/technical).
* **The asset library filters by access level**, so you can pull up everything restricted, or everything public, while auditing what partners can reach. See [Build the asset library](/features/content/asset-library/guides/build-the-asset-library).
* **Announcements and Tasks columns are customized the same way as Assets.** One **Configure** control across the three lists rather than three different affordances.
* **Pipedrive record search covers the whole CRM.** Searching for a record now queries Pipedrive by your search term instead of filtering the first few hundred records it had already loaded. See [Connect Pipedrive](/features/integrations/crm/guides/connect-pipedrive).