If you are a non-profit and use the Non-Profit Start Pack, you might have some concerns. There shouldn't be anything extra you need to do but just in case, we've answered some of the common questions below.
Be aware this guide was written on 1/10/2019 for the current version of NPSP. The account model in older versions was different.
How does SigParser handle Contacts and Accounts in the NPSP?
Will Phone workflow rules break with the NPSP and SigParser's updates?
How are address updates handled between NPSP and SigParser?
How does SigParser handle Contacts and Accounts in the NPSP?
SigParser doesn't have to do anything different for NPSP accounts and contacts if using the latest NPSP account model. The model is close enough to the standard SalesForce Accounts and Contact model that nothing really changes for how SigParser needs to operate.
Will Phone workflow rules break with the NPSP and SigParser's updates?
No, SigParser will set the proper phone field for a contact. From the SalesForce NPSP Documentation docs:
When you change the Preferred Phone or Preferred Email pick-list field values, Salesforce automatically copies the related Phone or Email into the standard Phone or Email field, respectively. For example, if you selected “Mobile” as the preferred phone, Salesforce copies the value from the Mobile Phone field (“609-111-3333” in the example below) into the standard Phone field (which you can see on things like related lists containing Contact information).
How are address updates handled between NPSP and SigParser?
The NPSP Address Management system works nicely with SigParser's updates. Since SigParser never overwrites addresses manually entered, SigParser won't ever set a bad address on a contact. If there are multiple contacts in a household, NPSP Address Management always ensures all contacts in that household have the same address.
What API calls is SigParser making?
SigParser has different types of API calls it makes depending on the need.
Local Cache
SigParser initially fetches a limited set of fields for Users, Accounts, Contacts and Leads. This is needed to reduce API calls during the sync process. The default page size is 2000 records. So if there are 100,000 Contacts SigParser will make 50 API requests to fetch Contacts.
Once the initial sync is complete then on later jobs SigParser will only fetch new or recently modified records.
Create/Update Standard Fields
SigParser can create or update Contacts and Leads in Salesforce and their standard fields. SigParser will look at each of the contacts in SigParser and determine if it meets the rules for either being created or updated in Salesforce.
Using the data from the local cache, if SigParser thinks it needs to create the contact then it will query Salesforce Contacts and Leads (2 API requests). If no matching contact on email address is found then SigParser will create the contact (1 API request).
Using the data from the local cache, if SigParser thinks it could update the Contact or Lead then it will fetch that record from Salesforce (1 API request). It will then compare all the fields in SigParser to the fields in Salesforce. If any fields can be updated by SigParser then SigParser will call the Update API (1 API request).
SigParser will only re-evaluate a contact for create/update if the contact was recently modified in SigParser or Salesforce. This prevents extra API requests.
Managed Package Updates
SigParser will detect if the managed package is installed. Using the data in the local cache, SigParser will look at all the recently modified contacts in SigParser and Salesforce since the last data sync. SigParser will loop thru all the matching contacts in SigParser 200 at a time and make three batch calls to update Contacts, Leads and Internal Relationship Metrics (1 to 10 API calls per 200 contacts).
If a single batch is more than 10MB then it has to be broken up into multiple batches. This is why there is a range from 1 to 10 calls.