• Home
  • Ideas
  • Enhancements to Relationship action- moving away from Name as required identifier

Enhancements to Relationship action- moving away from Name as required identifier

Related products: None
I'd love to see our Load to Relationship action expanded on.  Currently, we have to map to Account ID and Name.  This is fine on our original load rule, but if I am pushing aggregated data (such as ARR/MRR, Seat/License counts, etc.) to attributes I have created, and the NAME isn't on these sub-objects or in that data set, I can't finish up the rule.





I have created other attributes that hold unique ID's, so I was hoping to use these as identifiers.  Which I can call out in the action, but since it is till also requiring me to map NAME.





What I think would work as a solution is, on the attributes creation dialog box, you can check a box that allows you to mark that field as an External ID (which would also check the box on the backend of SFDC).  Then in the Load to Relationship action, you have to meet one of the following conditions:




  • Map AccountID and map Name

  • Map Account ID and one of the fields identified as an EXTERNALID
This way we can make more use of loading data into the created attributes.  I realize that we can also create reports from these sub-objects or data sources, but sometimes a customer wants a quicker way to consume that data.





Would love to talk through this more if needed.
I think, what is required here is an update operation on this action which will mandate some identifier and not Relationship identifiers.


Do you think that will work?
Yes, I think that would work well!  Thanks for the reply Sundar.
Sundar -- not sure if this is exactly on point or not... so forgive me if I'm on a different topic.





What I wanted to add is that every record (whether it's native SFDC or MDA) should automatically include a unique identifier -- a synthetic key, if you will. There are any number of uses for this, but easily identifying a specific record for update is something that we don't have when the standard SFDC record ID isn't available.
Adding to this again... when I know the "Relationship ID" I should be able to update the relationship record (using the rules engine) by just making that the sole identifier.
Terms & ConditionsCookie settings