A Practitioner’s Guide to AI-Assisted Org Discovery: Map the Org Before You Build

In a mature org with limited documentation and a major release on the horizon, there is often a gap between project documentation and what the metadata actually shows. Custom objects may or may not still serve their original purpose, automations may be layered on top of each other with no clear firing order, or integration touchpoints that connected systems depend on may not be fully mapped. You need to design the future state, but you have no clear understanding of the current state.

A structured discovery practice gives you a repeatable method for mapping what exists before you build. This is part one of a two-part series that walks through that practice, covering four discovery domains to evaluate and a practitioner toolkit for running discovery using AI skills.

This post explores four domains where complexity often concentrates in a mature org: custom objects, automation dependencies, integration touchpoints, and antipatterns. 

Domain 1: Custom object analysis: what’s real, what’s orphaned, what’s load-bearing

Unlike standard objects, custom objects are unique to your specific org and are often not well documented. 

When you enter a mature org, custom objects deserve close attention because they often have the highest concentration of specialized code written over many years. Undocumented code makes it difficult to remove legacy triggers and unused objects because the impact of doing so isn’t well understood. Without a clear understanding of what the code does, new features could introduce regressions if they clash with undocumented logic.

Apply a framework for custom object analysis

Custom object analysis works at three levels of resolution: org-level assessment, custom object health, and dependency radius. Each one narrows the scope of analysis: the first maps the full landscape, the second examines each object’s internal complexity and activity, and the third measures how deeply an object is embedded in the systems around it. Working through all three levels in sequence prevents the most common discovery failure, which is scoping a modification against an object’s current state without accounting for everything that changes when that object is updated.

Org-level assessment

Determine the scale and shape of the custom object landscape, including how many objects exist, how many are structurally simple, and where redundancy has accumulated.

• Schema Footprint: Total volume of custom objects within the org’s metadata.
• Low-Variance Structures: Identification of objects with a single record type.
• Functional Overlap: Detection of redundant objects shadowing standard or legacy entities (for example, Contact__c, Contact2__c, Legacy_Contact__c, and so on).

Completing this assessment identifies specific objects requiring investigation. From there, perform a deep-dive analysis into each of these prioritized objects using the next level.

Custom object health

Every custom object has to prove its value. At this level you track active usage, identify dependent logic, and catalog downstream systems relying on each custom object. This level of visibility is critical for paying down technical debt or safely executing new features that touch custom objects.

Utilization Metrics: Uncover how custom objects are utilized within your organization to evaluate whether they contain valuable data, remain active, or fulfill a broader operational role. These criteria define the specific metrics:

• Record Density: Total count of records stored on the object.
• Object Activity: Velocity of new data and churn rates for existing records.
• Owner Distribution: Correlates record volume with user or queue ownership to identify ownership skew and objects associated with isolated or obsolete business processes.

Metadata Complexity: Quantifies technical debt and structural bloat across an object’s architecture to expose hidden maintenance overhead and prevent performance degradation. The following aspects highlight the complexity:

• Field Count: Comprehensive count of fields defined on the entity.
• Field Bloat: Surfacing orphaned, unused, or explicitly deprecated fields.
• Logic Density: Count and conditional complexity of validation rules.
• Record Type Count: Count of record types currently driving business processes.
• Triggers: Count of triggers on the object and complexity of the invocation.
• Flows: Active flow references, specifically mapping record-triggered logic.
• Formula Depth: Volume of cross-object formula fields.
• Access Model Sprawl: Variance in field-level security across the profile and permission set landscape.

Dependency radius

The dependency radius is a measure of how your custom objects integrate within the org. This defines the exact footprint of an object across the Salesforce instance, moving your discovery from guesswork to informed analysis by assessing the technical impact and risk of every change.

• Classes: Number of Apex classes with calls to the object under analysis, and other associated objects within the same classes.
• Object Relationships: Count of lookup and master-detail relationships defining the object context.
• Analytics Footprint: Report volume and execution frequency leveraging object data.
• Integration Perimeter: Total inbound and outbound connection touchpoints associated with the object.

Domain 2: Understand automation dependencies before you touch them

