Great question @gregpowell!
There are several factors that play into your Mitto Salesforce situation:
1 - A Mitto IO job that uses Salesforce as an input uses a specific Salesforce user for authentication. Authorization is handled by the Salesforce API, so only objects/fields that user has access to in Salesforce are able to be piped by Mitto.
Here’s an example input:
2 - Mitto Salesforce jobs created via the Salesforce plugin wizard are configured for upsert (against both the Mitto store and the output database table).
Here’s how the store is configured for upsert:
And there are several steps involved in the table upsert:
In the example input above, when Mitto queries Salesforce for the Opportunity object data, it includes a filter using the
SystemModStamp. Only records with a
SystemModStamp greater than or equal to the maximum
SystemModStamp Mitto finds in the store are piped back from Salesforce.
So, with the combination of #1 and #2 above, if a new field is created in Salesforce that the user has access to and that new field updates the
SystemModStamp of every record in the table, then the output table will sync the new field and update all records.
However, in the case of a permission change for the Mitto Salesforce user, odds are the
SystemModStamp isn’t going to update just because the user has access to a new field. So only records that are added/updated after the permission change will show up in the output table over time.
In this particular case, you should perform a full refresh of the associated Mitto job and output table.
How to do a full refresh of a Mitto Salesforce job with a store and upsert?
- Delete the Mitto store
- Rename, truncate, or drop the output table.
- Rerun the job to recreate the store and output table.
You can also duplicate the Mitto job and change the name of the output table as an alternative. Mitto stores are tied to the name of the Mitto job, so a duplicated job has no store when it is created.