The Tech Debt Assessment gives you a structured, data-backed picture of where technical debt lives in a client org. Unlike a broad org audit, each tab focuses on a specific, well-defined category of debt: something measurable, explainable to a client, and actionable. Use it to scope cleanup work, set realistic expectations with a client about what they're carrying, or identify which areas need attention before you make changes.
Each tab loads data live from the connected org and includes two ways to go deeper: Generate Assessment runs an AI analysis that surfaces patterns, explains the risks, and produces prioritized recommendations. Export to LLM copies the raw data along with a structured prompt to your clipboard so you can paste it into ChatGPT, Claude, or any AI tool you already use — useful when you want a different angle or need to incorporate the data into a larger analysis.
Fields without description
Custom fields created in the last 12 months that have no description set. The table shows the field, the object it lives on, and when it was created — sorted newest first so recent work is immediately visible.
Undocumented fields are a compounding problem. New team members can't tell what a field is for without asking someone. Report builders make assumptions that turn out to be wrong. Fields get duplicated because no one realized one already existed. Over time, the org accumulates fields that only the person who created them understands.
What to look for: Objects with a high concentration of undocumented fields are the ones where knowledge is most siloed. A field created in the last 30 days with no description is a governance failure you can point to specifically. If the count is high across the board, that's a process finding — there's no documentation standard being enforced.
Inactive Validation Rules
Validation rules that exist in the org but have been deactivated. The table shows the object, the rule name, and the error message that rule would have shown — which is often the most useful clue about what the rule was originally enforcing.
An inactive validation rule is a signal worth investigating. Rules don't usually get turned off because they were wrong — they get turned off because they were inconvenient. Common causes: the rule was too strict for a data migration or import, end users couldn't satisfy it and complained, or a business process changed and no one got around to updating the rule. The rule sits there as metadata debt, making it harder to understand what the actual data integrity model is supposed to be.
What to look for: Rules with error messages that describe important business logic ("Contract cannot be closed without an approved quote") are the highest priority — turning those off has real consequences. A cluster of inactive rules on the same object often tells a story about a process that went wrong.
Multiple Triggers
Objects that have more than one Apex trigger. Each object card shows the triggers, the events each one fires on, the API version, the active/inactive status, and the last modified date.
When two triggers on the same object fire on the same event — for example, both fire before insert — Salesforce does not guarantee which one runs first. The execution order is non-deterministic. This is a well-known source of bugs that are extremely hard to reproduce: the behavior changes between deployments, between sandbox environments, and sometimes between consecutive saves. The assessment marks these as Same-event conflicts and highlights the specific event and trigger names involved.
Objects with multiple triggers on different events are flagged with a lower severity — they don't have the same execution order problem, but they still represent unconsolidated trigger logic that will become harder to maintain as the org evolves.
What to look for: Any same-event conflict is a finding. A trigger on an old API version (below v40) that's still active is likely legacy code that hasn't been touched in years. An inactive trigger is either abandoned debt or something that was turned off as a hotfix — worth understanding which.
Unassigned Permission Sets
Permission sets that are not assigned to any user, are not profile-owned, and don't come from a managed package. These are orphaned — they exist in the org but serve no active purpose.
The concern isn't just clutter. An unassigned permission set with View All Data or Modify All Data enabled is one accidental assignment away from a serious overpermissioning incident. The table flags any permission set that carries elevated privileges — View All Data, Modify All Data, API Enabled, Export Reports, Reset Passwords, or Manage Users — and surfaces that information immediately in the Elevated Privileges column.
What to look for: Any unassigned permission set with elevated privileges is an immediate finding. The right remediation is deletion, not reassignment. For permission sets without elevated privileges, review whether they came from a past project and were never cleaned up, or whether they're placeholders someone intends to use — if there's no clear owner, they should go.
Practical scenarios
Scoping a cleanup engagement. Walk through all four tabs before agreeing to a timeline. The total undocumented field count, the inactive rule inventory, the trigger conflicts, and the orphaned permission sets each contribute to a realistic estimate of remediation work.
Pre-handover documentation review. Before handing a project back to a client's internal team, run the Fields without description tab on the objects you touched. Any field you created without a description is your responsibility to document before the engagement closes.
Security findings presentation. The Unassigned Permission Sets tab, especially with the elevated privileges filter visible, translates directly into a client-facing security finding. A permission set with Modify All Data that isn't assigned to anyone is a concrete, named risk — not a theoretical one.
Trigger architecture assessment. A client wants to add new automation to an object that already has same-event conflicts. Run the Multiple Triggers tab, show them the current state, and use Generate Assessment to produce a written explanation of the risk and consolidation recommendations before any new code is written.
Establishing governance baselines. Run the assessment at the start and end of an engagement. The delta in undocumented fields and inactive rules is a concrete measure of the governance improvement you delivered.