Skip to main content
Reference — how Restricted Opportunities work. Restricted Opportunities is available on the Enterprise plan and is enabled per organization by an Enterprise Admin.

What is Restricted Opportunities?

Restricted Opportunities lets your firm designate specific deals as restricted, so sensitive opportunities — like public-to-private (P2P) transactions — are visible only to the people who need to know. It’s built for private equity and other investment firms managing compliance requirements around information sharing, such as MNPI rules in the US or “need to know” regulations in Europe. When a deal is marked restricted, everyone with access to the list still sees that the row exists — so your pipeline counts and reporting stay accurate — but the opportunity name and all field values are masked for anyone not explicitly given access. No more choosing between a single source of truth for your pipeline and keeping sensitive deals contained to the right people.

Turning it on

Enterprise Admins enable Restricted Opportunities in Settings → Opportunities → Allowed Opportunity Types:
  • Toggle Restricted Opportunities on to allow their creation alongside open opportunities.
  • Toggle Open Opportunities off if every opportunity created in your instance should be restricted by default.
This setting controls which opportunity types are available when creating new opportunities — from lists, global navigation, or organization and person profiles.

How access works

Enterprise Admins (with the right permission)

Admins with the “Manage and view any Restricted Opportunity” permission see every restricted opportunity in your org, regardless of any deal’s allow list — a consistent safety net for your compliance or operations lead. It lives under Settings → Users and Permissions → Data Access and isn’t assignable to other roles.

Allow-list members

People or teams explicitly added to a specific restricted opportunity see full field values and can work with it normally — as long as they also have standard access to the Opportunity list it lives on. Both are required: allow-list membership alone isn’t enough.

Everyone else

Anyone else with list access sees that the row exists (to keep headcount and pipeline reporting accurate), but the name and every field value are masked, and the opportunity can’t be opened, edited, or interacted with.

Working with a restricted opportunity

If you’re an allow-list member or an Enterprise Admin, you can:
  • Mark an existing opportunity as restricted from an Opportunity List (New Lists — action menu or hover menu)
  • Create a new restricted opportunity from an Opportunity List, global navigation, or an org/person profile
  • Manage the allow list — add or remove individual users or teams, per opportunity
  • View and edit all field values; add notes, files, and reminders; and work with the opportunity normally across list views, Kanban, profiles, Notes Center, and Affinity Analytics
  • Find restricted opportunities via global search
  • Export opportunity lists with full restricted-opportunity data visible
If you’re not on the allow list, you will:
  • See restricted-opportunity rows in lists, Kanban, and Affinity Analytics — but every field value is masked
  • Be able to open the opportunity’s profile, but the content is obfuscated
  • Not be able to edit or interact with it
  • Not be able to find it via global search, association pickers, or a person/org profile’s opportunity list
  • See a row in exports, but every field value is blank

Where restriction applies

Restriction is enforced consistently everywhere deal data can be accessed:
Affinity Analytics follows the same allow list as the rest of the product — there’s no way to show a restricted opportunity in a dashboard while keeping it masked elsewhere, or vice versa.

Good to know

Use a code name instead of the target company’s name. Opportunity names must be unique within a list, and that check applies even to restricted opportunities — so someone without access who tries to create an opportunity with the same name will hit a naming conflict, which can tip them off that a restricted deal exists. Using a code name closes this gap completely, with no extra steps.
  • Basic (Legacy) Reporting must be disabled if you’re using Restricted Opportunities — restriction isn’t enforced there.
  • Database Share (Snowflake, Databricks) doesn’t enforce restriction. It includes all of your org’s Affinity data and doesn’t apply in-app permissions — grant access only to people who should see everything, and use your database’s own access controls to limit it further.
  • Introduction-related analytics counts on restricted-opportunity lists only include opportunities the viewer has access to. This is intentional: an accurate total would expose who’s connected to whom on a deal the viewer isn’t allowed to see. Other counts (list-entry counts, funnel-stage counts) reflect the full list.

Current limitations

  • Once an opportunity is marked restricted, it can’t currently be un-restricted.
  • Restricting an existing opportunity is only supported from Opportunity Lists (New Lists), not from its profile page.
  • Creating a restricted opportunity from an extension isn’t supported yet (viewing enforcement is live).
  • Not supported: creating restricted opportunities from Classic Lists, via Import, via Opportunity Triggers, or via Email Bot; and restricting individual fields rather than the whole opportunity.
  • Showing the opportunity name to non-allow-list users (instead of “Hidden”) isn’t a standard option — available only via a custom feature request.

Troubleshooting

It’s available on the Enterprise plan only. If you’re on Enterprise and still don’t see it, confirm with your admin that the feature has been turned on for your org.
Allow-list membership alone isn’t enough — they also need standard access to the Opportunity list itself.
This is by design. Rows are masked, not hidden, so your pipeline counts stay accurate. People without access see a row with blank values and a lock/eye indicator.
They should be able to. Confirm they have both allow-list access and standard access to the list. If both are in place and search still isn’t working, contact Affinity Support.

Coming soon

  • Syncing the allow list to a designated People field, so allowed members update automatically instead of being set manually.
  • A filter to hide restricted opportunities you don’t have access to in list view.
(No committed dates yet for either.)