In North52 a trace log (sometimes called trace file) is the output of a Formula execution.  In this series of articles we will breakdown the trace logs providing a clear understanding of:

  • What is inside a trace log
  • Where to find North52 trace logs
  • How to interpret trace logs
  • Common errors to watch out for
  • We will touch on relevant Microsoft platform limitations and rules (depth, timeouts, execution context, etc.)
  • Differences between client side and server tracing

Purpose of Trace Logs

North52 tracing has 2 primary purposes:

  1. Information reporting (What the formula did and why)
  2. Error reporting (What the formula did and what went wrong)

Tracing Levels available in North52

North52 provides different levels of Tracing for customers to use:

Level Purpose
Information This setting will produce a trace log when the formula has finished executing. This will create a North52 Trace record that can examined afterwards.
Information (Show Exception Details) This level of tracing is used when you want to display information from a nested exception*. This will not create a North52 Trace record.
*Note: A nested exception is something that happens further down the execution pipeline. For example a formula updates a contact record setting an age field. On update of that field, a work flow is kicked off to send a happy birthday email. However the contact does not contain an email address and the workflow generates an error. Information (Show Exception Details) will allow that error message to be displayed back to the user. If this is not set, then the end user will see a generic North52 error message.

Information in a Trace Log

The trace log contains as much relevant information as we can add to it. The items found inside a trace log include:

Information about the plugin context

  • Stage (validation, pre-op, post-op etc.)
  • Message (update, create, delete, etc.)
  • Business Unit it is executing in
  • CreatedOn date and time
  • Primary entity it is executing against

Information about the primary entity

  • Any values that have changed in the transaction

Information about the formulas that are executing

  • List of shortcodes
  • Start and stop for each formula executing
  • Formula description (it's business rules)
  • Output of individual function used in the formula

Information about the Formula itself

  • Source properties
  • Description
  • Shortcode
  • Pipeline event
  • Pipeline stage etc

With this information you can determine how the logic in the formula has executed and why it chose the paths it did. In later articles we will examine this data in more detail.  

Note: Each trace log belongs to a specific Formula, but if multiple Formulas are executing then you can see those Formulas and their outputs in each trace log. This is helpful when you are trying to troubleshoot multiple executing Formulas in more complex logic.