Managing Object Limits and Dependencies in Salesforce: A Complete Guide

Salesforce is a powerful CRM platform, but like any system, it comes with limits and dependencies that every admin, developer, or architect must understand. Ignoring these constraints can lead to performance issues, errors during deployments, or even hitting hard system restrictions that require costly rework.

In this blog, we’ll break down Salesforce object limits and dependencies in simple terms, explore best practices for managing them, and provide practical examples.


Salesforce imposes limits on how many fields, relationships, records, and features you can have per object. These are designed to maintain platform performance and stability across all tenants.

Some of the most common object limits include:

1. Field Limits

  • Each object can have only a certain number of custom fields.
  • For most editions:
    • Custom fields per object: Up to 500 (varies by edition).
    • Formula fields and roll-up summary fields have their own limits.

👉 Example: If you try to add the 501st field on an object, Salesforce won’t allow it.


2. Relationship Limits

Objects in Salesforce are connected using relationships (lookup, master-detail, etc.), but these also have limits.

  • Lookup relationships: Up to 40 per object.
  • Master-detail relationships: Maximum 2 per object.

👉 Example: You cannot create a 3rd master-detail relationship on the same object.


3. Record Limits

While Salesforce doesn’t impose a strict cap on the number of records per object, large datasets can cause:

  • Slow queries
  • Reporting issues
  • Governor limits being hit during processing

👉 Example: Objects with millions of records should be optimized using indexing, skinny tables, or Big Objects.


4. Validation and Rule Limits

  • Validation rules: Maximum 500 per object.
  • Workflow rules (being replaced by Flow): Maximum 50 active workflow rules per object.

5. Dependencies in Fields

Certain fields and objects depend on others. For example:

  • Formula fields depend on other field values.
  • Roll-up summary fields depend on master-detail relationships.
  • Picklist dependencies (controlling vs. dependent picklists).

👉 If you delete a controlling field, the dependent picklist breaks.


Object dependencies occur when one object, field, or feature relies on another. Mismanaging dependencies can cause data loss, broken automations, or failed deployments.

Common Types of Dependencies:

  1. Field Dependencies
    • Example: A formula field depends on another field’s value.
    • Risk: If you delete the dependent field, the formula breaks.
  2. Object Dependencies
    • Example: A roll-up summary field on an Account depends on Opportunities.
    • Risk: If you try to delete the Opportunity object (or relationship), the roll-up summary fails.
  3. Picklist Dependencies
    • Example: Country (Controlling field) → State (Dependent field).
    • Risk: Removing a controlling value breaks the dependent options.
  4. Automation Dependencies
    • Flows, validation rules, Apex triggers, and reports often reference specific fields or objects.
    • Risk: If a field is removed, these automations fail.

Now that you know the limits and risks, let’s look at strategies to manage them effectively.

1. Plan Before Adding Fields

  • Don’t just keep adding custom fields for every requirement.
  • Use field usage reports to identify unused fields.
  • Group related data in a single field (e.g., use picklists instead of multiple checkboxes).

2. Optimize Relationships

  • Use lookup relationships instead of master-detail if flexibility is needed.
  • Avoid circular references (Object A → Object B → Object A).
  • For many-to-many, always use a junction object.

3. Handle Large Data Volumes

  • Use indexes for frequently queried fields.
  • Archive or delete unused records.
  • Consider Big Objects for billions of records.

4. Be Careful With Dependencies

  • Before deleting fields/objects, run “Where is this used?” (Setup → Object Manager → Field → Where is this used?).
  • Use Schema Builder to visualize dependencies.
  • Maintain a metadata inventory of critical fields and their dependencies.

5. Govern Automation

  • Consolidate automation using Flows instead of scattered workflow rules.
  • Document field references in Flows, Triggers, and Reports.
  • Use naming conventions (e.g., “Opp_Stage__c”) to easily identify dependencies.

  • Schema Builder → Visualize objects, fields, and relationships.
  • Setup Search → Find where fields are used.
  • Field Trip App (AppExchange) → Analyze field usage.
  • Salesforce Optimizer → Provides recommendations on unused fields, limits, and performance issues.

Imagine you have a Loan__c object with 400 custom fields already. Your business team asks for 120 more fields.

Challenges:

  • You’ll hit the 500-field limit soon.
  • Several formula fields already reference Loan Amount and Interest Rate.
  • Deleting or renaming these fields will break multiple flows and reports.

Best Practice Approach:

  • Combine multiple yes/no checkboxes into a multi-picklist.
  • Archive unused fields after confirming with business stakeholders.
  • Document dependencies of “Loan Amount” field before making changes.

Salesforce is powerful, but it’s not limitless. Understanding object limits and dependencies ensures you don’t run into performance issues or broken automations down the line.

By planning your data model carefully, using tools like Schema Builder and Optimizer, and following best practices, you can keep your Salesforce org clean, efficient, and scalable.


Pro Tip: Always document your objects and fields. Today’s “just one field” request can become tomorrow’s 500-field headache.


Leave a Reply

Your email address will not be published. Required fields are marked *