While related fields are a simple alternative to report metrics, it's important to understand their limitations when using them for metric attribution. Specifically, it's important to know that Ambition only receives updates when the source object is updated, not when any of its related objects are updated.
Consider an example where an Ambition metric is configured for the Task object, a count-type metric whose user
attribution is tied to the related Account Owner (Task.Account.OwnerId). When a given Task object is received, it
is received with the current Account Owner and is attributed as expected. However, if the Account Owner is later changed
and no subsequent change is made to the Task, the metric record will not be attributed to the new owner in Ambition.
Attribution based on fields of related objects should not be confused with related objects themselves. For example,
consider a metric configured for the Opportunity object, a count-type metric with a filter that only counts
Opportunity objects that are related to a specific Campaign (Opportunity.CampaignId). Any time a given Opportunity's
association with a Campaign is changed, our process in Salesforce will recognize that there are changes to the
Opportunity object, and Ambition will receive the updated state of the Opportunity.
When metric configuration is based on related objects, rather than the fields of related objects, the metric state in Ambition stays in-sync with Salesforce seamlessly.
We recommend that when using related fields to filter or attribute metric records to users or dates/times, you choose
related fields whose state is static. For example, attributing the user in Example 1 will have no negative impact
on data consistency as long as the Account's Owner isn't likely to change.
If there is no alternative to metric filtering/attribution based on fields of related objects whose value is likely
to change often, there is a relatively simple workaround: Implement a simple trigger on the related object that updates
the source object. An example trigger that would solve the case in Example 1 is shown below.
trigger AmbitionOnAccountUpdatedTouchTask on Account (after update) {
List<string> updatedIds = new List<string>();
for (Account account: Trigger.new)
{
updatedIds.add(account.Id);
}
List<Task> relatedTasks = [SELECT Id FROM Task WHERE AccountId IN :updatedIds];
update relatedTasks;
}