@MelissaC Sounds like you may need to open a Gainsight Support ticket to look at your specifics.

That said, one behavior to know about the SFDC Connector sync: If you run a Connectors Job manually, depending on the radio button you select pertaining to what to sync, you may only be syncing records with a “Last Modified Date” more recent than the previous Job run. You might try making a trivial edit to the SFDC Account record so that it attains a fresh “Last Modified Date” and therefore is in-scope to be synced. 

Hi @matthew_lind !

From my SFDC guy:

I just can't tell if it was "Last Modified" by Gainsight.  I just turned-on field history tracking for the "Gainsights Account Health" field and the other related health measures tracked in Salesforce.  This will help us track if and when those fields are actually being updated by Gainsight.  I assume we will have some changes over the next 24hours.  I will set up a report so we can see if any updates are being made by Gainsight as a higher level audit of the sync.

Is there anything else you think we should do?

Ack, @MelissaC , I misread your original question. A couple things which may help:

• The Salesforce Connector in Connectors 2.0 is currently one-way only. Jobs built on it move values from Salesforce to Gainsight. (I misread your original post thinking you were moving data from SFDC to Gainsight, and now I understand you’re actually trying to move data in the other direction, from Gainsight to SFDC.)
• Moving values from Gainsight to SFDC most often is done via a Bionic Rule. Here’s a good link covering an example of writing data from Gainsight to SFDC. This example is writing to a SFDC Contact, but the principles also apply to writing to a SFDC Account.
• You’ll need to determine if you have a Bionic Rule already in place to write your Gainsight health score to SFDC. If you do, that’s the place to start. If that Rule running as expected? Look at the Execution History for evidence it’s running and that it’s running error-free. If it’s running well, are there any filters or configurations within the Rule that cause this particular Account to be out of scope?
• For your SFDC Admin, he’ll want to be looking for records updated by the OAuth user. That’s the SFDC User which was used when this authorization step was completed. It’s that SFDC User who will do all “writes” to SFDC, and that’s the SFDC User that will appear in the Field History Tracking. That won’t necessarily be your own SFDC User (and as a best practice, likely shouldn’t be your own SFDC User).

Hopefully this is helpful!