Your first flights

How to judge any answer

The Copilot works from built-in guides (we call them recipes). Each one fixes the steps, the questions it may ask your system, and the shape of the answer. You do not name a recipe: you describe the job, and the Copilot uses the one that fits. Every recipe in this chapter is read-only: it reads and explains, and never offers to change anything.

7.1 The first question

Before the guides, prove the connection returns real data.

A good answer reports real numbers from the org's limits and says which are nearly used. In a new org, nothing will be close. The API meter above the message box then shows your calls this run.

Then one question per connected system. Note each result on your checklist:

7.2 Explain a debug log

Needs: nothing connected. It reads only what you paste. It touches no system.

To try it without a real log, paste these made-up lines:

• A good answer, in this order: one plain sentence with the cause; a table of limit, used and allowed (only limits in your paste; any at 80 percent or more flagged); the top three suspects, each with a log line number or a class and line; the usual fix. It says which part is your paste and which part is its reasoning.
• For a SOQL limit, the usual cause is a query inside a loop, and the usual fix is to query once into a Map.
• If the error is not one it recognises, it says "not recognised", says what it can read, and asks for the missing part.

Check: every suspect cites a line you can see in your paste. It does not name a class the paste does not show. It does not offer to fetch the log itself.

7.3 Org tour

Needs: a connected Salesforce org. A guided walk through an org you have just inherited, in about ten minutes of reading.

• A good answer goes in seven steps and stops after each with one line asking whether to go on: org summary and licences; data model; automation; integration surface (installed packages, named credentials); limits; security risks; and what changed in the last 30 days. It uses the same sections as the Org Discovery Report (7.10).
• Each step is two or three plain sentences, a small table if it helps, and what it means for someone taking over.
• It ends with Five things to read first and Three things that look risky, naming only things it read. On a small org it gives fewer and says the tour cannot show business rules that are not written down.
• A part it cannot read is listed as "not readable with your access" in its step and again at the end.

Check: pick one named object or flow and find it in Setup. It should be there. It should not call anything a bug.

7.4 Async job doctor

Needs: a connected Salesforce org. Finds background work that has quietly failed.

• A good answer starts with one sentence (for example "3 classes failed in the last 7 days and 1 schedule looks stuck", or "nothing failed in the last 7 days"), then a table of job, failures, last error and last success, then any stuck schedules. A schedule is flagged when it should have run and did not, or is in an error or blocked state.
• It counts what it can see and says so. It always lists what it did not check: failed Flow interviews, fault emails, platform event delivery and email send errors, which need Event Monitoring or admin settings. It never says the org is healthy about those.
• It never offers to abort, reschedule, retry or change a job.

Check: in Setup, open Apex Jobs and compare the failures it names. A new Developer org will normally answer "nothing failed", which is correct.

7.5 Licence, storage and idle-user review

Needs: a connected Salesforce org.

• A good answer gives a table of licence, used, total and free, largest free first (rows with a total of 0 left out); idle users who have not logged in for 90 days, oldest first, up to 20, with the total, and users who never logged in; and storage as used = Max minus Remaining, with the percent used, from the org's limits.
• It calls idle users "candidates to ask about", because they may be integration or seasonal users. It does not tell you to remove anyone.
• For storage per object it can only count records on a few objects and says its space figure is an estimate (Salesforce counts most records as about 2 KB).
• It does not state or guess what a licence or a gigabyte costs, unless you give it a price.

Check: compare the licence table with Setup, Company Information. Compare the storage figures with Setup, Storage Usage.

7.6 Who can edit a field

Needs: a connected Salesforce org and a user in it. In a new Developer org, use your own admin user or a user you create.

• A good answer gives the deciding reason first in one line, then the chain: who the user is (profile, role, active or not), each profile, permission set or permission set group that grants something, and what is missing if the answer is no. Editing a field needs Edit on the object and Edit on the field.
• If more than one user matches the name, it lists them and asks which. If the user is inactive, it says so and stops.
• For a grant that arrives through a permission set group, it says "granted through the group X unless the group mutes it", because muting is not evaluated.
• It always says "Record-level sharing was not evaluated". Object and field access say whether the user can edit the field at all, not which records they can see.

Check: open the user in Setup, then the permission sets and the field's field-level security, and confirm the chain.

7.7 Sandbox refresh checklist

Needs: a connected Salesforce sandbox. It lists what to note before a sandbox refresh and checks what is left after it. A person does the refresh in Setup; the Copilot cannot start or schedule one.

• Before: one table per area (named credentials, external data sources, remote site settings, outbound messages, scheduled jobs, connected apps, custom settings) with what, name, the value to note and what to do. Then a manual list of things the API cannot give, each with where to look in Setup. Anything it could not read is on the manual list, not guessed.
• After: the same reads again. It asks which production hosts your integrations point at, then flags any endpoint whose host equals a production host as pointing at production, and lists same-domain hosts as "check". If you decline to name hosts, it lists every host and says nothing was compared.
• Nothing is stored beyond the chat: copy the "before" table somewhere safe, and paste it back in the "after" chat.

Check: the "after" run flags nothing for an integration you know still points at its sandbox endpoint.

7.8 Pull request review

Needs: GitHub connected, and a pull request in a repository the connected user can see. It reviews the Apex and Flow files of one pull request against a fixed checklist of ten rules.

• A good answer lists findings, high severity first. Each has the rule (R1 to R10), the severity, the repository, the file path, the short head sha, the line range, the line quoted exactly, why it matters in one sentence and the fix. For the class above, expect R1 (a query inside a loop) and R2 (a data change inside a loop), and probably R5 (no sharing keyword).
• It reviews only Apex, trigger and Flow files and names the other changed files as not reviewed. It says how many pages of files it did not read.
• No findings is a valid answer: "No findings from the ten rules in the files I read", with the files listed.
• It never posts a comment, approves, or requests changes, and never calls the pull request safe: it read a diff, it did not run it.

Check: open the file at the sha it names and compare the quoted line and its number. If the line number matters and it was unsure, it should have confirmed with a file read before citing it.

7.9 Pull request description and release notes

Needs: GitHub connected. It writes text in the chat for you to paste. It cannot put it into the pull request.

• A good answer uses the repository's pull request template if it has one, keeping its headings in order, and leaves every checkbox unticked with "to be ticked by the author". Without a template: Summary, Components changed (each changed file in exactly one section, such as Apex classes, Flows or Tests), Risk (low, medium or high, with the reason, stated as its judgement), Test plan and Deploy notes.
• It never says a test ran or passed unless a tool result says so. It names a ticket only if the key is in the title, description or a commit message.
• Deploy notes contain only what the file types support. A file named destructiveChanges removes components and is called out first.
• It says in one line what the text cannot know: it describes the diff and messages, not what was run or what is in the org.

Check: count the changed files on GitHub against the files listed in the answer. The guide tells the Copilot to make them match.

7.10 The Org Discovery Report

Needs: a connected Salesforce org, and the report switched on for your environment. It reads the org once, within a fixed call limit, and writes a report into a chat. It changes nothing in Salesforce.

• The report states its date. A part the connected user cannot read is marked not readable with your access; a part skipped because the report reached its call limit, or to protect your API allowance, says so.
• Afterwards, ask follow-up questions in the same chat. The Copilot quotes the report's numbers and does not recompute them. For anything newer, it uses its tools and says the report may be out of date.

Check: compare the date and two numbers (for example the count of custom objects) with Setup.

7.11 More guides

These work the same way: read-only, honest about what they could not read, and never offering to change anything. Try them after the nine above.