Skip to main content

Interesting dilemma. The File_c which is used for attaching files at the field level needs some additional functionality to manage who sees what.

The issue is that the object doesn’t inheret any sharing rights as it’s the record being referenced as a lookup. There really really needs to be some additional considerations to manage this when using this object. Any solution I think of is quite a bit of a hack. Updates to sharing of any kind wouldn’t stay in sync with the File__c record.

Really stumped on this one.


so… You made a custom object File__c and you attach files to it and then reference it from multiple objects?
If I am understanding you correctly, I think the best/fastest solutions would to be to do one or the other:
A) make several of these file__c objects and make each a child of the parent that will be referencing it. You und up with multiple repositories, but each one will follow the permissions of its parent.
Or 😎 have a junction object. I haven’t fully thought this through, but if you create a junction object, it seems that you could create a snazzy way to create a FileJunction__c record that is a child of the parent object and then create the File__c record as a lookup of FileJunction__c. I think this gets you a quasi many-to-many relationship with inherited sharing that you are looking for, but I haven’t thought very much about it, so if it doesn’t work don’t Skuidshame me! If it does work, then you only eat up one master-child relationship on each object which would be to that objects FileJunction__c object. You would still have a single repository for files in File__c. Each object would need its own junction, though, for you to get inherited sharing.


I edited my response above. I meant A or B not A and B.


Sorry. My mistake. skuid__Image__c is the object that I should be referencing.


In either case, the junction object may work. Instead of linking skuid__image__c to a contact, you could link it to Contact_File_Junction__c and make Contact_File_Junction__c a child of Contacts. Then you would have a “gate” between the the contact and the file that would inherit the permissions of the Contact.


That’s my issue. I want to continue using the Skuid field renderer for File Upload as is.


I guess what I am thinking is that now you are using that field on the Contact object. Instead, have the contact object open a pop up that creates a new junction record child of that contact. Then have the junction record have the Skuid field for file upload. A bit convoluted, but it may be the easiest way for you to get your sharing model worked out.


Reply