3

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.

Improve this question
  • I'm attempting eyescream's custom VF page and controller route. The trigger conversation spurred me to this pro-con question. – twamley Nov 14 '12 at 19:48
  • Just added another thought, but yes, I'm still in favour of encapsulating this requirement as something tangible and visible to the users / system admins rather than internal gymnastics. So given eyescreams answer, I like option 1 aswell. – Andrew Fawcett Nov 14 '12 at 22:15
  • I have a slightly different POV, which I've added as an answer to your other question. Choosing to go custom comes with its own suite of costs. – techtrekker Nov 14 '12 at 22:55
2

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)
Improve this answer
  • Not expecting Data Loader use here but it is a fair concern. I could live with a flood of emails or silence in that case. Option #1 is interesting--I actually haven't spent much time with custom VF pages but I think I read that I can configure my VF page to replace the standard page. That's a solid idea. Option #2 is similar to my idea just using a checkbox instead of an in-memory list. Clearing it to prep for subsequent use is a good idea. – twamley Nov 14 '12 at 18:11
  • Yes, this is one of those, not so much technical "can I do it" questions, more like "should I do it this way?" architecture wise. Spookly another user was asking the same question recently here, salesforce.stackexchange.com/questions/4271/…. Eyescream's answers fits with my answer there and my general view to approaching these type of requirements. +1. – Andrew Fawcett Nov 14 '12 at 18:23
  • I'd go with Option 2. That way data loader "spam" (API calls in general, if you'll ever have to integrate rewards with some financial system for example) will have same level of control whether they set the checkbox or not. Un-setting in "before" trigger gives you save to db for free - also good, no reevaluating workflows... Override of New/Edit pages is possible but is it worth losing the benefits of standard page layouts? Plus if you apply &nooverride=1 to the request you're back at the original page anyway. – eyescream Nov 14 '12 at 19:26
  • I'm going to try the controller route. If it works you get the checkmark for a clever alternative. – twamley Nov 14 '12 at 19:44
  • Option 1 offers purity at a cost (I got it working this way). At first I despaired over losing page layouts but fieldsets came to the rescue and controller extensions lessened the blow. Still, that's an awful lot of work compared to Option 2. Inspiration here and here and here. I'm glad none of my users know about &nooverride=1 :) – twamley Nov 14 '12 at 22:43
2

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.

Improve this answer
  • Clever. I'd also have to switch the record type from System to Manual when the user edited the record directly. – twamley Nov 14 '12 at 22:28
  • Also, isn't this just a variant of a Control Field, except that in this case it is piggybacking off a system feature. – techtrekker Nov 14 '12 at 23:07
  • Yep indeed sure is, good observation, but powered by its own UI to manage and configure it, that just happens to match the role specific element of the use case! I love it when a plan comes together on this platform! :) – Andrew Fawcett Nov 14 '12 at 23:12
1

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))
Improve this answer
  • My first attempt with the workflow included the user filter. I thought that was going to be good enough, but it's the same set of people that update the records directly and indirectly. Thinking through System_Update__c... worried about subsequent updates to an initially system generated record. – twamley Nov 14 '12 at 18:07
  • My answer addresses that concern in that the 'flag' will be reset via workflow so that subsequent user updates are captured. – techtrekker Nov 14 '12 at 18:36
  • Just added an Edit which could make it simpler and perhaps more elegant. – techtrekker Nov 14 '12 at 18:56
  • I see that it works and thanks for answering. I'm just on the fence about adding control fields--more on that over here. – twamley Nov 14 '12 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.