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 and every request, including API tokens and connected agents.
• 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.
• 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.

4. Save. The restriction takes effect immediately.

Caution

Add the network you are currently on before saving. If you save a list that does not include your own IP, your very next request is blocked along with everyone else’s. Remote workers without a company VPN will also 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. Requests authenticated with personal access tokens go through the same check, so a CI job or agent running outside your allowed networks will be blocked too. 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. Add your current IP BEFORE saving. Easy lockout pattern. Verify your IP is on the list, save, 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

• Saved allowlist, locked out. Owner on allowed network can fix. Otherwise contact support.
• Member can sign in but can’t see data. Allowlist blocks org 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. Allowlist agent egress IP.
• IP allowlist + Audit log. Changes to allowlist audit-logged.
• IP allowlist + SSO. SSO sign-in unaffected; org 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