Keep Fields And Reduce Complexity
If you have ever implemented a recipe in CRM Analytics, you have certainly joined the User object to another object, like an Account.
You’ve probably even joined the User object to the same object two times. Heck, you may have even done it three times. Having a User object connected to the same object multiple times is an extremely common pattern; most default objects have at least “Last Modified By” and a “Created By” User, and maybe more.
And that’s just with the out of the box fields for Account. Throw in some custom fields, and the number of times you join one object to another is only limited by the business needs of the client. We have one client whose recipe joins the User object to the Account object five times.
Absolutely not Customer Data, but You Get the Idea
By default, when you have this pattern each of the joins brings across all of the selected fields from the User object. So if the User object has six fields selected, and you have three joins, that means we have 18 fields in the recipe. And unless you’ve edited the attributes of those fields, you have 6 sets of 3 fields, each with an identical label and only slightly different API names. Of course, you are already cleaning up your joins and removing those extra fields, so we’re fine, right?
Well, what happens the next time you need to include another field via the User object? You’re probably only using that field on one of your joins, but now it is coming across via every single one of those joins. So now you have to clean up each and every join every time you add a new field, and I assure you that eventually you are going to forget to do that, and your complexity costs just went up a LOT more than you were expecting. Hopefully nobody gets confused and uses those extra fields before you catch them and clean them up…
So what do we do about this? We’re going to use our friend the Keep statement. You see, what almost always happens in this scenario is that one of your joins is way more important than the others. In our example above, the only field we really want for the Last Modified User and Created By User and our contrived Another User and Just One More User is the “Name” field. Meanwhile, the Owner User has a lot of information we need. We have seen this pattern over and over again, so now we insert a Transform between the User and all of our secondary Joins, like so.
As the name “Keep Only Needed Fields Before Mutli-Join” implies, the only action in this Transform a “Keep”, which Keeps the Id and Name fields.
With this in place,the Keep is a shield that protects the secondary Joins from extra complexity. We can add as many fields as we need for the Owner join via the User object, and none of the other Joins will need to be changed.
A variant of this pattern occurs if you don’t have a ‘primary’ Join in your recipe. If they all need similar fields, you can move the Keep so that it’s before all the Joins.
Of course, if we need to add a new field to one of the secondary Joins, we will need to update the Keep AND we will need to edit the other secondary Joins, but good news: now the Transform node itself serves as visual reminder that we have to make some additional updates and we’ re much less likely to forget them. It’s a win-win!
The “Keep Before Multiple Joins” is not a development pattern that you will use frequently, but if you find yourself joining an object to another object more than twice, consider throwing that Keep in there. It makes everything a little bit less complex.
