When writing dynamic Apex, you often find yourself working with the generic sObject class to build reusable utilities or framework-level code. While fetching a field on the immediate object is straightforward using the get() method, accessing fields on a related parent object can lead to frustrating runtime errors.

In this guide, you will learn why traditional dot notation doesn't work with dynamic methods and how to correctly traverse relationships to fetch parent data.

The Problem with Dot Notation in get()

If you are used to writing static SOQL, you know that accessing a parent field is as simple as Contact.Account.Name. Naturally, many developers try to replicate this logic dynamically:

// This will throw a runtime error
sObject myRecord = [SELECT Account.Name FROM Contact LIMIT 1];
String accountName = (String)myRecord.get('Account.Name');

When you run the code above, Salesforce throws an Invalid field Account.Name for Contact error. This happens because the get() method is designed to look for a specific field name on the current object's schema. It does not natively parse the dot notation for relationships.

The Solution: Using getSObject()

To move "up" a relationship dynamically, you must use the getSObject() method. This method returns the related sObject instance, which you can then call get() on to retrieve the specific field value.

Here is how you can correctly traverse a multi-level relationship (e.g., Account -> Owner -> Profile):

// Query the record with the necessary relationship fields
sObject acc = [SELECT Owner.Profile.Name FROM Account LIMIT 1];

// Traverse the relationship hierarchy
sObject owner = acc.getSObject('Owner');

if (owner != null) {
    sObject profile = owner.getSObject('Profile');
    if (profile != null) {
        String profileName = (String)profile.get('Name');
        System.debug('Profile Name: ' + profileName);
    }
}

By chaining getSObject() calls, you can navigate as deep into the relationship hierarchy as your SOQL query allows.

Handling Dynamic Paths Programmatically

In some advanced scenarios, you might have a string variable representing a path, such as "Account.CreatedBy.FirstName". Since you cannot pass this entire string into a single method, you can split the string and loop through the parts to find the value.

public static Object getFieldValue(sObject record, String fieldPath) {
    if (record == null || String.isBlank(fieldPath)) return null;

    List<String> parts = fieldPath.split('\\.');
    sObject current = record;

    // Loop through all parts except the last one (the actual field)
    for (Integer i = 0; i < parts.size() - 1; i++) {
        current = current.getSObject(parts[i]);
        if (current == null) return null; // Handle null relationships safely
    }

    // Return the value of the final field in the path
    return current.get(parts[parts.size() - 1]);
}

Important Considerations

1. Query Requirements

Before you can use getSObject(), the fields must be explicitly included in your SOQL SELECT clause. If you attempt to access a relationship that wasn't queried, Apex will throw a System.SObjectException: SObject row was retrieved via SOQL without querying the requested field.

2. Null Safety

Always perform null checks when traversing relationships. If a lookup field is empty, getSObject() will return null. Attempting to call another .get() or .getSObject() on a null reference will result in a NullPointerException (NPE).

3. Case Sensitivity

While Apex is generally case-insensitive, it is a best practice to match the API names exactly as defined in your schema to ensure consistency and readability.

Wrapping Up

Accessing parent fields dynamically requires a shift in mindset from static dot notation to the programmatic use of getSObject(). By understanding how to traverse these relationships and implementing safe navigation patterns, you can build robust Apex tools that handle complex data structures with ease.

Next time you need to reach across an object boundary, remember: use getSObject() for the relationship and get() for the final destination.