Object Sync for Salesforce maps and syncs data between Salesforce objects and WordPress objects.
For any supported WordPress content types (e.g. post, page, user, or any supported custom content type in your installation), you can assign Salesforce objects that will be created / updated / deleted when the data in WordPress is saved, and the WordPress objects can be created / updated / deleted when the data in Salesforce is saved.
For each such combination of object and content type, choose which fields should be mapped to one another, creating a fieldmap. The plugin acts on matching data after it is installed.
This plugin also includes developer hooks that allow for additional plugins to modify what data the plugin is working with, or what happens upon specific events.
The plugin documentation contains initial setup instructions. This is the fastest way to get the plugin running on your site.
We maintain extensive documentation of the plugin beyond its installation process as well, including its developer hooks. This documentation also exists in the plugin’s docs
folder when it is downloaded.
WordPress stores metadata as key/value pairs in its database. Many plugins and themes use this method to store custom field data. Object Sync for Salesforce supports mapping these fields (many other plugins use non-standard methods, and this plugin may or may not support them).
There’s a helpful spreadsheet (we are not affiliated with it, we just think it’s useful) comparing various options for custom fields you can review. If the plugin you wish to use uses Meta-based Storage (listed in the spreadsheet), you should be able to use it with Object Sync for Salesforce, but how well they work together will vary. Plugins with full meta compatibility (also listed in the spreadsheet) may work the best, but you don’t have to restrict yourself to those.
Object Sync for Salesforce, however, cannot see meta fields before the field has at least one value in the database. For example, if you have a “testfield” on your user object, it won’t be in the fieldmap options until there is at least one user that has a value for the field.
If you load Object Sync for Salesforce and then store data for a new meta field after this load, make sure you click the “Clear the plugin cache” link on the Fieldmaps tab.
Related to the mapping of custom fields, but raising its own distinct questions and problems that can make this plugin more complicated, is the issue of mapping between required fields in WordPress or Salesforce.
How WordPress handles meta fields
This plugin runs on WordPress’ core actions for user, post, comment, attachment, and term objects, which run when those objects are created or deleted. This plugin also runs on WordPress’ meta actions for those objects. The way WordPress works is that these actions don’t happen together, so metadata is generally not part of the core action’s dataset.
How this affects required fields
The way these actions work means that if a field is required in Salesforce, it needs to be sent as part of the first, core WordPress action associated with the WordPress object. If it is only added as part of the second action, the metadata, it will not be sent and the Salesforce operation will fail.
How this works in detail can vary for different WordPress object types. Some examples:
user_register
action. The initial action has access to data stored in wp_user
. It also has access to some fields that are stored in wp_usermeta (first_name
and last_name
), but it does not have access to custom user fields.save_post
action. This means it has access to data stored in wp_posts
only, not data stored in wp_postmeta
.create_term
action. This means it only has access to the Term ID, Term Taxonomy ID, and taxonomy data, not other custom fields.comment_post
action. This means it has access to the comment ID, whether the comment is approved, and the comment data array.Again, this all applies to the first operation the plugin runs, which is when Salesforce will expect to receive required fields.
If you are storing a required field’s value in a meta field in WordPress, you will run into errors if it is not sent as part of the first action.
This plugin was built to sync data that is created after it was installed. However, there are some techniques that can import pre-existing data. See the Import & Export section of the documentation for methods you can use for this.
Object Sync for Salesforce does not and will not “officially” support ACF because you don’t have to use ACF to use WordPress or to use Salesforce. However, they are generally usable together.
Things to know:
test_field
to a Contact_description
field. The fieldmap screen will show a _test_field
in the dropdown, but you should be able to safely ignore that, and only map test_field
.While we will not include code that only runs for ACF in this plugin, we would happily point to any add-on plugin that uses Object Sync for Salesforce hooks to build a more comprehensive integration with ACF for all users who install this plugin while they’re running ACF.
Object Sync for Salesforce doesn’t have, and will not have, intentional support for WooCommerce. It kind of supports it, to the extent that WooCommerce uses WordPress’ default ways of creating objects and data. WooCommerce is very complicated, and on top of that it often deviates from those default WordPress methods, and it’s certainly possible that this plugin won’t support it when it does.
This doesn’t mean you can’t use them together, but it does mean this plugin is not intentionally built for that purpose. Because WooCommerce is not a requirement to use WordPress, or to use Salesforce, it will never be built directly into Object Sync for Salesforce.
Object Sync for Salesforce does have abundant developer hooks, and WooCommerce has its own API, and it would be possible to build an add-on plugin to provide full support by integrating these (we would happily point to it for all users who install this plugin while they’re running WooCommerce).
If you are having trouble setting up or configuring the plugin, we’ve provided answers to some common problems in our troubleshooting document. Expanding this document is also a great way to contribute to this plugin.
There is extensive documentation of this plugin, including its developer hooks, on GitHub. This documentation also exists inside the docs
folder when you download the plugin from the WordPress directory.
We make an effort to answer support requests in the WordPress plugin forum. If you have these requests, please put them in that forum only. Do not send them by email or by social media.
While MinnPost’s nonprofit newsroom does welcome donations to support our work, this plugin does not have a paid version.
Use the plugin’s GitHub repository for bugs, feature requests, and other additions and especially do that if you can help solve these things.
WordPress developers can use hooks in this plugin to extend its functionality. These are listed, with links to each hook’s documentation, in the developer hooks documentation, and are frequently mentioned throughout the plugin’s documentation.
We host a document intended to list plugins that use these hooks or otherwise extend this plugin, and we welcome additions.
If you’d like to suggest a feature, or if you think you’ve encountered a bug, you can create an issue on our GitHub repository. We actively add our own issues to the list, and comment on their progress.
We welcome contributions of code, documentation, or translations to this project from other developers. See our contributing guidelines.
This plugin can be relatively complicated, and sometimes other plugins can effectively integrate Salesforce and WordPress, especially if there are more limited, specific requirements. If one of these can meet those requirements, use it. We’re happy to link to additional choices here, as well.
See our full changelog for information about all previous releases.