function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
WhyserWhyser 

Guest User Running Triggers that perform Updates

A follow up to more questions regarding the Guest User.

We have a customer portal that allows customers to manage their licenses via Sites ( an iframe in our product that passes very specific parameters to our Site VisualForce page that allows us to determine the customer we are dealing with ) so that customers can manage their licenses to our product ( adding or renewing ).

When a customer has made a purchase to add/renew, one of the things that happens is that an Opportunity is created from it. This doesn't cause any problems since we can grant permission to Guest Users to create specific objects under the Guest User Profile.

However, in addition to creating an Opportunity, it initiates an Opportunity trigger (BEFORE INSERT) that tries to:

  • Update the End Date (custom field) of an Opportunity, based on the Contract that it is associated to, and recalculate prorated months (custom field) on the Opportunity
  • Update the Contract Months (custom field) of the related Opportunity Line Items.

Understanding that Salesforce is going to soon be enforcing Guest User Record Access to be limited to Create and Read-Only, I am assuming that Salesforce will not allow the Guest User to perform these kinds of updates.

What would be the best practice to allow the Guest User to perform these actions?

The development best practices state:
https://www.learncommunitycloud.com/s/news/guest-user-record-access-development-best-practices-20Y1U000000UkITUA0

which suggests that the update action should be moved into a "without sharing" class.

But considering that this is a trigger, the updates to the fields happen prior to the insertion (is that a problem for the Opportunity since it hasn't been technically inserted yet),

But the trigger does have to query the Opportunity Line Items and perform updates on those, and I suppose that based on best practices, I would now have to move that functionality into a "without sharing" class?