0

I'm working on a project where we have to import data from a client's old system and it does not quite match the schema of the objects we're choosing in Salesforce.

One example is that the table we're importing into Case has a many-to-many relationship with the table we're importing into Asset (i.e. a customer called about a problem with several of our products that they own). Case has an existing lookup to Asset, however some of the records point to multiple Assets. Granted this is only a minority of Cases: less than 0.5% of them.

So one strategy could be, for every Case with multiple Assets, create a parent Case with child Cases and each child points to one Asset. The other content of the Case would just be duplicated on import.

Another strategy is a junction table, but now we have to grapple with the fact that there's already a lookup relationship. The majority of Cases we import only have one Asset, so do we fill in the standard Asset field for those and use the junction table only for the multi-Asset Cases? Or should we not use the standard field at all and let the junction table also include entries tying all single-Asset Cases together as well?

I've been thinking about this way too much so I thought I'd ask the crowd for some advice. Thanks :)

Improve this question
4
  • 1
    To me, if I had a business that sold phones and someone had bought an iPhone and a Samsung and had problems with both, that'd be two separate Cases? – Dan Jones Oct 7 '16 at 15:38
  • Sure that makes sense. This company does field service and the business logic is that if someone makes one call saying they need on-site preventative maintenance done on 3 of our products, they want it all on one invoice. – Charles T Oct 8 '16 at 15:06
  • I'd say in that instance you'd need an Invoice object that each case was assigned too. – Dan Jones Oct 10 '16 at 8:03
  • If they're done as children of a parent case, the invoice could attach to the parent. – Charles T Oct 11 '16 at 14:05
1

I'd go with parent-child cases. This keeps them related together in a coherent manner. Looking at a child case will show the parent case, and from there, all related children. To be certain, however, I'd suggest mocking a few records first to see what it looks like.

Improve this answer
1
  • That's fair, and I'm already leaning in that direction. My plan is, once we've set up all the requisite schema, I'll create a Developer Sandbox that takes a snapshot of the metadata, and use Data Loader to populate it with the real data. Due to dependencies within the data, I'm using external ID fields and have to load in the order: Product, Account, Contact, Asset, Case, Work Order, and then service reports (via Field Service Lightning objects). Any necessary pre-load transforms I can easily script outside of SFDC. – Charles T Oct 8 '16 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.