Restrict access by IP allowlist

An IP allowlist restricts your organization’s content to requests coming from networks you trust, typically your office egress IPs and your VPN. With a non-empty allowlist in place, members connecting from anywhere else get a clear “your IP is not in the allowlist” error instead of your data.

How it behaves

• The restriction applies to your organization’s content, for every member, on every surface: the web app and its live updates, API tokens, AI agents connected over MCP, report and schedule downloads, live wiki editing, and the notifications feed in the Onplana Tasks apps.
• Signing in and personal account settings are not organization-scoped, so a blocked member can still sign in; they just cannot reach your organization’s projects and data.
• A few things sit outside it: user provisioning from your identity provider (SCIM), public share links you create, and push notifications already set up on a phone.
• An empty list means no restriction. The control is off until you add at least one entry.

Configure the allowlist

1. Open Organization Settings and go to the Security & Compliance tab.

2. On the Controls sub-tab, find the IP Allowlist editor.

3. Add each address or range your team connects from. Individual IPv4 addresses (203.0.113.5), CIDR ranges (10.0.0.0/8), and IPv6 are all accepted. The editor shows your current IP address; select Add my IP to include it.

4. Save. The restriction takes effect immediately.

Caution

Onplana will not save a list that leaves out the IP address you are saving from, because your very next request would be blocked. Remote workers without a company VPN will still be locked out, so collect the full set of egress IPs first.

If you lock yourselves out

Any Owner or Admin connecting from a network that is still on the list can edit the allowlist and fix it. If nobody can reach the organization from an allowed network (for example, the office IP changed), contact Onplana support to restore access.

FAQs

Does the allowlist block sign-in? No. It blocks access to the organization’s content. Members can still sign in and manage their personal settings; they see the IP error when they try to open your organization.

Does it apply to API tokens and AI agents? Yes. Personal access tokens and agents connected over MCP go through the same check, so a CI job or agent running outside your allowed networks will be blocked too. Connectors that run in a vendor’s cloud, such as ChatGPT or Claude on the web, reach Onplana from that vendor’s network rather than yours, so they are blocked unless those addresses are on the list. Plan for that before enabling.

We use dynamic home IPs. Can we still use this? Only practically via a VPN: route remote workers through a VPN with a fixed egress IP and allowlist that. Listing residential IPs that change weekly is not maintainable.

Is allowlist activity recorded? Changes to the allowlist are written to the audit trail, see Read audit logs.

Best practices

1. Start with your current IP. The editor shows it, and a list without it will not save. Add it, then add more.
2. Use VPN egress IPs, not user home IPs. Home IPs change weekly. VPN egress is stable.
3. Document the allowlist purpose. “Office US-EAST: 203.0.113.0/24” beats “203.0.113.0/24”. Notes prevent accidental deletion.
4. Plan for CI + agents. Agents and CI jobs need allowlisted IPs too. Add their egress IPs before enabling.
5. Review quarterly. Office IPs change. VPN endpoints change. Periodic review prevents stale entries.

Troubleshooting / common pitfalls

• Save refused. The list left out your own IP. Select Add my IP and save again.
• Locked out after an IP change. An Owner or Admin on an allowed network can fix it. Otherwise contact support.
• Connector or hosted agent stopped working. It connects from its vendor’s network. Allowlist those addresses or remove the restriction.
• Member can sign in but can’t see data. Allowlist blocks organization content, not sign-in. Expected.
• API token rejected. Token request came from blocked IP. Allowlist agent/ CI egress.
• CIDR range syntax error. Use standard CIDR notation (10.0.0.0/8).
• IPv6 entries not matching. Verify IPv6 syntax + that user’s connection is actually IPv6.

How this combines with other features

• IP allowlist + API tokens. Tokens respect allowlist. See Create API tokens.
• IP allowlist + Agents. Agents respect allowlist, over MCP too. Allowlist agent egress IP.
• IP allowlist + Exports. Report and schedule downloads are checked like any other request.
• IP allowlist + Audit log. Changes to allowlist audit-logged.
• IP allowlist + SSO. SSO sign-in unaffected; organization access affected.

Coming from another tool

Tool	Mapping
Salesforce IP restrictions	Direct concept
Microsoft Conditional Access	Similar
Okta network zones	Direct
Custom firewall rules	Onplana adds app-level enforcement
AWS security groups	Adjacent concept

Related

• Read audit logs, allowlist changes
• Create API tokens, tokens respect allowlist
• Configure single sign-on, sign-in side