Be There for Your Customers
After completing this unit, you’ll be able to:
- Describe Subscriber Login and its benefits.
- List the limitations that apply to Subscriber Login.
- Explain interactive debugging and where you can use it.
Customer support is part of the software business. It doesn’t matter if you’ve built the best solution the world has ever seen—your customers still need help from time to time.
Sometimes the fix is easy. Customers contact you by email, phone, or Service Cloud, and give you enough information to fix it or help them complete their task.
Other times, the issue is more subtle, and it helps to see exactly what’s going on in a customer’s org. But how?
You can ask your customers for a screenshot or a video. You can even set up a screen-sharing session, if you have the right software and can coordinate your schedules. But these methods require time and effort from your customers, and they don’t let you directly navigate customer orgs to explore the issue.
The Next Best Thing to Being There
It’s much easier if you can log in to the customer’s org, figure out the problem, and potentially fix it directly. And you can! Ask your customers to grant you Login Access. It lets you log in to an org as a given user for a period of time that customers can control. No need to ask your customers for a username and password, which is a big security no-no.
Because you’re logging in as a specific user, granting Login Access is sometimes called LoginAs.
Request Login Access
To request Login Access:
- Ask your customers to navigate to their personal settings.
- Tell them to click Grant Login Access.
- Have the customer specify the Access Duration, which should be enough time for you to troubleshoot and resolve the issue.
- Click Save.
- If your customers don’t see your company name listed, make sure that:
- Their system administrator enables the permissions for non-admins to grant Login Access.
- The customer has a license for your solution’s package.
- If the package is licensed to the entire org, an admin with the Manage Users permission grants you access.
- In the org’s settings, Administrators Can Log in as Any User is disabled.
- Check that you have the Log Into Subscriber Organization permission on your License Management Org (LMO) user account. Your administrator can grant you this permission, either to your user account directly, or via a permission set.
When your customers have successfully granted you Login Access, you’re ready to log in to their orgs:
- Navigate to Subscribers in your License Management App (LMA). The LMA refers to customers as subscribers.
- Search for a customer’s org by name or by org ID.
- Click the desired org record in your search results. The subscriber org record page shows you the name and contact information from the org’s company information page, its org ID, and its instance. The page also contains information about limits, login access, and packages and licensing for the org. The contact information may be a bit different from that in your corresponding LMA Lead, Account, or Contact records.
- Click Log Into Subscriber Console to connect to the org.
If you don’t see the Log Into Subscriber Console button, add that button to the page layout. If you need a refresher on this, read how to customize record details and page layouts in our Lightning Experience Customization module.
Maintain Trust by Limiting Access
As you know, trust is top priority at Salesforce. Getting access to a customer’s org means gaining access to their data, which is a privilege no organization grants lightly. Request login access only for trusted support and engineering personnel who can efficiently and carefully address problems in a customer org. Use the Log Into Subscriber Organization permission to organize your support team, and grant that permission only to those who need it.
When you connect to a subscriber org with Login Access, you get some pretty cool tools unavailable to customers. You can:
- View your managed package code. Whereas this code is hidden to end users.
- Inspect your solution’s debug logs. With these logs and your visible source code, you can construct a picture of what’s happening in the customer org.
- Inspect and debug your managed package code as it runs, using the ISV Customer Debugger.
|What You Can Do||With Login Access||As a Customer|
|Log in to subscriber org||X||X|
|View managed package code||X||
|View managed package debug logs||X||
|View and edit protected data in custom settings||X||
|Start an ISV Customer Debugger session||X||
|Grant OAuth access||
|Use two-factor authentication||X||X|
Debug logs contain debugging information that helps you troubleshoot customer issues. To view the debug logs in the subscriber org:
- From Setup, enter Debug Logs in the Quick Find box.
- Select Debug Logs.
- View the debug logs in the list view.
Logs and source code are great, and they can be all you need to fix up your customers and send them on their way. But if you need to dig deeper, we’ve got you covered.
Find the Needle in Your Call Stack
Let’s face it—sometimes you need to watch what’s happening in your solution to understand a problem. This is what debuggers are for. If you’ve used a debugger to find a bug in your code, you know how handy they are. We’ve made one available for you to use in debugging subscriber orgs.
If you haven’t used a debugger before, you’re in for a treat: You can inspect data right in your program as it runs!
The ISV Customer Debugger is available as part of the Salesforce Extensions for Visual Studio Code integrated development environment (IDE).
This debugger does just about everything you expect a debugger to do.
That said, there are some limitations to the debugger:
- You can open only one debugging session at a time, which means you can only debug one customer at a time. If you need to conduct more than one debugging session simultaneously, contact your partner account manager for options.
- The debugger can connect only to sandbox orgs. In other words, you can’t interactively debug production orgs. If a customer identifies an issue in a production org, create a sandbox org and fill it with data to reproduce the error. A full sandbox offers the closest experience you can get to a production environment.
- You can debug at most two executing threads at a time.
- A debugging session times out after one hour of inactivity.
- A debugging session can last no longer than 4 hours, regardless of activity.
Set Up and Start a Debugging Session
To set up and start a debugging session when you're working with the Visual Studio Code IDE, follow the instructions on the Visual Studio marketplace site. If you’re working with the Eclipse IDE, follow the instructions in the Force.com IDE Developer Guide.
Manage your licenses properly and attend to your customers’ needs, and you can grow your business and affirm your reputation on AppExchange. The less time you spend fighting fires and tracking down bugs, the more time you have to add great new features and work in new directions.