When adding line items on an opportunity, after you select the product(s), the screen to enter the sales price, quantity and discount are shown. I've also added the list price, which is a read only field.

enter image description here

If the sales price is less than the list price, I'd like the discount to auto-calculate. Is a before trigger on the opportunity product the recommended approach? I don't want the sales reps to have to figure out the correct discount percent when they just want to enter a round number amount for the sales price. Also, in Classic the sales price is pre-populated with the list price amount that can be edited. However, in Lightning the sales price is not pre-populated with the list price. Is there a setting that allows the list price to be pre-populated in the sales price input field similar to Classic as shown in the image?

  • The issue of Sales Price not being populated in Lightning Experience (LEX) is probably best left for another question. For what it's worth, the Sales Price is populated for me when I try this in my own org when using LEX. My org is not overriding the "Add Products" button, so this should be the standard, OOB experience.
    – Derek F
    Commented Jun 27, 2023 at 19:49

1 Answer 1


In general...

  • Use a "Before" trigger when you want to make additional changes to the records the trigger is acting on
  • Use an "After" trigger for everything else
    • when you want to make changes to SObjects that aren't the one that the trigger is on (i.e. if you want to make a change to the Account that an Opportunity is related to, in a trigger on Opportunity)
    • if you need to change records that are not the ones going through the trigger (e.g. you want to make a change to the Account specified in the ParentId field in a trigger on Account)
    • some other scenario I'm probably forgetting

So yes, a trigger set to run before insert (and possibly before update) would be appropriate here.

That said, a simple calculation like this is a perfect candidate for a before-save, record-triggered flow instead. Flows are generally quicker to develop, and don't require unit tests1 to deploy.

Do note that since the page to add OpportunityLineItems to an Opportunity is provided by Salesforce out-of-the-box, you won't be able to modify it (unless you override that button), and the calculated discount will not show up on that page (as it's only calculated after you hit one of the "save" buttons).

1: Not required, but probably still a good idea. Hhaving unit tests, and running them routinely, can help detect issues that other metadata changes can introduce. It can help detect them before your users do, which is preferable to having your users inform you.

  • curiously, SFDC Architects Guide suggests updating related records in an after trigger is an anti-pattern -- but I'm with you in your response.
    – cropredy
    Commented Jun 27, 2023 at 21:42

You must log in to answer this question.

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