Salesforce IDs not pulled back into WordPress (sometimes)

  • Resolved metricmedia

    (@metricmedia)


    2 years, 6 months ago

    We are trying to get a better understanding of how Salesforce record IDs get to WordPress. In this example, for WordPress users who become Salesforce contacts.

    A user registers in WordPress. Assuming we have a fieldmap for users with WordPress Create enabled, this results in a sync to Salesforce. The sync includes a temporary Salesforce ID. The sync creates a new contact record at Salesforce, which includes generation of a valid Salesforce ID that is saved in that record.

    Under what conditions is that Salesforce ID pulled back to WordPress and replaces the temp ID in the wp_object_sync_sf_object_map table?

    – Is this considered a “Salesforce Create” (though we didn’t create the record IN Salesforce, it “was created in Salesforce” (by the sync)), and so we would need to have Salesforce Create enabled as a sync trigger in the fieldmap?

    – Or is there an automatic pull that should occur after pushing to get that Salesforce ID back to WP, regardless of the status of Salesforce Create?

    We are finding that temp IDs are not always being updated in the WP database. We have Salesforce Create disabled in the fieldmap because the client doesn’t want every record entered into Salesforce to end up in WordPress. If that’s the problem, we can look into other ways of controlling which records end up in WP.

    We also have a somewhat unique setup in that we don’t always push users to Salesforce when they are initially created. We allow a user to register with only an email address, and we don’t want to push those “thin” users to Salesforce to avoid crowding the contacts table with records that have no first and last name.

    Later, if a user creates an order, we DO request the additional necessary user fields (name, etc), update their user in WP (which still has a temp SF ID), and at that point push the user (and order) to Salesforce.

    I am assuming the plugin would consider this a “WordPress Update”, right? Since the user already existed in WordPress.

    If we are creating a new Salesforce customer via WordPress Update, rather than via WordPress Create, would that have an effect on WordPress pulling the Salesforce ID back into the wp_object_sync_sf_object_map table?

    Thanks!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Jonathan Stegall

    (@jonathanstegall)

    I’ll see if I can answer all of these one at a time:

    1. “Under what conditions is that Salesforce ID pulled back to WordPress and replaces the temp ID in the wp_object_sync_sf_object_map table?”

    As long as WordPress create is checked in the fieldmap, the plugin should replace the temp ID once the record is successfully created in Salesforce. As long as there are no errors in the response from Salesforce, the plugin looks for the new record’s ID and replaces the temporary one with it as soon as the API responds. If there is an error, it should instead create a log entry (according to the plugin’s log settings).

    I’d be interested to see cases where the plugin does not receive an error from Salesforce but also does not replace the temporary ID, especially if those cases could be isolated to see what’s causing them.

    2. – Is this considered a “Salesforce Create” (though we didn’t create the record IN Salesforce, it “was created in Salesforce” (by the sync)), and so we would need to have Salesforce Create enabled as a sync trigger in the fieldmap?

    No. A Salesforce Create is designed to detect when a new record is created in Salesforce and you want the plugin to respond to that event. You certainly don’t have to store every record from Salesforce in WordPress (we don’t use Salesforce Create at MinnPost, for example).

    3. – Or is there an automatic pull that should occur after pushing to get that Salesforce ID back to WP, regardless of the status of Salesforce Create?

    It’s not an automatic pull but, as I described in #1, the plugin does read the response from Salesforce.

    4. We also have a somewhat unique setup in that we don’t always push users to Salesforce when they are initially created.

    This could be part of the issue. I’m not really sure how that would work. I think it’s possible that this is causing the problem, but I’m not really sure how the initial push is running. You might want to see what happens if you do push the records to Salesforce when they’re initially created. Not because that is necessarily a solution but because it might at least identify if this is where the problem is.

    5. Later, if a user creates an order, we DO request the additional necessary user fields (name, etc), update their user in WP (which still has a temp SF ID), and at that point push the user (and order) to Salesforce.

    Yes, the plugin would consider this to be a WordPress update because the WP record already exists. However, it would fail if the temporary ID was there but had not been replaced.

    If there wasn’t already a temporary ID, I think the plugin would skip it, since it would see that you were updating an existing user rather than creating a new one, but the plugin doesn’t trigger an update if there isn’t a record in the wp_object_sync_sf_object_map table.

    Plugin Author Jonathan Stegall

    (@jonathanstegall)

    I think it’s also possible that there might be something in the server error logs, if the plugin is failing to replace the temporary ID but it is also not creating any plugin log messages. You might check both plugin logs and server logs to see if something is happening that the plugin does not expect.

    Thread Starter metricmedia

    (@metricmedia)

    Thanks for the quick and thoughtful response.

    I believe we ARE getting errors when doing those “updates-that-aren’t-really-updates”. We’re going to test a bunch of things now. We’ll report back.

    Thread Starter metricmedia

    (@metricmedia)

    OK – we worked this out.

    The problem was our registration form had no name fields, but we required LastName in Salesforce, so on registration the sync would fail. And generate an error, consistenly.

    We added name fields to the registration form and now registration goes through and everything works perfectly. Another option would be to remove the requirement for LastName.

    We used this as a guide:
    https://www.cloudways.com/blog/add-woocommerce-registration-form-fields/

    But it didn’t work at first, because we were only adding the name fields to user_meta on Woo Customer Create, which apparently happens after the sync. We modified it to run after registration and it now works perfectly.

    Thanks for the help!

    Plugin Author Jonathan Stegall

    (@jonathanstegall)

    Thanks for replying! It made me think of a possible addition to the plugin. I’m not sure if it’s possible, but it would be nice to determine what the required fields are even if they’re not being mapped. For example, we do show that the last name field is required in the field list, but probably nobody would see this if they didn’t try to map that field.

    Anyway, I’ve made a GitHub issue so I don’t forget: https://github.com/MinnPost/object-sync-for-salesforce/issues/493

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Salesforce IDs not pulled back into WordPress (sometimes)’ is closed to new replies.