I have a custom object (named Rewards) that 99% of the time is automatically populated by triggers on other objects (conditions that automatically grant said Rewards). But I've also exposed this object to various people and 1% of the time they need to manually create or update these record from the Salesforce UI. I want to send an audit email for this 1% case of manually creating or editing the records from the Salesforce UI. My first attempt was with workflow and it of course alerts on the 99% case too. I want to silence that 99% system-created case.

Any clever ways to differentiate a UI-initiated update from a UI->trigger->2nd object update?

I'm interested in Workflow and Trigger options here. Thanks in advance!

My only thought so far is to switch the alerting mechanism over to a trigger that checks a global variable or list before sending the alert. In the 99% case where my trigger code is making the change it first registers a "don't alert on this change" with that variable or list. When users go through the UI they won't have that and the alert will come through for them.

Attribution to: twamley

Possible Suggestion/Solution #1

What behavior would you expect if somebody decides to use Data Loader to mass edit multiple rewards?

1. Can you build a VF page for new/edited records, then simply send emails from the controller?
2. Can you rewrite all your triggers/automated thingies to use a hidden field (say a "suppress emails" checkbox which would be not shown on any page layout)? Then a before insert, before update trigger on rewards could:
   • examine the values,
   • send emails for the ones that didn't have it set
   • clear them for the ones that had it set (so they won't be abused in subsequent edits by real users)

Attribution to: eyescream

Possible Suggestion/Solution #2

There are a few options depending on how things are set up :

If the conditions which invoke your triggers are invoked by one or even a few users, you can think of a User Level Control Field - ByPassAlerts, which is set only on the (Integration or such) users, and is checked for by the workflow before sending out an alert.

If however, the conditions are based on user interaction, which involves most of your user community, you could have a hidden (Checkbox) field on your Rewards Object - System Update (or similar). Set this when you're updating something via your triggers, and you can then use this field for bypassing sending out the alerts for system changes.

If however it is likely that real users might modify those said records via the UI, then you will need to reset the variable after update has been committed, which you can achieve via a Workflow - to reset the System Updates flag if it is true. (You email alerts workflow should neglect any updates where ISCHANGED(System_Update__c), so that it ignores the setting or the unsetting of this flag.

EDIT :

You can also employ 'negative' logic where you infer who is changing the record based on whether the value of System_Update__c is changing. So have a date field rather than a checkbox. Whenever the system updates a Reward Record, it sets System_Update__c to Datetime.now()

Your alert workflow rule then checks for

NOT(ISCHANGED(System_Update__c))

Attribution to: techtrekker

Possible Suggestion/Solution #3

Record Types? What about having two Record Types, 'System' and 'Manual' for your Rewards object. You can make System the default Record Type used when your code creates the Reward records. And then enable only the 'Manual' record type for the users you've exposed your Rewards object to. Then in your trigger code / workflow you can check the Record Type assigned and emit your email (or Chatter Post maybe to a designated user).

Background: The thing that made me think about this, is about the two roles of users you've expressed and utilising the platform features in this case to design that into your application.

Attribution to: Andrew Fawcett
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/4405