DML operation Insert not allowed on CorsWhitelistEntry
Someone hands you a two-line Apex snippet to allowlist an origin. It works in their org and fails in yours. Nothing is wrong with the snippet — setup objects just don't behave like normal ones.
The path that always works
Skip Apex. Do it in Setup, where the platform expects this change to be made. Two entries, one org, roughly two minutes.
1. Allowed Origins (CORS)
Setup → quick-find CORS → Allowed Origins List → New → enter the origin → Save.
2. CSP Trusted Sites
Setup → quick-find CSP Trusted Sites → New → same URL, Context All, Active checked → Save.
Enter the origin only — scheme and host, nothing else. https://example.com is right. https://example.com/ with a trailing slash, or anything with a path, is the single most common reason an entry looks saved and still doesn't work.
Why the Apex shortcut fails in some orgs
CorsWhitelistEntry is a setup object, not an ordinary sObject. Salesforce restricts DML against setup objects, and the platform is not uniform about which setup objects accept inserts from Anonymous Apex. Behaviour varies by org configuration and by release, which is exactly why the same script that worked for your colleague throws in front of you.
This is also why the failure is a System.TypeException rather than a permissions error. It isn't telling you that you lack rights; it's telling you the operation isn't a permitted operation on that type in that context. Adding permissions won't change it, and neither will running as a different admin.
There's a related constraint worth knowing while you're here: setup and non-setup objects can't be modified in the same transaction. If you ever do get DML on a setup object working, keep it in its own transaction rather than mixing it with ordinary record changes, or you'll trade this error for a mixed-DML one.
The snippet, for orgs that do allow it
Plenty of orgs run it happily. If yours is one, this saves a minute — and if it throws, you've lost nothing, so it's a reasonable thing to try first as long as you know the fallback.
Run it in Setup → Developer Console → Debug → Execute Anonymous. If you see the type exception, use the Setup UI instead — the outcome is identical.
Why Salesforce asks for this at all
The question underneath the error is usually: why does this tool need me to change a security setting when other tools don't? Fair question, and the answer is architectural rather than about trust.
Browsers enforce the same-origin policy. A page served from one domain cannot make arbitrary calls to another domain unless that other domain says it's allowed. When a browser-based tool calls your Salesforce APIs directly, your org is the second domain — so your org has to declare that it permits requests from that origin. Salesforce is deliberately routing that decision through an administrator.
| Tool type | Why CORS may not come up |
|---|---|
| Chrome extension | Runs with extension privileges, outside the page's origin restrictions. |
| Server-backed SaaS | Calls happen server to server, so the browser rule never applies — but your token reaches their server. |
| Managed package | Code executes inside your org, so there is no cross-origin call. |
| Direct browser tool | Genuinely cross-origin, so the org must allowlist it — the token goes straight from your browser to your org. |
Seen that way, the CORS prompt is the visible cost of an architecture where your access token stays in your own browser. The tools that don't ask are usually not asking because the token went somewhere else.
Troubleshooting a setup that still fails
- Trailing slash or path in the entry. Remove them. Origin only.
- Only one of the two entries added. Add both CORS and CSP Trusted Sites.
- Wrong org. Sandboxes and production are separate. Each needs its own entry, including every refreshed sandbox.
- Propagation. Give it a minute, then hard-refresh the tool.
- Scheme mismatch.
httpsandhttpare different origins. - Subdomain assumptions. An entry for a host does not automatically cover its subdomains unless you used a wildcard pattern.
Frequently asked
Can I remove the entry afterwards?
Yes. Delete it from the Allowed Origins List and the tool loses browser access immediately. Nothing persists on the tool's side.
Does this need to be repeated per sandbox?
Yes, and after every sandbox refresh, since a refresh restores configuration from production.
Is a wildcard origin safe?
Prefer an exact origin. A broad wildcard widens what the browser will permit for no benefit if you only use one site.
Why does the tool still fail with CORS configured correctly?
Check whether the failure is genuinely CORS. An expired OAuth token, a missing scope, or an API version issue can look similar in a console. The browser network tab distinguishes them: a true CORS block names the policy explicitly.
Is there a way to avoid CORS setup entirely?
Only by having something other than your browser make the call — an extension, or a server-side proxy. Both are legitimate; both change where your token goes, which is the trade-off worth being deliberate about.
Where OrgKit fits
OrgKit needs one CORS entry per org and it covers every tool on the site. If your org blocks the Apex shortcut, the Setup steps are shown at the point of failure rather than buried in documentation. There's also an opt-in relay for orgs where you can't add the entry at all — off by default, stateless, and disclosed in full on the trust page.
Free, runs in the browser, nothing stored server-side.
Read how OrgKit handles your token