PROJECT OVERVIEW (Please read this first)
In June, 2015 we designed and implemented a solution for a client that allows for the exchange of information between their Salesforce instance and 3 sites on a Wordpress Multisite network. Of the 3 sites, 2 are private BuddyPress community sites and one is the client’s primary public-facing site.
The client currently only uses a small component of the original system (#2 below), but the following user actions were all enabled as part of the original feature set (which still exist in the build):
1) Admin users can create and update BuddyPress community member accounts and profile information (including avatars) directly from within Salesforce.
2) Admin users can create and update a “Bio” custom post type information on the main public-facing site (including avatars). This process occurs simultaneously with the creation or update of the BuddyPress member profile info, as each “Bio” post corresponds to a member of one of the two BuddyPress communities.
3) End users of the BuddyPress community can update their profile information in BuddyPress. It will change immediately only within BuddyPress. After the update, a notice is sent through Salesforce alerting the Admin, giving them the following three options:
a) accept the updated information into Salesforce overriding the previous data,
b) reject the updated information and push the original Salesforce data back into the BuddyPress community, or;
c) ignore the change, leaving the information changed in BuddyPress, but not in Salesforce.
4) Admin users can access a Contact Reconciliation Report in Salesforce which shows where conflicts exist between Salesforce field data and BuddyPress field data. (The “Bio” custom post type data always matches what is in Salesforce, so is not shown on the report). To reconcile the data in the report, admins can click a button for each conflicted field to determine which data source should override the other. Regardless of whether the Admin chooses to override the Salesforce data or BuddyPress data, the “Bio” custom post type on the front end is populated with the data that is retained in Salesforce (which is the “Master” data source).
CURRENT PROJECT REQUIREMENTS & NOTES
We need two new fields from the Salesforce contact page to be linked to the “Bio” custom post-type on the public-facing site ( the “Start Date Title”, and the “Start Date Organization” fields), so the client can continue using Salesforce to create and update the “Bio” custom post type on the main public-facing site). Our main focus is that the client is able to initiate the push from Salesforce to the “Bio” custom post type the same way they have been doing it-- so no extra time needs to be given to working on any of the BuddyPress or Report components that don’t affect the client’s ability to push from Salesforce to the Bios, (though the easiest way to implement will likely be to just add the two new fields within the context of the existing solution). We will handle styling the output of the files in the existing custom post types.
At some point in the future, we will be doing a complete redesign of the public-facing site, at which point we will remove the BuddyPress sites, and rework the connection with Salesforce so it consists of a simple one-way push from Salesforce to the custom post types… but that is not in the scope of this project.
We will provide you with a dev instance of the multisite network and a sandbox version of the Salesforce sandbox to work with. Once you have worked out and tested your solution, you will also need to deploy it into the production instance.
**You must have experience deploying Salesforce Apex Components from a sandbox into production**
Current solution uses custom Apex classes in Salesforce along with custom Wordpress templates linked to blank pages, and JSON API.
EXAMPLES OF THESE FILES ARE ATTACHED.
February 6, 2018
I am looking for a mix of experience and value
January 13, 2018
Project Stage:Fully Specified
One-time Project:Small enhancement to an existing solution