Can you capture and store stack trace information in a managed package? This page says that the idea was delivered, but that's not what I'm seeing.

The same code stores this stack trace in the unmanaged version:

 Stack Trace:
    Class.PMT_PaymentCreator.<init>: line 107, column 1
    Class.PMT_Payment_TDTM.run: line 48, column 1
    Class.TDTM_TriggerHandler.runClass: line 118, column 1
    Class.TDTM_TriggerHandler.run: line 68, column 1
    Trigger.TDTM_Opportunity: line 34, column 1

And this one in the managed one:

 Stack Trace:

I'm using the getStackTraceString method from the Exception class.

  • It takes a support request to get detailed logging information turned on for a managed package. This is pure speculation, but perhaps this feature also requires enabling by Salesforce support?
    – Keith C
    Commented Apr 3, 2014 at 22:13

2 Answers 2


You need to be an ISV and login to the customers org using Subscriber support to see any logging from the managed package, including the stack trace.

See comments on Capturing process information with Apex

  • Still testing the issue. A deeper rabbit hole that you'd think. I'll mark your answer as correct as soon as I verify it. We are definitely an ISV (Salesforce.com Foundation), but for now I'm just testing a beta of the new version of our package (the Nonprofit Starter Pack) in a dev org. Got access to the list of Subscribers in the LMA and found the org where I installed the beta. However the package is not listed as one of those belonging to the Foundation...Maybe it's not signed because it's a beta?
    – ceiroa
    Commented Apr 4, 2014 at 19:02
  • This does not work in this case, as we are still working with the beta version, which is not identified as being owned by us. Not sure if it will work when we have a production release...
    – ceiroa
    Commented Apr 7, 2014 at 18:06
  • I'd previously raised the idea Expose logging from a Beta managed package in the deployed org around this. In @ca_peterson's answer he reports that beta packages work with the subscribers tab, but I've never had the chance to try it. Commented Apr 7, 2014 at 19:25
  • I just commented below. Subscribers tab did not work for me on beta package...
    – ceiroa
    Commented Apr 7, 2014 at 20:51
  • We have the error stack traces stored into a custom object, but even using the subscribers tab log in doesn't unmask the stacktrace; just says (namespace). So it seems the masking occurs before even saving it. So this method won't get you historical stacktraces.
    – Aequitas
    Commented Aug 8, 2018 at 6:47

In addition to the ISV subscribers console method posted by Daniel backline support is technically able to "unmask debug logs" for a managed namespace temporarily which will expose this info. You'll need consent from the package author (if it's not you) to make this happen.

  • This is good to know. This would be a partial solution to Ideas: Expose logging from a Beta managed package in the deployed org Commented Apr 4, 2014 at 1:33
  • The subscribers tab worked on beta packages last I checked. By far the best solution to that idea imo Commented Apr 4, 2014 at 1:47
  • Ah, OK. Thinks may have moved on in the 2 years since that Idea was raised. Commented Apr 4, 2014 at 1:51
  • 1
    Any idea if this works for error information already stored? We have implemented error handling in our package that will store error information in the database. I'd be great if the "masking" of stack traces happened at runtime. That is, that the stack trace was stored regardless, but that it's shown only if the unmasking of debug logs is enabled.
    – ceiroa
    Commented Apr 4, 2014 at 19:29
  • 1
    The problem is that we tried to be smart. We set a savepoint, catch the exception, do the rollback, and log the exception. This works great in unmanaged code but now we are stack without stack trace in the database or in emails.
    – ceiroa
    Commented Apr 4, 2014 at 20:05

You must log in to answer this question.

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