Category: Salesforce

Step 1: Check logs

	Debug logs	Audit Trails
Records	Records automated actions and results generated by end user or code	Tracks configuration changes by Salesforce user in the Org
Example	Apex trigger actions, workflow, validation rules	Create/updates happened on workflows, validation rule, sharing rules, classes etc

Debug Logs: Will provide you information what actions are getting performed and in which order

Audit Trails: Helpful to find out it some newly made org changes has broken the functionality

Step 2: System Debugs

Debug log recording in Setup is turned on for your User via: Setup > Monitoring > Debug Logs. See here for more information.

I would place temporary debug statements such as

System.Debug('>>>> the value of x is ' + x);

within my code to make sure that the code is executing the way I think its working. Individual SObjects, Maps of SObjects and Lists of SObjects can all be appended and that shows you all populated SObject fields.

The >>>> is a unique string that usually doesn’t appear anywhere else in the log files. This allows me to quickly find my debug output. (Logs are truncated after 2M bytes of output – there are workarounds for this.)

Step 3: Use the Developer Console

The Developer Console is a great tool for debugging. You do the following things (and more) with the developer console

• View Logs – This is another way of viewing debug outputs.
• Execute SOQL –  This can be used to verify that the SOQL in your code is returning the correct information
• Execute Anonymous – Apex code can be run directly from the dev console

Log Lines

Log lines are included in units of code and indicate which code or rules are being executed. Log lines can also be messages written to the debug log. For example:

Log lines are made up of a set of fields, delimited by a pipe (|).

The format is:

· timestamp: Consists of the time when the event occurred and a value between parentheses. The time is in the user’s time zone and in the format HH:mm:ss.SSS. The value in parentheses represents the time elapsed in nanoseconds since the start of the request. The elapsed time value is excluded from logs reviewed in the Developer Console when you use the Execution Log view. However, you can see the elapsed time when you use the Raw Log view. To open the Raw

Log view, from the Developer Console’s Logs tab, right-click the name of a log and select Open Raw Log.

· event identifier: Specifies the event that triggered the debug log entry (such as SAVEPOINT_RESET or VALIDATION_RULE). Also includes any additional information logged with that event, such as the method name or the line and character number where the code was executed.

Events:

· EXECUTION_STARTED

· EXECUTION_FINISHED

· CODE_UNIT_STARTED

· CODE_UNIT_FINISHED

· METHOD_ENTRY

· METHOD_EXIT

· CONSTRUCTOR_ENTRY

· CONSTRUCTOR_EXIT

· SOQL_EXECUTE_BEGIN

· SOQL_EXECUTE_END

· SOSL_EXECUTE_BEGIN

· SOSL_EXECUTE_END

· CALLOUT_REQUEST

· CALLOUT_RESPONSE

· FATAL_ERROR

Step 4: Explain like I’m five

Simplest meaning of it is “Explain a complicated subject in a way five years old can understand.” Try to explain your code stepwise to yourself or someone else(Dry Run). A lot of the time you figure out the problem when you are explaining the code to someone else. (If exceptions are involved, take a look at your code at the line numbers reported and consider what could have generated the exception.)

Step 5: Create a Unit Test

A unit test is a great way to figure out what is going on with a piece of code. It allows you to:

• Execute your code in an environment with no other data
• Create test data that you can use over and over again.
• Use asserts to check your code

e.g. System.assert(contacts.size() > 0);
     System.assertEquals(expectedX, actualX);

Step 6: Take a break

Sometimes taking a break helps to refresh your mind. It allows you to see the problem from a different angle. This has really helped in most of the time. If you don’t think you have enough time to take very short breaks, you’re probably spending a lot of time on unproductive tasks. It’s important to take a step back and ask “Am I doing working in correct direction?”

Step 7: Ask for help

If you have done all the steps above and reached this point then you most likely need help. This is where a colleague or stack exchange come in. When asking a question, clearly state your problem. Provide enough information to make it understandable to others. If you provide a code sample, ensure it is well formatted.