Six months as the ad hoc SFDC dev onsite and counting, I've run into the following issue. Before I came along, Salesforce was set up in concert with a devshop who created a trigger that adds sales team members from various lookups. This trigger no longer works properly due to the fact that additional team members have been added and additional roles created that the trigger is unaware of, and therefore defaults to adding the lead into these roles and tasks the lead with tasks they shouldn't own. The trigger itself contains various maps, lists, and loops, which I recognize, but how do I get what each line/loop is doing? Is inserting System.debug(); statements the only way to go, or can I do something with System.asserts as well? The code is 134 lines and so I'm loathe to post it (nothing I see in it that's proprietary, so that's not an issue), but please comment if I should.

  • UPDATE: While the question is still a valid question, the trigger itself was found to be not the issue. We had duplicated a role in the sales team mapping, and when the workflow was triggered, the logic couldn't decide and would default to task the owner.
    – SQLHound
    Commented Nov 26, 2013 at 17:19

2 Answers 2


Honestly, for 134 lines that don't work I'd rather just get the new requirements (you need to implement them anyway) and write the thing anew.

What you could do is simply execute the code on a known record and see what changes that introduces. You could deploy it to a blank org or execute in test context so that you know exactly what data is involved. I'd look for signs of calling any other code in the debug log, also check if any custom settings are used.. really, there are many possibilities, but it shouldn't be a huge workload.


System debug is probably the best way, maybe best rewriting it but then you start going down another road. If the current code is calling other functionality/logic that you dont know about you may end up removing other functionality that may in tern break something else. EG the code updates another field on the record that you dont update in your new code, but what you dont know is that when that field is edited it fires off a different trigger/workflow to do something else.

You must log in to answer this question.

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