jCustomer - Salesforce Connector

Fixed

• The admin screen's cards take the full width of the window, with the same margin on both sides; they stopped at 1200 pixels and left the right side of wide windows empty.

2.6.5

• Value if empty for picklists: chosen from the Salesforce field's own values, several of them for a multi-select picklist.
• The mapping warns about values Salesforce would refuse: a value outside a restricted picklist, or a multi-valued jCustomer property mapped to a single-value picklist.

2.6.4

• Maintenance release: faster builds, no change of behaviour.

2.6.3

• Field mappings are saved only for the Salesforce objects the connector maps (Contact, Account or Lead from Salesforce; Lead or Contact to Salesforce).
• The module is now built and tested automatically for every change and every release.

2.6.2

• Converted Leads: once Salesforce converts a visitor's Lead to a Contact, their changes now update that Contact. Before, every update failed, and a visitor without a stored Lead could be created again as a duplicate Lead.
• Value if empty and fixed values in the jCustomer to Salesforce mapping: for example Company = Web visitor, so that visitors who gave no company become Leads instead of being skipped.

2.6.1

• Fixed: after a bulk import or a busy campaign, changes beyond the first 500 profiles were not sent to Salesforce. Every change since the last run is now sent.
• Fixed: a profile that could not be sent (Salesforce unreachable, a validation rule) was not tried again. It is now retried by the next runs, 5 times in all, and shown in the history if it still fails.

2.6.0

• Automatic purge of the sync history, set per direction in its History tab: runs older than 30 days (or the number of days you choose) are deleted every hour. The history holds personal data, so it is no longer kept indefinitely.
• History stored by day, so that it stays fast however many runs it holds. Existing history is reorganised automatically when the module starts.
• Fixed: opening a run on the second page of the history or later went back to the first page.
• Error messages from the server are shown in full in the administration screen.

2.5.0

• Redesigned administration screen in Jahia's design system, with a new Overview tab: the connection status, each direction's triggers, mapping coverage and last run, and what needs attention with a button that opens the screen that fixes it.
• Each direction has three tabs: Mapping, Triggers and History. Schedules read in words, Save is enabled only when something changed, and results appear next to the button that produced them.
• History: every field changed for a person is visible when a run is expanded; dates read 5 minutes ago, the exact date on hover.
• Fixed: a single value of a Salesforce multi-select picklist left the multi-valued jCustomer property empty. Values now follow the property type; profiles affected are repaired on their next sync (run Sync now after upgrading).
• Security: actions that change something (save, sync, push, purge) are protected by Jahia's CSRF guard again.
• The screen fits narrow windows and works with the jContent versions of Jahia 8.2.3 and later.

Full history: CHANGELOG.md

2.4.1

Fixed

• An inbound sync (login or manual) of a profile that already holds the Salesforce values is no longer reported as an error. It is recorded as “skipped: already up to date”, and only the values that changed are sent to jCustomer.
• History tab: the Refresh, Export and Purge buttons could be pushed off screen on jContent 3.8 when a run had a long status. The screen now fits its container, and long messages wrap.

Changed

• Inbound history records list only the fields that changed.

2.4.0

Added

• Sync history for each direction (SFDC to jCustomer, jCustomer to SFDC): one row per run, with when it ran, what triggered it, and how many records were created, updated, skipped or in error. Expand a run to see each record: who, the Salesforce record, the fields written, and why a record was skipped or failed.
• Export CSV / Export JSON of a direction’s history, and Purge history with confirmation.
• History retention can be configured (history.max.runs, history.max.records.per.run, history.max.value.length). Scheduled runs that found no change are not recorded.

2.3.5

Fixed

• jCustomer to Salesforce: “Profile updates” did not push anything automatically. The poll now runs whenever “Profile updates” or “Form submissions” is on.
• The Triggers tab shows the stored settings: a trigger that was never saved is shown as off.
• Results now report created, updated, skipped and errors separately; a profile that was not sent is no longer counted as updated.

Changed

• Profile changes are polled every 5 minutes by default (outbound.poll.cron). A schedule chosen in the Triggers tab still takes precedence.
• Turning a trigger on pushes changes made from that moment, with no backfill. The poll is skipped while the Salesforce connection is disabled.
• The separate “Enable scheduled sync” switch is removed.

Hardening release: nothing hardcoded in the module.

Fixed

• sfdc.api.version is now actually used. It was documented but never read, because the API version was hardcoded in the code, the CND default and the admin UI. One source now: the Connection's API version when set, else sfdc.api.version from the OSGi configuration. A missing version is reported as an error instead of being guessed.
• Connection tab text (labels, placeholders, hints) comes from the EN/FR locale files. Some of it was hardcoded in French for every language.
• Private key guidance is correct: only an unencrypted PKCS#8 PEM (-----BEGIN PRIVATE KEY-----) works. The hint gives the conversion for PKCS#1 keys: openssl pkcs8 -topk8 -nocrypt -in old.key -out key.pem.

Changed

• The API version field stays empty unless you set it, and shows the configured sfdc.api.version as its placeholder, so saving the form no longer pins the default on the connection.

Upgrade

Deploy the jar; no migration. Existing connections keep their stored API version.

Bug-fix release. Salesforce to jCustomer updates now actually reach jCustomer, on any project, Jahia Cloud or on-premise.

Fixed

• Inbound updates were silently dropped. Profile updates sent a custom updateUserEfficyPortalData event that only one demo jCustomer had a rule for. Every other jCustomer accepted it and changed nothing, while the log said Login sync complete. Updates now use Unomi's standard updateProperties event, signed with the jCustomer key from the site's jExperience settings. No custom jCustomer rule and no extra configuration: it works wherever jExperience works.
• Dropped updates are reported. The jCustomer response is checked, and a refused update logs an explicit error naming what to check. The login sync logs one of: profile updated, Salesforce record found but nothing updated, no Salesforce record.
• "Sync now" (inbound) always ran against a hardcoded site, and the outbound scheduled reconcile ignored the configured site and buffer.
• A failed Salesforce-id writeback no longer fails an outbound push that Salesforce already accepted.

Changed

• No project-specific defaults. The site is resolved in this order:

  1. The site the admin UI is open on (manual runs).
  2. jcustomer.site.key, when it names an existing site.
  3. The single site with jExperience installed.

  jcustomer.site.key now ships empty. A stale value that is not a site on the server is ignored with a warning.

Upgrade

Deploy the jar; no migration. If several sites have jExperience, set jcustomer.site.key in org.jahia.community.jcustomer.sfdc. If the log shows jCustomer did not update profile ... updated=0, jCustomer refuses updateProperties for jExperience's key or this server's address: check jCustomer's third-party settings (UNOMI_THIRDPARTY_PROVIDER1_*). This is the same setup jExperience needs for its own login events.

• Mapping dropdowns sorted alphabetically. The jCustomer-property and Salesforce-field pickers (both sync directions) now list options alphabetically (case-insensitive) instead of fetch order, so a long property list is predictable to scan. (jCustomer's own picker groups by card; matching that needs per-property Unomi group data the connector doesn't pass yet, so alphabetical is the equivalent.)
• Operator config now survives a redeploy. The shipped org.jahia.community.jcustomer.sfdc.cfg gained the # default configuration marker, so Jahia installs it only when absent. Previously every module redeploy overwrote it, wiping any jcustomer.url / credentials and silently dropping the live property lookup back to the generic fallback. Existing installs keep their current config; no action needed.

No migration required; deploy the jar.

Authentication JSON handling hardened; Salesforce API-client input validation.