One prompt produces a health check as a document you can send. This article gives you the baseline, the lines you can add to shape it, and the full client-ready version at the end.
Start with the baseline. Add lines only for what you actually need.
The baseline
Score this org's health out of 100 by domain and write it up for a client.
That returns a scored document with the evidence behind each domain, in about three minutes. For a quick internal read it is enough on its own.
Everything below is a line you add to it.
Narrow what it looks at
Scope it to one object. The deepest results come from pointing the scan at a single object rather than the whole org.
Focus on the ‹Opportunity› object.
Or to one area.
Cover only automation and code quality.
Name the domains when you want the same scorecard across several orgs, or when the report is a deliverable and the sections have to match last quarter's.
Score these seven domains and no others: Automation health worth 20 points, Security model worth 20, Object complexity worth 15, Code quality worth 15, Data integrity controls worth 10, Documentation and naming worth 10, Deprecation risk worth 10.
Left open, it picks the domains that fit your org, which surfaces things a fixed list would not have asked about. Named, you get the same scorecard every time, which is what you want when the report is a deliverable.
Change who it is for
The audience shapes depth and tone more than any other line you can add.
Write it for the client's own technical and business stakeholders.
Write it for a non-technical executive. Explain the risks in business terms, deal cycle time, reporting accuracy and audit exposure, rather than in Salesforce terms.
Write it for an admin who is new to this org and has to work through it.
Change how it is ranked
The ranking axis decides what lands at the top, so pick the one that matches the conversation you are about to have.
Rank by risk.
Quick wins first: order by what takes least effort for the most benefit.
Order by blast radius: what touches the most other components.
Order by what we could realistically fix this quarter.
Ask for more behind each finding
Name the components. Turns general advice into a checkable list.
Name the components behind every finding.
Get the queries alongside the numbers. You end up with a document and the SOQL to confirm anything in it, which is what makes it usable as a client deliverable rather than a read.
Flag any number worth confirming with a direct query, and give me the query.
Add the roadmap.
End with recommendations in three phases, sequenced so each is additive and reversible, with the rollback position for each.
Compare against last time.
Here is the assessment we ran in ‹March›: ‹paste the findings›. Show what has improved, what has got worse, and what is new.
Make it precise about your org
Platform ceilings depend on your Salesforce edition, so an assessment gets sharper when it knows yours. Telling it your edition and your real counts moves severities from approximate to exact: the same 259 custom fields is comfortable headroom under one ceiling and a genuine constraint under another.
Facts about this org, already verified. Use these exactly:
- Salesforce edition: ‹Enterprise›. The custom-object ceiling for this edition is ‹2000›. The custom-fields-per-object ceiling is ‹800›.
- Custom objects: ‹N›. Total customizable objects: ‹N›.
- ‹Opportunity› custom fields: ‹N›.
- Apex: ‹N› classes total, ‹N› of them native, ‹N› native test classes. ‹N› Apex triggers in total, of which ‹N› are native and ‹N› belong to managed packages.
- ‹Opportunity›: ‹N› validation rules, ‹N› of them active. ‹N› flow definitions, ‹N› active in total, ‹N› active and save-triggered, ‹N› inactive. ‹N› record types.
Getting those numbers
Run these in Developer Console, or ask the Assistant for them first and paste the results back:
SELECT COUNT() FROM EntityDefinition WHERE QualifiedApiName LIKE '%__c'
SELECT COUNT() FROM CustomField WHERE EntityDefinition.QualifiedApiName = 'Opportunity' AND NamespacePrefix = null
SELECT Name, NamespacePrefix FROM ApexClass
SELECT Name, NamespacePrefix, TableEnumOrId FROM ApexTrigger
SELECT ValidationName, Active FROM ValidationRule WHERE EntityDefinition.QualifiedApiName = 'Opportunity'
SELECT ApiName, IsActive, TriggerType FROM FlowDefinitionView WHERE TriggerObjectOrEventLabel = 'Opportunity'
In Developer Console's Query Editor, tick Use Tooling API for all of these except the last one. FlowDefinitionView is a standard object and will return "sObject type is not supported" if Tooling is on, while the other five return the same error if it is off.
Your edition is in Setup under Company Information, and the ceilings for it are in Salesforce's own limits documentation.
Change the format
Make it an HTML file so it's presentable to a client.
Give me the findings as a CSV so I can work through them in a spreadsheet.
Do not use em dashes or en dashes anywhere in the document. Use a comma, a colon or a full stop instead.
The full version
Everything above, assembled, plus the wording that keeps the counts and the scoring arithmetic exact. This is the one to use when the document is going to a client. Replace the bracketed values with your own, and paste your verified facts into the block.
Produce a Salesforce org assessment report for ‹Org name› as an HTML file, written for the client's own technical and business stakeholders to read.
Facts about this org, already verified. Use these exactly and do not derive your own versions of them:
- Salesforce edition: ‹Enterprise›. The custom-object ceiling for this edition is ‹2000›. The custom-fields-per-object ceiling is ‹800›. Do not cite any other ceiling for either.
- Custom objects: ‹N›. Total customizable objects: ‹N›. These are different numbers; when you state one, say which it is.
- ‹Opportunity› custom fields: ‹N›.
- Apex: ‹N› classes total, ‹N› native, ‹N› native test classes. ‹N› Apex triggers in total, of which ‹N› are native and ‹N› belong to managed packages, and ‹N› are on ‹Opportunity›.
- ‹Opportunity›: ‹N› validation rules, ‹N› active. ‹N› flow definitions, ‹N› active in total, ‹N› active and save-triggered, ‹N› inactive. ‹N› record types.
Structure it in these sections, in this order:
1. Executive Overview: what state the org is in and the three things that matter most.
2. Org Context: the size and shape of the configuration, stated as custom versus total.
3. Org Strengths: what is genuinely well built here, with component names.
4. Critical Findings, each with a severity, the components involved by name, the business impact of fixing it, and the risk of not fixing it.
5. Important Findings, the same shape at lower severity.
6. Scan Focus, the ‹Opportunity› object. Cover every validation rule gating stage progression, every save-triggered automation grouped by the package that owns it, the record types and their sales processes, and what that density means for save performance.
7. Health Score. Score the org out of 100 against exactly these seven weighted domains and no others: Automation health worth 20 points, Security model worth 20, Object complexity worth 15, Code quality worth 15, Data integrity controls worth 10, Documentation and naming worth 10, Deprecation risk worth 10. Letter bands: A is 90 or above, B is 80 to 89, C is 70 to 79, D is 60 to 69, F is below 60. For each domain give the score, the letter, the evidence you scored it on with component names, and the single highest-value improvement. Score each domain directly out of its own weight, so Automation health is scored out of 20 and Deprecation risk out of 10. The total is the plain sum of those seven numbers and nothing else. Do not convert, rescale or re-weight them. Before stating the total, list the seven scores on one line, add them up, and state the sum. Then give the letter band for that sum.
8. Recommendations and Roadmap: three phases, sequenced so each is additive and reversible, with the rollback position for each.
9. Appendix: the component inventories behind the findings, listed by name.
Rules for the whole document:
- Report any count as either custom or total, and say which. Never blend them.
- Use one number per fact throughout. If two sections mention the same limit or count, they must agree.
- Do not state that something is absent unless you have looked for it. Where you report none of something, give the query that establishes it.
- Rank findings by risk. Do not tell me the list is complete, and do not certify coverage.
- Flag any number that should be confirmed with a direct query before a client sees it, and give me the query.
- Stay inside what the metadata shows. Where a finding would need record data, licence counts or team structure, say what a consultant would have to confirm and move on.
- Where something depends on data you cannot see, put it in a 'needs a human to confirm' list with the SOQL that answers it.
- Do not use em dashes or en dashes anywhere in the document.
If you build your own prompt
The full version above ends with a short block of house rules. They are what keep the numbers consistent across a long document, so if you are assembling your own prompt rather than using that one, paste this on the end:
Report any count as either custom or total, and say which. Use one number per fact throughout, so any two sections mentioning the same count agree. Where you report none of something, give the query that establishes it. Rank by risk rather than claiming the list is complete. Where something depends on data you cannot see, put it in a 'needs a human to confirm' list with the SOQL that answers it. Flag any number worth confirming with a direct query, and give me the query.
After it runs
Ask for the full inventory separately when the client wants every item rather than the ranked findings. One focused call returns a complete list where the assessment returns the ranked subset:
List every validation rule on the ‹Opportunity› object, active and inactive, with its error message. Assessment only.
Drill into anything that looks wrong.
Tell me more about finding ‹CF-03›. Which components exactly, and what would the fix touch?
Re-aim it without regenerating.
Add a one-page executive summary at the front for a non-technical reader.
Say add to keep what is on screen and grow it. Say turn this into and it rewrites, replacing what was there.
For record data, ask for the query
Swantide reads your org's configuration, not the records inside it. So questions like how many accounts use a field, or which picklist values are actually chosen, come back as a query you run:
Write me the SOQL that answers ‹how many Opportunities have used each stage in the last year›, and tell me what to look for in the results.
Run it, paste the results back into the same conversation, and ask for the interpretation. That keeps the analysis in one document.