About Sharing Inheritance

This article discusses file sharing when adding documents to records such as an Account. If you use Folderize original mode (not related to records), see Document Permissions for file sharing options related to that mode.

By default, when you attach a file to a record, it gets shared with all internal users who have access to the record. The level of access is specified additionally as either Viewer (read-only access) or Set by Record (a user gets either read-only or read/write access depending on the access the user has to that record). For information about setting the default sharing type, see Folders for Object-Records (step 4 of instructions for “Setting Up Object-Record View”).

But suppose you want to bypass this logic and manage file sharing explicitly via users, groups or libraries? You can do this for an individual file by following these steps:

  • Lightning:
    • Open the File and click Edit File Details.
    • Find File Privacy on Records field in the popup. By default, this is set to Visible to Anyone With Record Access.
    • Change it to Private on Records. Save.
  • Or in Classic:
    • Open File Details.
    • Click Go to Content Detail Page.
    • Expand the Edit menu and click Edit Content Details.
    • update the File Private on Records checkbox. Save.

This works fine but requires manual intervention for each file. Technically, it’s possible to implement a mechanism (trigger) to implement this logic automatically. There are various possible use cases; here are two:

Scenario 1

This is simplest scenario when you need to stop inheriting access from all records for all files. Key features:

  1. Each time when a user uploads a document, the mechanism sets Sharing Privacy to Private On Records.
  2. Optional: If a user tries to change the privacy back to Visible to Anyone With Records Access, the mechanism either throws an error or change it back to Private On Records silently.

Scenario 2

In this scenario, you can enable the mechanism for some objects but not for others. Key features of the solution:

  1. There is a list of selected Salesforce objects which require privacy for files.
  2. Each time a user attaches a file to a record of an object in list (A), the mechanism enables privacy for the file.
  3. Optional: If a user detaches a file from a record, the mechanism checks whether this file is still attached to other objects that require privacy. If not, the mechanism changes the privacy to Visible to Anyone With Records Access.
    For example, let’s say Account requires privacy, but the Opportunity does not. File1 was attached to one account and one opportunity and, thus, its privacy was enabled. Then somebody, who has access to the file, removed it from the account. Now File1 is attached only to an opportunity (which does not require privacy). Should the mechanism disable privacy for the file now?
  4. Optional: If a user tries to manually change the privacy of a file back to Visible to Anyone With Records Access, the mechanism checks whether this file is still attached to other objects that require privacy. If so, then the mechanism either throws an error or changes the privacy to Private On Records silently.

Creating the Trigger

Instructions to implement a trigger as outlined above are beyond the scope of this user guide. If needed, ShareMethods, publisher of Folderize, offers the option of a short consulting engagement to help configure triggers according to your needs. If you might be interested in this, please contact support@sharemethods.com. In your email it will be helpful to answer the questions below.

1. What scenario do you prefer (scenario 1, 2, or a custom one)?

2. What optional features of the scenario do you need?

  • Scenario 1:
    a. Do you need the protection described in KEY FEATURE B?
    b. If you answered “YES” to the above question, would you like the mechanism to throw an error to a user when he tries to disable privacy? Or would you like the protection to happen silently, i.e., the privacy would be enabled again in background without notifying a user.
  • Scenario 2:
    a. What Salesforce objects do require privacy on files attached to them?
    b. Do you need the KEY FEATURE C?
    c. Do you need the protection described in KEY FEATURE D?
    d. If you answered “YES” to the above question, would you like the mechanism to throw an error to a user when he tries to disable privacy? Or would you like the protection to happen silently, i.e., the privacy would be enabled again in background without notifying a user.
  • Custom scenario: Suggest your key features.

3. If you have existing files with disabled sharing privacy (the default in Salesforce), you will probably want to change them too:

  • Do you have legacy files that must be updated too?
  • If you answered “YES” to the above question, how many legacy files do you have?

4. Do you need to change behavior of the mechanism via settings? For example:

  • Enable/disable the mechanism;
  • Enable/disable the protection;
  • Change the list of objects that require privacy (Scenario 2). Is re-processing of all files needed after this change?
  • Anything else?