Want a clear, prioritized picture of the technical debt in your Salesforce org? This guide is a ready-to-use library of AI Assistant prompts that walks your org through a full health inspection — automation, Apex, security, data model, validation rules, UI, reporting, documentation, and packages — and ends with a prioritized remediation roadmap.
Each prompt is copy-paste ready. Run them in the AI Assistant, one domain per conversation, and you'll finish with a ranked list of what to clean up, why it matters, and how much effort each fix takes.
How to get the best results
Run one domain per chat. Each scan below is self-contained. A fresh conversation per domain keeps every answer focused and deep.
Scope big scans to one object. On large orgs, the deepest results come from pointing a scan at a single object ("…only for Opportunity"). Run Domain 0 first to learn which objects carry the most complexity, then aim the heavier scans at those.
Ask for a ranked shortlist, not a census. Phrase caps as "up to ~20" and ask Swantide to rank by severity. A focused, prioritized list is far more actionable than an exhaustive dump — and when an exact total matters, Swantide will write you a quick query to confirm it (see the data-probe pattern below).
Re-run a scan to widen coverage. Each pass can surface additional valid findings. If a domain is rich, a second run is a cheap way to find more — combine the two lists.
Use the data-probe loop for record data. Swantide reads your org's metadata — the configuration, not the records inside it. For questions that need record data (like "which fields are actually empty?"), use the pattern in Domain 4B: Swantide writes the exact query, you run it, paste the numbers back, and Swantide ranks the results.
Share your report folders. Swantide sees reports and dashboards in folders shared with the integration user. If Domain 7 comes back thin, share the folders and re-run.
Focus on your own configuration. Managed packages maintain their own internals, so the assessment concentrates on the metadata you own — where your cleanup leverage actually is. Swantide also maps the connection points between your automation and installed packages, which is exactly what you need to understand cross-package behavior.
Score everything by severity and effort. Every prompt asks for a severity and effort rating, so the outputs stack into one priority matrix at the end (Domain 10).
The program at a glance
# | Domain | What it covers |
0 | Org inventory & complexity baseline | Metadata census + where complexity is concentrated |
1 | Legacy automation & Flow migration | Workflow Rules / Process Builder → Flow, automation per object |
2 | Apex & code quality | Code smells, outdated API versions, test gaps |
3 | Security & access model | Risky permissions, Profiles vs Permission Sets |
4 | Data model & field utilization | Unused fields, object bloat |
4B | Data-probe queries | Field population %, empty objects — the record-data bridge |
5 | Validation rules & business logic | Conflicting or overlapping logic |
6 | UI sprawl — layouts & record types | Layout and record-type proliferation |
7 | Reports & dashboards | Stale or broken reporting |
8 | Documentation & naming hygiene | Missing descriptions (→ Swantide Data Dictionary) |
9 | Packages & limits | Installed packages, limit-risk indicators |
10 | Synthesis — priority matrix | Prioritized remediation roadmap |
Two-tier rhythm: each domain has a Tier-1 scan that returns a prioritized list. Pick the worst offenders and run the Tier-2 drill-down on each, one per chat.
Domain 0 — Org inventory & complexity baseline
Run this first. It sizes the org and tells you which objects carry the most complexity, so later domains can be aimed at the heavy hitters.
You're performing a thorough technical-debt assessment of this Salesforce org. Start with a high-level complexity inventory — assessment only, don't change anything.
Break the org down by: custom objects, total custom fields, Apex classes, Apex triggers, Flows, Workflow Rules, Process Builder processes, validation rules, page layouts, record types, profiles, and permission sets. Give approximate counts for each.
Then tell me where complexity is concentrated: which 5–10 objects carry the most custom fields, automation, and code. I want to know where to point a deeper audit. |
Companion scan — managed vs. custom composition. A great opener for orgs with a large package footprint: it frames where your own configuration ends and packages begin.
Break down this org's metadata: roughly how much is managed-package content versus our own custom configuration, and which managed packages have the largest footprint? |
Domain 1 — Legacy automation & Flow migration
Two different jobs — run them as two focused scans for the deepest results.
Tier-1 scan 1A — legacy-automation inventory:
Audit this org's automation for technical debt. Assessment only.
List the Workflow Rules and Process Builder processes in this org, grouped by the object they run on, and flag whether each should be migrated to Flow (Salesforce has retired both tools).
Rank by severity and cap at up to ~25 of the most significant. State the total count, and I'll confirm exact totals separately. Present as a table: object, automation, type, migrate-to-Flow?, severity (High/Med/Low), effort. |
Tier-1 scan 1B — automation overlap and order-of-execution risk:
Still assessing this org's automation, assessment only. I want the objects with the most tangled automation. Find the objects where MORE THAN ONE automation type fires — Workflow Rules, Process Builder, Flows, and Apex triggers all touching the same object — since that's order-of-execution risk and a sign of conflicting or duplicated logic.
Give me up to ~10 of the most overloaded objects, ranked, with a count of each automation type on them and why it's risky. |
Tier-2 drill-down (one object at a time):
Focus only on the [OBJECT] object. Walk through every automation that fires on it — Workflow Rules, Process Builder processes, Flows, and Apex triggers — and describe what each one does. Tell me where two of them update the same field or could conflict, the order they execute in, and how you'd consolidate them into a single Flow. Assessment and recommendation only — don't build it yet. |
Tier-2 variant — trigger-event cascade map. When users report that "one small edit sets off a chain reaction," anchor the scan to that exact symptom. This is one of the most powerful prompts in the whole program:
When a user changes [FIELD, e.g. the close date] on a [OBJECT] that has [CONTEXT, e.g. an active quote], we see cascading updates that sometimes slow saves down. Map the chain of automation that fires on that change — flows, workflow rules, and Apex, plus any entry points into the [PACKAGE NAMES] managed packages — so we can see why one edit fans out. |
Domain 2 — Apex & code quality
Swantide reviews logic and code patterns in depth. For lint-level static analysis and test-coverage numbers, Salesforce Code Analyzer is a great companion.
Tier-1 scan:
Review the Apex in this org for code-quality and technical-debt issues. Assessment only — don't rewrite anything.
For each Apex class and trigger, flag any of: outdated API version, SOQL or DML inside loops, hardcoded IDs, lack of bulkification, missing try/catch or error handling, no matching test class, and "God classes" doing far too much. Note any triggers that don't follow a one-trigger-per-object handler pattern.
Rank by severity and surface up to ~20 of the worst offenders; I'll confirm counts separately. Table: class/trigger, issue(s), API version, severity, effort. Worst first. |
On a code-heavy org, run this in batches — e.g. "…only the Apex classes related to Opportunity and quoting" — to keep each pass deep.
Tier-2 drill-down (one class at a time):
Show me the full body of the [ApexClass] class and give a detailed code review: logic bugs, anti-patterns, governor-limit risks, and security gaps (CRUD/FLS enforcement, SOQL injection, sharing). List what you'd refactor and why. Assessment only. |
Domain 3 — Security & access model
Pro tip: treat this scan as your ranked lead list, then confirm the complete inventory of permission holders with a quick query — Swantide will write it for you (the Domain 4B pattern). Security totals are worth double-checking by query in any org.
Tier-1 scan:
Audit this org's security and access model. Assessment only.
Identify Profiles and Permission Sets that grant risky permissions — Modify All Data, View All Data, Author Apex, Customize Application, Manage Users, Manage Sharing, Password Never Expires, or API Enabled where it shouldn't be. Tell me roughly how many profiles have admin-level access. Flag profiles that should be converted to Permission Sets, and any object- or field-level access that looks over-broad.
Rank by severity and give me the highest-risk findings; I'll confirm the full inventory with a direct query. Table: profile/permission set, risky permission(s), why it's a risk, severity, effort. |
Follow-up — the confirmation query:
Write me a query I can run to get the complete list of Profiles and Permission Sets that grant Modify All Data, Manage Users, or Author Apex, so I can confirm the full inventory. |
Tier-2 drill-down (one profile or permission set at a time):
Take the [Profile / Permission Set] named [NAME]. List every risky or unusually broad permission it grants and explain the concrete risk of each. Then describe a least-privilege alternative — what to strip out and what to move to a dedicated permission set. Assessment only. |
Domain 4 — Data model & field utilization
Swantide flags fields that aren't referenced anywhere — a strong "likely unused" signal. To confirm which fields are actually empty in your records, pair this with the Domain 4B data probe before deleting anything.
Tier-1 scan:
Audit this org's data model for bloat — you read metadata, not record data, so flag fields that aren't REFERENCED anywhere rather than claiming they're empty. Assessment only.
Work through the heaviest objects (start with the 3–5 with the most fields — don't try to cover every object at once, and tell me which ones you got through). For each, flag: custom fields with no references in any layout, automation, Apex, or report (likely unused); duplicate or overlapping fields; oversized picklists; and formula fields that reference other formula fields. Note fields missing descriptions.
Table: object, field, issue, "referenced anywhere?", severity, effort. |
Tier-2 drill-down (one object at a time):
For the [OBJECT] object, list every custom field and tell me, for each, everywhere it's used — page layouts, automation, Apex, validation rules, reports. Group them into "safe to deprecate (no references)", "consolidate (duplicates/overlap)", and "keep". This is the shortlist I'll validate against record data before deleting. Assessment only. |
Domain 4B — Data-probe queries (Swantide writes, you run)
The bridge between metadata and record data. Swantide knows your exact field and object API names, so it's an excellent query author: it writes the SOQL, you run it in Developer Console or Workbench, paste the numbers back, and Swantide ranks the results. For an org-wide sweep, the free Salesforce Optimizer (Setup → Optimizer) is a great companion — Swantide then turns its output into a prioritized plan.
4B-1 — field fill-rate query (per object):
For the [OBJECT] object, I want to find which custom fields are barely populated so I can deprecate them. You know this object's field API names — write me a single SOQL aggregate query I can run in Developer Console or Workbench that returns, in one row, the non-null count of each custom field alongside the total record count, so I can compute a fill rate per field. If there are too many fields for one query, split it into a few. I'll run them and paste the numbers back for you to rank. |
Follow-up after you run it:
Here are the counts I got back: [paste the query results]. Total records on the object is [N]. Convert these to fill-rate percentages and rank the fields: "deprecate (<2% filled)", "review (2–20%)", and "keep". Flag any surprises. Assessment only. |
4B-2 — empty or near-empty custom objects:
List the custom objects in this org and give me a way to find which ones hold little or no data. Either write the per-object "SELECT COUNT() FROM Object" queries, or tell me exactly where in Setup to read record counts. I'll bring back the counts and you flag the empty or near-empty objects as deprecation candidates. Assessment only. |
4B-3 — stale reports & dashboards:
Write me SOQL against the Report and Dashboard objects to surface stale reporting — reports by LastRunDate and dashboards by LastViewedDate, oldest first, with owner and folder. I'll run it and you help me decide what to archive. Assessment only. |
4B-4 — inactive users / reclaimable licenses:
Write me a SOQL query (against User, plus LoginHistory if useful) to find active users who haven't logged in for 90+ days, with their profile and last login date. I'll run it and you help me flag license-reclamation candidates. Assessment only. |
Domain 5 — Validation rules & business logic
Tier-1 scan:
List the validation rules in this org, grouped by object. Assessment only. Flag: rules that are deactivated, rules whose logic overlaps or could conflict with another rule on the same object, rules with no description, and overly complex formulas that are hard to maintain.
Rank by severity and surface the highest-value findings — up to ~20. State the total count, and I'll confirm exact totals separately. Table: object, rule, issue, severity, effort. Worst first. |
Tier-2 drill-down (one object at a time):
For the [OBJECT] object, show every validation rule's formula and explain what each one enforces in plain English. Identify any pair that overlaps, contradicts, or could block each other, and recommend how to consolidate. Assessment only. |
Domain 6 — UI sprawl: layouts & record types
Tier-1 scan:
Audit this org's UI configuration for sprawl. Assessment only. Flag objects with an excessive number of page layouts or record types, layouts that look near-duplicate, and record types that appear unused (not referenced by profiles or automation). Table: object, layout/record-type count, issue, severity, effort. |
Tier-2 drill-down (one object at a time):
We have [N] record types on the [OBJECT] object, but only a few are actively used. Inventory the record types and, for each, list its page layout, business process, and any flows or validation rules tied to it. Flag which ones appear to be legacy or unused cleanup candidates based on their supporting configuration. |
Which record types are actually used is a record-data question — Swantide will write you the usage query (a GROUP BY on RecordType) to confirm before you retire anything.
Domain 7 — Reports & dashboards
Swantide sees reports and dashboards in folders shared with the integration user — if results look thin, share the folders and re-run. The 4B-3 query covers the rest.
Tier-1 scan:
Audit reporting in this org. Assessment only. Flag reports or dashboards that reference fields or objects that no longer exist (broken), folders with no clear owner, and reporting that looks stale or redundant. Note if folder-sharing limits what you can see. Table: report/dashboard, issue, severity, effort. |
Domain 8 — Documentation & naming hygiene
The fix for this entire domain is Swantide's Data Dictionary — auto-generated business and technical descriptions for every component, kept current as your org changes.
Tier-1 scan:
Audit this org for documentation debt. Assessment only. Across custom objects, fields, automations, and Apex, find the components missing descriptions or with non-descriptive or cryptic API names that hurt maintainability. Tell me where the documentation gap is worst (by object and by component type). Table: component type, % missing descriptions (approx), worst-offending objects, severity. |
Bonus — reverse-engineer the requirements behind what's built. Great for teams whose requirements documentation has drifted from what was actually delivered:
Take the [COMPONENT, e.g. a complex flow]. First, document what it actually does today (the delivered solution) in clear business language. Then reverse-engineer the user stories with acceptance criteria that this component implements — the requirements documentation that should have accompanied it. |
Domain 9 — Packages & limits
Tier-1 scan:
Assess this org for package and limit risk — assessment only, and be clear about what you can infer from metadata vs. what needs the live org. List installed managed packages and flag any that look out of date. Then flag metadata-shape limit risks: objects approaching the custom-field limit, objects with an unusually high number of triggers or automations, or other governor-limit-adjacent concentrations. Table: item, risk, severity, effort. |
Domain 10 — Synthesis: the priority matrix
Run this last, pasting in (or summarizing) the tables from the prior domains so it has the full picture. This is your executive readout.
Here are the findings from the technical-debt assessment across automation, Apex, security, data model, validation rules, UI, reporting, documentation, and packages: [paste or summarize the prior tables].
Produce a consolidated executive report: the top 10–15 issues ranked by severity × effort. Split them into "Quick wins" (high impact, low effort) and "Major projects" (high impact, high effort), and call out anything that's a security or data-integrity risk regardless of effort. Give me a one-paragraph health summary I could put in front of a stakeholder. Assessment and prioritization only. |
Want a project plan instead of a report? Turn the findings straight into a phased roadmap:
We want to clean up the [OBJECT] object: retire unused record types, migrate legacy workflow rules to flows, and consolidate redundant validation rules. Build a phased project plan with estimated level of effort for an advanced admin, ordered so the lowest-risk quick wins come first. Include what to verify in production data before each phase. |
Suggested sequencing
Domain 0 — size the org and get the heavy-hitter object list.
Domains 1–9, one chat each. Where a domain is rich, narrow to the heavy objects from Domain 0 and go deeper.
For each domain's worst findings, run the Tier-2 drill-down, one item per chat.
Domain 4B is a loop, not a one-shot: Swantide writes the query → you run it → paste results back → Swantide ranks. Use it whenever a metadata finding needs record data to confirm before anyone deletes anything.
Domain 10 — synthesize into the priority matrix and readout.
Then turn confirmed findings into action: Swantide's AI Admin can build and deploy the fixes, turning your assessment into an executed cleanup.