0

I would like to associate Files with Big Object records.

Documentation inference implies this is not technically possible... if a Big Object could be a "LinkedEntityId" I imagine it would have been spelled out.

And finally, my attempts to directly associate a ContentDocumentLink with a Big Object record via LinkedEntityId failed. The platform won't allow a save on the ContentDocumentLink.

In light of this... what would be the best-practice way(s) to associate Files with a Big Object records?

1 Answer 1

0

I would say the "best practice" is don't do it. I don't really feel like that is the right use for Big objects (that is strictly an opinion though).

You could try to create a junction object, one that is supported as a linkedentityId that can reference the big object. From this question it doesn't seem to me that a direct lookup to a big object is possible (which makes perfect sense as it shouldn't be) but it does offer a workaround that allows for associating custom objects to big objects that you might be able to leverage.

At the end of the day it wont behave exactly as it would for other objects, but it would get you as close as possible.

Otherwise, consider swapping your big object to a custom object. If you have a ton of data in the object you may need to include an archiving strategy or remove the data from SFDC altogether.

1
  • thanks for responding. However... asserting best-practice based on your feelings is... not quite the answer I was looking for :) The problem I am trying to solve is simple and reasonable... archive old records via Big Objects, and preserve File associations. A junction sObject between File and Big Objects defeats the purpose of moving old sObjects into Big Objects as there would be no savings in terms of sObject record count, simply a shift in records to the new sObject junction table.
    – krigi
    Mar 6, 2019 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .