+ Start a Discussion
csweetcsweet 

Debug Logs on Web-to-Lead in Sandbox

Hello all,

 

I have an Apex trigger attached to lead creation which currently works as intended in sandbox when I use the "New" button in the Lead area. My system.debug output works correctly when using the System Log pop-up.

 

With that, my next step was to test the Web-to-Lead creation to assure that the trigger was also working there. The leads are being created, however the trigger does not seem to be firing at all and I am getting no response in the Monitoring > Debug Logs area to see what the issues may be. I have used "Add Users To Debug Logs" to assure that I am requesting the logs, which is working when I create a Lead from within the sandbox.

 

Based on what I've seen on our Debug Log in production, I believe I should be seeing Request Type = "Application", Application = "Browser" and Operation = "Async Metadata" (along with a boatload of other API calls).

 

I know that the Web-to-Lead HTML has the option to turn on debug mode, so I did that, but I don't think it's the same debugging I need.

 

Any help is appreciated, thank you.

   

 

Best Answer chosen by Admin (Salesforce Developers) 
werewolfwerewolf
Which user did you turn on the log from?  I would think the W2L leads would be created by the Default Lead Owner, so you should set the log on for that user.

All Answers

werewolfwerewolf
Which user did you turn on the log from?  I would think the W2L leads would be created by the Default Lead Owner, so you should set the log on for that user.
This was selected as the best answer
csweetcsweet

That looks like it did the trick. Oddly enough, in production I'll get the logs regardless of who the Default Lead Owner is. I switched it to myself in sandbox and I'm getting the trigger logs. Thanks.

 

 

Now for debugging...

withoutmewithoutme

did you figure out what this Async Metadata is? 

I'm getting this same "operation" in the debug log when i moved my trigger/class to production. 

csweetcsweet

Basically Async Metadata was the operation that fed me all of the information not only from when the trigger fired, but also any other active assignment rule on Lead creation (which is what I was testing). There's a ton of useful info in there, including any System.debug outputs you have. I'm sure a more experienced person could elaborate a bit more. I'm guessing "async" stands for asynchronous.

 

Happy to say that my modified round robin lead assignment is working great though :D

withoutmewithoutme

what a coincidence? I just pushed my roundrobin lead assignemnt to production!!!!

 

I have deactivated my triggers. But my class associated with that trigger gets executed every once in a while and shows up in the debug log as "Async Metadata"  I dont know if this is cos, the testmethods got triggered and there is no trigger to test it with?

But why did the class trigger up? Is that bcos of moving other components to production - triggers auto testing of all classes ?

Kevin KraverKevin Kraver
Hi, I am having this same problem for an Apex Trigger designed to auto-convert leads into contacts. The trigger is also designed to resolve cases where there already exist duplicate contacts or accounts. Trigger is setup as (before insert, before update)  

Leads created manually from within Salesforce (Lead -> new Lead) trigger correctly, leads are converted, duplicates are resolved correctly. Debug Logs are visible in the developer console.

Leads created through W2L form trigger correctly, leads are converted, however for duplicate cases, the contacts are not coverting correctly. I am getting an error email from the system, but Debug Logs are not visible in the developer console so I am having a very hard time pinpointing where the error is coming from. 

Per the instructions in the thread above, I have made sure that I am the Default Lead Owner for W2L, but this has not made a difference. I know this is an old thread, but hoping someone can provide some new ideas on how to resolve this. 

Thanks!


 
 
Kevin KraverKevin Kraver
Sorry, i misspoke....trigger is on Lead (after update, after insert)  not sure this matters to the problem though.