2

I'm trying to find out how to programmatically create a Sharing Access Rule for a custom object when an event occurs.

For example, I have a Community active with some Portal users. Whenever one of the portal users is enabled for a specific internal procedure (an Assignment__c is created), I need to share with that specific user the rules of the parent object of the Assignment__c created previously (Project__c).

To do so, I manually open the Project__c mask, click on "Sharing" button, "Add new" and select the portal user I want to share the Project settings with.

I'm trying to find a way to automate this process, more specifically I was trying to understand what kind of data, object, string or whatever is created when a new Sharing Access rule is created, to simulate it with some APEX code.

enter image description here

I hope I've explained my issue clearly, I've already worked on automating more complex processes that included Permission Sets and Licenses.

I'm here because I can't find proper documentation online about this specific type of Sharing rule.

Improve this question
3
  • Have you reviewed documentation such as Sharing a Record Using Apex?
    – Keith C
    Commented Aug 4, 2017 at 11:47
  • Thank you SO much Keith, I checked a lot of documentation, but probably I missed that page, I was exactly looking for this. I wasn't aware of the existence of the Schema object. Thank you a lot!
    – Alberto
    Commented Aug 4, 2017 at 11:52
  • A colleague has done Apex sharing code and it turned out to be reasonably straightforward. Good luck.
    – Keith C
    Commented Aug 4, 2017 at 12:10

1 Answer 1

Reset to default
2

It appears you have a Partner Community, so you should be able to do it. Apex Managed Sharing is only available with Partner and Community Plus licences. @KeithC has pointed you to the right documentation.

I recommend using triggers that write to a custom object. Depending on the volume and immediacy of the sharing need, there are two ways to proceed from there.

  1. Another trigger fires when the the record to be shared is written to the custom object. That calls a queueable that queries the custom object for records that need to be shared. Any records that have failed for some reason or other can be written back with an error message to the original record. On success they can be deleted. If, after a retry, they still can't be shared, an email can be sent to an admin for investigation.

  2. Instead of the trigger on the custom object, a scheduled job can be run at some interval that queries the custom object for records to be shared. Again, any errors are written back to the custom object and on success records are deleted from it. If on a retry after an error, a record still can't be shared, an email is sent to an admin.

These are options that have worked worked well for me in the past.

Improve this answer
2
  • Hmm, never thought of working with a trigger + queueable! I liked the solution.
    – Javier García
    Commented Aug 4, 2017 at 14:06
  • 1
    If you're in a heavy use org, you'll want to check limits before firing the queueable. If you string queueables together, be sure to check limits. If you don't have limits available, you can choose to use a schedulable instead to take care of what might still be in the custom object. Appleman discusses this pattern in ver 3 of his book Advanced Apex.
    – crmprogdev
    Commented Aug 4, 2017 at 14:18

You must log in to answer this question.

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