What Fidelic can run
Your org is the real answer, and one command gives it to you. This is the general shape: what works, and where it differs from a real org.
The words on this page
- Works
- Your real Apex runs, and behaves as the org would.
- Mostly works
- Your real Apex runs, but something listed beside it is modelled rather than really done, or one corner of it is refused. The row says which.
- Not supported
- Refused by name, with a reason and a file and line. Never silently wrong.
| Capability | Status | Where it differs from a real org |
|---|---|---|
| Database operations insert, update, delete, upsert and partial success | Mostly works | Savepoints, Database.query and Database.merge are not supported. Everything else behaves as the org does. |
| Async jobs Queueable, @future, Schedulable, Batchable | Works | Jobs run inline as soon as the transaction commits, instead of being queued for later. |
| HTTP callouts HttpRequest and HttpResponse | Works | Callouts return whatever you register in the mock registry. Nothing reaches the network. |
| Schema and describe describe calls and permission checks | Mostly works | Describe answers only for the objects and fields you retrieved — it refuses rather than guessing. Permission checks always answer yes, because we do not model users. |
| Custom Settings and Metadata reads of both | Works | Org-default values only. Per-user and per-profile overrides are not modelled. |
| Events and email EventBus.publish and Messaging.sendEmail | Works | Events and emails are captured so you can assert on them, and never actually sent. |
| Crypto the Crypto namespace | Mostly works | Random numbers are seeded so your tests repeat. Hashing, signatures and encryption are not supported. |
Anything not listed is refused rather than guessed at: you get the file, the line, and the construct we do not support. Refusing is the point — a wrong answer you cannot see is worse than a gap you can plan around.
The answer for your org
A general table cannot tell you whether your code runs; that depends on what your triggers actually do. Point the analyzer at your metadata and it grades every trigger you have, naming the reason for each refusal:
docker run --rm -v "$PWD/mdapi":/mdapi:ro \
--entrypoint /sfapex fidelic/emulator coverage --report /mdapiNothing leaves your machine — it reads local files and makes no network calls. The report is plain text, built for pasting into a channel.
Your coverage report uses more precise words for the same ideas — EXECUTE, SIMULATED, UNRESOLVED — and defines each one alongside the numbers behind this page.