Using this thread to address some common questions around piping data from Salesforce with Mitto.
The Mitto Salesforce documentation covers:
- How to use the Mitto Salesforce plugin wizard to initially create Salesforce jobs and sequence?
- How to use Salesforce SOQL to specify a more specific query than
SELECT * FROM OBJECT
?
But what about the following questions:
- New objects were added to Salesforce, so how do we get Mitto jobs for these Salesforce objects?
- Can I use a different Salesforce field for upsert?
SystemModstamp
is the default (and recommended)
Mitto Salesforce jobs are IO jobs that use Salesforce as an input. Learn more about the anatomy of a Mitto IO job.
Adding New Salesforce Jobs to Mitto
One option here is to simply run through the Salesforce plugin wizard again.
Mitto will create new jobs that didn’t previously exist. Mitto won’t automatically add those jobs to the main Salesforce sequence that was initially created on the first run through of the wizard. But, you can add these newly created jobs by hand to any sequence.
If you only want to add one or a handful of new Salesforce objects as Mitto jobs, you can duplicate any existing Salesforce job, edit the new job, and make a few tweaks.
Let’s use duplicating the Salesforce Opportunity Mitto job (which pipes data from the Salesforce Opportunity object) as an example. Our new Salesforce object is fictionally called “NewObject”.
Edit your duplicated job and you will see this job config:
-
Update the
input
'ssobject
with the name of the new object. In our example, you would replace"sobject": "Opportunity"
with"sobject": "NewObject"
. -
Replace the
output
'stablename
with the name of the new table. In our example, you would replace"tablename": "opportunity"
with"tablename": "new_object"
. -
Remove the entire
sdl
object. It relates to fields from the original Salesforce object and isn’t needed on the duplicate job.
You can leave everything else about the job the same. The Mitto Salesforce jobs are configured for upsert and that configuration is the same for the vast majority of Salesforce objects (Id
as primary key, and SystemModstamp
as last updated).
Changing the Upsert field in a Salesforce Job
Speaking of upsert, what if you wanted to use another field in Salesforce as the last modified date? The default (and what we’ve tested and highly recommend) is SystemModstamp
.
The upsert’s last modified field is referenced a few times in a Mitto Salesforce job config:
In the input
:
In the steps
:
In the store
:
So if you wanted to upsert on LastModifiedDate
instead of SystemModstamp
you would make these changes:
- Update the
input
'supsert_field
fromSystemModstamp
to the Salesforce API name of the new field (e.g.LastModifiedDate
). - Update the first
steps
's value ofsystem_modstamp
with the output table’s column name (e.g.last_modified_date
). - Update the
store
'supdated_at
'sSystemModStamp
with the Salesforce API name of the new field (e.g.LastModifiedDate
).