Forum Discussion

NAl's avatar
NAl
Contributor
4 years ago

Records not marrying up based on Email

I have a pipeline which is pulling data from 2 salesforce orgs. These data sets are then combined and matched based on the email address using a sort and join (left outer) snap. The end result is an upsert operation is in 1 of the orgs.

When executed, the pipeline fails because our duplicate management rule in salesforce is triggered since it is trying to create rather than update a record with an existing email address.

My question is why isn’t this being picked up through the salesforce read snaps and being mapped through the join? What am I missing

9 Replies

  • del's avatar
    del
    Contributor III
    4 years ago

    @Nai,
    If Email is not required to be unique across Org 1, then it may be possible the same email address exists on more than one record in Org 1, thus producing multiple records with the same email address in the Join output. Each duplicate would follow the same path in the Router output toward the Create snap (or Upsert snap).

    • NAl's avatar
      NAl
      Contributor
      4 years ago

      Hey all,
      So I stepped back from the pipeline, had a brainstorm and increased the batch size from 2000 to 10,000 on the Salesforce Read Snap and this seems to have done the trick.

  • bojanvelevski's avatar
    bojanvelevski
    Valued Contributor
    4 years ago

    If the record is picked up by the Duplicate management rule, that means that it is not joined properly in SL. Could it be a case sensitivity issue? I don’t know about Salesforce, but SnapLogic is case sensitive, so you may try and add a .toLowerCase() method after you read the records.

    • NAl's avatar
      NAl
      Contributor
      4 years ago

      There’s another record that exists in both systems which is correctly identified in the join snap.
      The email addresses on both records which is firing the duplicate management rule, for has the exact same spelling and case used. Salesforce’s duplicate rule is based on a an EXACT match for email addresses.

  • SpiroTaleski's avatar
    SpiroTaleski
    Valued Contributor
    4 years ago

    @NAl

    Did you try to get the data from two different Salesforce org and insert into third one? If yes, before upserting the records in the target org, you should query/check if the record with the given email address(if this field is unique field in the target org) exist in the target org. If exist update it, if not exist create new one.

    If you are using Salesforce Upsert Snap, then you should have an unique external id field(in your case email address) setup that is required for this action. Based on that field, Salesforce will decide if the operation will be create or update.

    Regards,
    Spiro Taleski

    • NAl's avatar
      NAl
      Contributor
      4 years ago

      Hi Spiro,
      For context are comparing datasets extracted from Org 1 and Org 2.
      The Join snap uses the Email address from both sets as the join paths.

      If records from Org 1 does not have a corresponding record (Id) in Org 2, they are created in Org 2 using a Salesforce Create snap.
      If records from Org 1 does have a corresponding record (Id) in Org 2, then we update the record in Org 2 using a Salesforce Update snap.

      If the email exists in both orgs, I’d expect this to be handled by the Join snap?


  • SpiroTaleski's avatar
    SpiroTaleski
    Valued Contributor
    4 years ago

    @NAl

    If there is an match on email addresses from both orgs, then based on your logic it should go on update branch.

    After the Join Snap, I suppose that you have a router snap where you are routing create/update messages. Can you please share the conditions inside the router snap?

    Regards,
    Spiro Taleski

    • NAl's avatar
      NAl
      Contributor
      4 years ago

      That’s correct, in our Router it’s just looking at the whether the Id is populated or not:

      $Id != null - EXISTS > go to update snap
      $Id == null - DOES NOT EXIST > go to create snap

  • SpiroTaleski's avatar
    SpiroTaleski
    Valued Contributor
    4 years ago

    @NAl

    Then, it remains what @bojanvelevski said. Maybe it was an case sensitivity issue.

    Since SnapLogic is case sensitive, and in order to avoid duplicate scenario, before the join snap you can add .toLowerCase() on the field that you are using as an join key.

    Regards,
    Spiro Taleski