I'm in the process of updating the FuseIT SFDC Explorer to use the Winter '16 (v35.0) APIs. One of the first things I've encountered are a number of changes with how debug logging works. These are somewhat documented in the Release Notes on Debugging.
In terms of actually integrating with Salesforce at the API level, TraceFlag no longer has a scopeId field to optionally represent the user being debugged. Instead it has a logType and DebugLevelId field. It's the latter that is particularly interesting.
Say you have two developers working in an Org. Ideally they would both be developing in separate orgs and then migrating changes into a common org, so let's say they are testing the integration of their changes.
- Developer A starts the Developer Console.
- A DebugLevel is created for Dev A with the DeveloperName 'SFDC_DevConsole'. Lets call it 7dl70000000000A, or DLA for short.
- A TraceFlag is created for Dev A that references DLA. The TracedEntityId is the Developer A's User Id.
- Developer B starts the Developer Console in the same org in their own session
- You can't have two DebugLevel records with the same DeveloperName, so the Developer Console uses the existing DLA record. (See where I'm going with this?)
- A TraceFlag is created for Dev B that references DLA. The TracedEntityId is Developer B's User Id.
So, what have we got? Both developers will see their logs in the Developer Console. However, they are sharing the same DebugLevel definition by default!
If either developer makes changes to the common SFDC_DevConsole debug levels it will affect the other developers logging for any future logs. If one developer deletes/removes the common DebugLevel it will cascade delete any associated TraceFlags. Hours of fun!
What can you do about this? You can add new DebugLevel records via the developer console. The one you have selected when you press Done will be sent back to the TraceFlag.