Automation is one of the highest-risk categories in a legacy org. Unlike problems with custom objects, where the consequences of a poor decision may be visible before you deploy, automation failures generally surface at runtime. A field change that appears safe in isolation can break a validation rule, trigger a recursive loop, or cause a record-triggered flow to re-fire triggers in a way no one anticipated. 

Over time, orgs accumulate automation built with different tools by different teams, often with limited documentation describing how those automations interact. Before making changes, understand what automation is running, when it runs, and what it affects.

Look for predictable patterns in automation

Automation debt tends to accumulate in predictable patterns. Recognizing them early can accelerate the discovery process:

• Legacy automation that is still active. Workflow rules and Process Builder processes are both deprecated and no longer available for new configurations, but active instances remain in many orgs built before these tools reached end of support.
• Duplicated logic across automation types. The same business logic implemented in a flow and a trigger, or a Process Builder process and a flow, creates write overlap. The last writer wins based on execution order. Duplicated logic also unnecessarily increases the risk of encountering governor limits.
• Trigger stacking. Multiple Apex triggers on the same object, written by different teams or vendors across different release cycles, with no shared handler framework.
• Conflicting automation. Two or more automations sharing a triggering condition on the same object, writing to the same field in different contexts. The conflict isn’t always visible until a specific record state exposes it.
• Unmapped dependencies. Automations that call out to external systems, reference fields written by integrations, or cascade across parent-child relationships in ways that weren’t formally documented.

Apply a framework for mapping the automation stack

Work through automation discovery in four stages:

1. Identify overlaps: Map which objects carry more than one active automation type. An object running Apex triggers, record-triggered flows, and Process Builder processes simultaneously has overlap by definition. Build the inventory first and flag every object where multiple automation types share an event context or write to the same field.
2. Sequence dependencies: For each flagged object, map the execution order across automation types. The goal is understanding which automations fire in the before-save context, which fire after the record is committed, and where deprecated automation types introduce a secondary save that re-fires triggers unexpectedly. Pay particular attention to objects where Process Builder processes are still active alongside record-triggered flows, as both operate in adjacent steps and write overlap between them can be a source of silent data errors.
3. Assess what’s safe to change: Before recommending any field or object change, answer four questions: Is this field written by any automation? Is it used as a condition in any flow, trigger, or validation rule? Does any automation on this object call out to an external system? Is there a governor limit risk from the total automation load on this object? An object with fourteen Apex triggers, five record-triggered flows, and five Process Builder processes active simultaneously requires a stabilization plan before it can safely absorb new work.
4. Document and prioritize modernization: Every conflict, non-bulk-safe trigger, and unmigrated Process Builder process is a finding that belongs in your technical debt backlog with a severity classification and a sequencing dependency. Use that backlog to make the case for process modernization (that is, technical debt remediation) with stakeholders. Where the architecture supports it, work toward a single point of automation entry per object, consolidating logic that has accumulated across multiple tools over time.

Domain 3: Integration touchpoints

Start by understanding what the platform natively provides for integration analysis. Building an inventory of integration touchpoints from areas such as named credentials, API Catalog, external client apps, and legacy Connected Apps confirms which integrations are configured, but not how they operate or how heavily they’re used.  Beyond this inventory, you must quantify volume and frequency to better understand the full landscape of integrations.

Recognize integration debt

High-velocity integrations, whether they are batch or high-frequency API bursts, act as risk amplifiers for new features. They can introduce concurrency issues, record locking errors, and governor limit problems that rarely surface in a sandbox or with a unit test. These indicators help you to identify areas under stress and areas that involve less risk. 

Apply a framework for mapping integration scope and ownership

When using an AI agent for integration discovery, focus your analysis on these core activities:

• Establish a comprehensive inventory of connection points. Direct the agent to evaluate named credentials, connected apps, external client apps, remote site settings, external data sources, Platform Events, API Catalog, Outbound Messages, Streaming API, Change Data Capture, and Apex REST API endpoints to map the architectural baseline of your environment.
• Transition from inventory to dependency mapping by identifying where these connections intersect with your business logic. This requires the agent to perform a deep-dive analysis of Apex classes and flows to surface exactly how integration touchpoints are used across your instance.
• Quantify the velocity of your data flows through frequency and volume analysis. More data is available if Event Monitoring or Salesforce Shield is active. Without these add-ons, your architectural visibility is limited to short-duration audit trails or custom logging features.

