It would be useful to have a new Rule trigger type for when a (to-one) linked entity is Updated.
This Rule trigger condition would essentially be identical to the current “<Type> Updated” trigger, with the associated “Select Changed Fields” filter, but for filtering the fields of the related entity.
Use Case: I want to use a Rule to “pull” the Name of a linked entity, and use it to construct this entity’s Name. Very similar to using a Formula that references the linked entity’s Name, but this method would allow using a Text field for the Name instead of a Formula; thus the Rule can decide if and how to build the Name, or leave it as the User has entered it (since it’s just a Text field).
The logic is: “If there is a linked entity, use its Name to construct our Name; otherwise continue using our existing Name”. But we want to run this logic whenever the linked entity’s Name changes - thus the need for a Rule that can trigger on changes to a (to-one) linked entity’s fields.
Currently this can only be done by defining a Rule in the linked entity, and “pushing” a new Name to this entity when updated. That is undesirable since it requires placing the Rule in the “wrong” entity.
What is bothering you about having a rule ‘in the wrong entity’?
If the rule has to be in the affected entity’s database, you could create a lookup to get the linked entity’s name and then trigger on this field changing (and it has the advantage of triggering if/when an entity is unlinked/linked).
@Chr1sG, yes there are existing workarounds.
The case for this is really about reducing complexity, i.e. not having to create additional lookups, and avoiding having to remember that a particular field is actually modified from a related entity (which is not how I like to build things). It’s a maintenance headache.
I have actually found myself forgetting why I created a particular lookup or relation, and deleting it, only to (re)discover later that it was added it to perform some kind of work-around (usually in a script or rule).
If we were able to notate each field and DB, that would also help with this situation.
That’s totally understandable.
Conversely, allowing for users to trigger when linked entities are updated will significantly grow the complexity of both the automation engine and the UI.
For example, if an entity has several relationship fields, and each of the related databases has a dozen fields (not totally unrealistic scenario) then the number of possible triggers might increase by an order of magnitude.
I think allowing for a database to have lookups for only those fields that are ‘of interest’ may be preferable, but I agree that it would be good to be able to annotate fields with their purpose/usage and also be able to hide any fields that are not useful for everyday users, would also be really valuable.