Skip to main content

SF-0301 · Concept · Easy

What is an anonymous Block?

✓ Verified by Vikas Singhal · Last reviewed 5/17/2026 · Updated for Spring '26

An anonymous Apex block — sometimes called Anonymous Apex or Execute Anonymous — is a snippet of code you run against an org without saving it to the org. There’s no class, no trigger, no test method. You paste it, hit run, see the output. When the transaction returns, the code is gone.

It’s one of the most-used Salesforce developer tools, primarily for: ad-hoc data lookups, one-off fixes, prototyping logic before committing it, and running quick diagnostic queries against production.

How to run it

Three places, same engine underneath:

  • Developer Console → Debug → Open Execute Anonymous Window (Ctrl+E).
  • VS Code → command palette → “SFDX: Execute Anonymous Apex” (or run a .apex file).
  • Salesforce CLI → sf apex run --file fix.apex --target-org my-prod.

A minimal example

// Fix the rating on a single account
Account a = [SELECT Id, Rating FROM Account WHERE Name = 'Acme' LIMIT 1];
a.Rating = 'Hot';
update a;
System.debug('Updated ' + a.Id);

Paste, run, done. No test class, no deployment, no metadata change.

What it can do

Pretty much everything Apex can do in a class:

  • Run SOQL and SOSL.
  • Insert/update/delete records.
  • Call methods on existing classes.
  • Make HTTP callouts (within the same transaction rules).
  • Enqueue Queueable / Batch / Future jobs.
  • Publish Platform Events.
  • Read and write Custom Settings.

What it can’t do

  • Define a class or method that persists. You can declare a class inside the block, but it vanishes when the transaction ends.
  • Modify metadata (custom fields, validation rules) — that’s the Metadata API, not Apex.
  • Skip governor limits. A single anonymous block is one transaction with the standard sync limits: 100 SOQL, 10,000-row DML, 10 s CPU.
  • Get formal version control. Saving a .apex file in your repo helps but it’s not deployed metadata.

What runs in an anonymous block

The block runs as the user who invoked it, with that user’s sharing and FLS rules — unless you wrap the logic in a class with without sharing. Importantly, you cannot mark the block itself with sharing / without sharing; that’s a class declaration only.

Common production use cases

  • Data fix for a single bad record: 
    Account a = [SELECT Id FROM Account WHERE Name = 'OldCorp' LIMIT 1];
a.Name = 'NewCorp';
update a;
  • Trigger one-off of a Batch / Queueable: 
    Database.executeBatch(new AccountRefreshBatch(), 200);
  • Inspect governor state: 
    System.debug('SOQL used: ' + Limits.getQueries());
  • Verify before deploy: 
    Integer cnt = [SELECT COUNT() FROM Account WHERE Industry = null];
System.debug('Accounts missing industry: ' + cnt);
  • Enqueue a reminder for testing: 
    System.schedule('once', '0 0 9 ? * *', new ReminderScheduler());

Risks

Anonymous Apex bypasses the entire deployment review process. In production, this is the tool senior developers use carefully:

  • No code review.
  • No test runs against it.
  • No audit trail for the script itself (only its DML).
  • Errors don’t roll back changes made by update/insert statements before the failure unless you wrap in try/catch with a Database.setSavepoint().

Many orgs require a peer-review step before anyone runs anonymous Apex in production — the script lives in a scripts/ folder in the repo, gets reviewed, then someone with prod access runs it.

Debugging tips

System.debug() output in an anonymous block goes to the Developer Console log just like any other Apex transaction. If you don’t see your debugs:

  • Check the trace flag for your user is enabled and the level is DEBUG or finer.
  • The Developer Console runs at FINE by default — usually enough.
  • For larger logs, raise the Apex Code level to FINEST in your trace flag.

What interviewers are really looking for

The naming check: “code run from Developer Console without saving to the org.” Strong signals: (1) it’s subject to all governor limits like any Apex, (2) it’s the right tool for ad-hoc data fixes and prototyping, the wrong tool for repeated business logic (that belongs in a class), (3) CLI invocation (sf apex run --file ...) is the modern way to keep these scripts in source control, (4) no metadata changes — anonymous Apex cannot add fields or validation rules.

Verified against: Apex Developer Guide — Anonymous Blocks, Salesforce CLI — sf apex run. Last reviewed 2026-05-17.