Domain 4: Identify antipatterns as architectural signals

An antipattern is a recurring, counterproductive workaround that appears across multiple objects. This can be a field overloaded with picklist values that carries dependencies across automation, reporting, and potentially integration payloads. Non-bulk-safe triggers on core objects are a hard blocker for data migrations and bulk integration writes. Misreading an antipattern, or missing it entirely, means you make the wrong architectural decisions. 

Recognize inherited antipatterns

Antipatterns accumulate across release cycles, teams, and vendors, and don’t surface in any single metadata query. These are the challenges that make them easy to miss:

• Volume obscures signal: In an org with hundreds of custom fields and dozens of automation components, individual anomalies get lost. The antipattern only becomes visible when you look across the full dataset.
• Context is missing: The metadata shows what exists, but not why it exists. A field with overloaded picklist values looks like a design choice until you understand it was extended several times by different teams over the years.
• Antipatterns compound: A single cross-object hack is a workaround. Three cross-object hacks in the same domain may signal a missing abstraction that the org has been approximating for years. Reading one antipattern in isolation misses the architectural story.
• Remediation without root cause: Cleaning up an overloaded field without understanding why it exists leaves the conditions in place, allowing the antipattern to return.

The four antipatterns below represent high-risk signals that are most likely to block implementation work, generate production incidents, or require architectural remediation. In each case, trace related dependencies to understand the change management implications before modifying the affected functionality. 

• Field overloading: Field overloading can result when an org outgrows its data model and teams extend existing fields rather than introduce new ones. This can look like a picklist field with values spanning unrelated workflows or a single field driving record type assignment, automation branching, and reporting simultaneously. 
• Non-bulk-safe architecture: Architectures featuring triggers that weren’t written with bulk processing requirements or tested against data loads and batch operations should be remediated. Examples include Apex triggers with UsageIsBulk = false on core objects and triggers that perform SOQL queries or DML inside loops. 
• Cross-object hacks: Cross-object hacks occur when relationships between objects are simulated through workarounds instead of through the data model. This can look like formula fields pulling data across numerous object relationships, or roll-up summary fields on objects with no meaningful parent-child relationship. 
• Permission set sprawl: Permission set sprawl can indicate that access control was handled reactively: each time someone needed access to something, a new permission set was created rather than absorbed into a coherent access model. Symptoms can include permission sets with temporary names or users assigned ten or more permission sets with overlapping field-level security. 

What to do when antipatterns appear together

When multiple antipatterns show up in the same domain, treat them as connected, not separate.

• Field overloading and cross-object hacks in the same domain may signal a missing abstraction the org has been approximating for years. The domain needs a data model review, not just field cleanup.
• Non-bulk-safe triggers alongside trigger stacking on the same object signal that the object has become a hub for logic it wasn’t designed to hold, and that bulk operations will likely surface failures that single-record testing didn’t catch. Prioritize trigger consolidation and bulk-safe refactoring before expanding automation on that object.
• Permission set sprawl alongside field overloading signals that user personas weren’t defined at the data model or access model levels. Start remediation with persona definition before addressing the data model or permission set structure.
• When all four antipatterns are present in the same org, it is a signal that the org has been operated without consistent governance. Recommendations must include a governance model alongside the technical remediation work.

What comes next

To get started, take a pass through your custom objects and automations on high-volume objects. Document what you find: which objects carry the most logic, which antipatterns appear together, and what you already know about the history of that area. That documentation is the starting point the toolkit is designed to work from. The Record-Triggered Automation Decision Guide and the Well-Architected Framework on the Architecture Center are good companions for that inventory.

In part two of this series, we’ll introduce the practitioner toolkit, bringing together skill-writing best practices and sample prompts for all four domains into a single reference. We’ll also walk through how to translate your findings into a governed technical debt backlog connected to Well-Architected principles.