What is everyone thoughts on Jitterbit we are looking to so Salesforce intergration and was wondering what some pit falls people encountered so issue with the system?
go with SSIS with the cozy rock add on suite
1 Like
The main pitfall is not defining the integration points no matter what tooling you are using.
- What are integrating?
- One way? Bisync?
- Customers/Contacts?
- Quotes/Orders?
- Attachments?
- Views?
- Where and how is the workflow split?
- and so many more…
1 Like
also consider, will Epicor acting as basically an MSP in this case meet your needs as well? You’ll lose a lot of control, and responsiveness to changes will become a factor as well as deployments depending on your methodology of software control and development. They only offer it as a service, which in the end steered us away for that reason. It may work for your needs. In the end we decided to purchase jitterbit on our own. We just had our initial kick off meeting this week. More as i know more…
2 Likes
Business user here, so grain of salt! I’ve stepped into an environment with Jitterbit syncing Salesforce and E10. Our existing scheduled transfer are nightly updates for Customers, Parts, typical tables. JB consultants did the setup previously for big $$$. I was surprised to see how much custom code we have for not a lot of usable integration - I’m thinking JB’s “codeless” claims may only apply to the most accessible of systems (I’d count Salesforce in that group, but not E10). Our only effective integration that doesn’t create tons of useless duplicate records is an automated SF Quote --> E10 Sales Order for our simplest type of quote.
I do think Jitterbit’s newer, easier-to-use Cloud Studio environment and brand-new Epicor connector will drastically simplify our upcoming rebuild efforts - but I can’t get the connector to work yet, so it’s too soon to tell.
I’ll second other comments: thorough analysis and DESIGN is what will make or break your project far more than the integration tools you choose.
1 Like
2 Likes
Depending on the complexity(and who maintains it) and if you own Office365, consider Microsoft Flow and using the On-Premised Gateway to Get/Update Data via the HTTP with Azure AD connector with REST. The Salesforce Connectors are pretty straight forward. Once you get the hang of Epicor’s REST Payloads, mapping back and forth isn’t too bad. It cost extra per month for the connectors but it’s way cheaper than Jitterbits pricing model.
That being said, we decided to bring the integration into Epicor after using Flow for 6 months. We now use what we call a BAQRunner, which is an Updatable BAQ, with Advanced BPM Update, that runs on a schedule. In our GetList Base Method is where we have the code to do the sync. We utilize the DeveloperForce Nuget package that wraps the Salesforce REST calls.
Currently we Sync Accounts(one way to SF) , Contacts(both ways) , Cases(which includes the Chatter Feed, one way from SF) . Possibly in the future we will do Products(one way to SF) and PriceBooks(one way to SF) and Orders(both ways).
One of the “integration” options I try to use is the view. Instead of duplicating data everywhere, I suggest a link between records and embed a view of the other system. In SF or Dynamics, I would embed a view of orders, cases, etc. and in Epicor, do the same for CRM data with a browser control or REST + table component. It’s not offline friendly out of the box but when you’re viewing two web sources, that’s probably not an issue. But the data is always up-to-date and no schedules to run. And if you’re hosted in Azure/AWS/Google, you’re only using the resources as needed and not burning cycles on unnecessary background tasks.
It’s more like EDD than EDA. 
Oh, and it upgrades easier too.
Mark W.