11

Question

Any tips or tricks for providing a good user experience when a time-based workflow field update can lead to an exception?

Detail

For each wrench in the Salesforce toolkit there is often a good choice for error handling. For triggers addError allows you to delegate the error handling to the code making the DML statement, or have it bubble up to the UI. For VF you have pageMessages to let the user. For time based workflows, no ones home, so what to do? What error handling techniques are good for this case?

Concrete Example

In my scenario we have an approval-ish object (meaning it can be active/inactive), and we limit the number of active objects users can own. We use .addError to display an error message to the user if they try and activate the object and their over the limit. Trouble is, we also use time based workflows to activate them on a specific date.

I'm not an expert on time-based workflow error handling (and can't find anything in the docs), but my understanding is someone gets an email (not sure who) if it fails.

In this case, the field update fails, but this leaves the data in an inconsistent state. Does anyone have some examples of what they've done to handle errors with time based workflow?

  • 1
    If you're OK with not performing the update at all - why not add Owner:User.CountOfActiveOnes__c < Owner:User.LimitOfActiveOnes__c to the workflow's formula? (yes, I do realize this syntax looks batsh*t crazy. Must be some recent change to finally mitigate the OwnerId = Lookup(User, Queue)). – eyescream Jan 6 '14 at 22:31
  • To monitor the workflow action:Adminstration setup---monitor--time based workflow. Did u run the workflow in developer console. It is easy to debug through developer console – Sindoora Jan 7 '14 at 8:46
  • Yep, monitoring is sweet. Just trying to see if there were any approaches to error handling in triggers, since .addError doesn't have the usual effect since no one is there to get the error. Only thought I had was email, but am curious to see if the community has any thoughts. – Ralph Callaway Jan 7 '14 at 23:12
2
+50

I'm not sure I'd go so far as to call it "best practice" but what about creating a custom log object and having your trigger create a log record with the error, lookup to offending approval record, etc? Then you could create reports/dashboards off of that object and monitor it as a part of a routine data cleansing process.

  • Interesting but messy. The transaction will fail (that's the whole point, right?), there will be rollback. So how would you save such "side effect"? I think @futures are not queued in such case, ditto with queued outbound emails... I'm not downvoting you, just thinking out loud. But I "don't see it". Savepoints within a trigger? Yuck (if possible at all). In such case I guess I'd ditch time-based w. and go with scheduled batch, would be "cleaner". – eyescream Jan 8 '14 at 23:41
  • Since @Ralph mentioned .addError, I was thinking that the error was being caught within the trigger -- in which case the record could be created within the catch en lieu of the .addError. – Tim Smith Jan 9 '14 at 1:12

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.