Be There for Your Customers

Learning Objectives

After completing this unit, you’ll be able to:

• Describe Login Access and its benefits.
• List the limitations that apply to Login Access.
• Explain interactive debugging and where you can use it.

Get In There and Help Out

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 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:

1. Ask your customers to navigate to their personal settings.
2. Tell them to click Grant Login Access.
3. Have the customer specify the Access Duration, which should be enough time for you to troubleshoot and resolve the issue.
4. Click Save. 
5. 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 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.
6. 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:

1. Navigate to Subscribers in your License Management App (LMA). The LMA refers to customers as subscribers.
2. Search for a customer’s org by name or by org ID.       
3. 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.
4. On the Org Details page, click Login next to a user's name. You have the same permissions as the user you logged in as.

Secure Access to LoginAs with Multi-Factor Authentication

Multi-factor authentication (MFA) is required when logging into the License Management Org (LMO). MFA is required only for LMO users who require access to the Subscriber Support Console. This requirement provides subscribers an extra layer of security by verifying the identity of the user accessing their org. You also have more control over which users log in to a subscriber org. See Log in to Subscriber Orgs in the Second-Generation Managed Packaging Developer Guide for more details. 

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.

How Login Access Works

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 package’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.

Debug logs contain debugging information that helps you troubleshoot customer issues. To view the debug logs in the subscriber org:

1. From Setup, enter Debug Logs in the Quick Find box.
2. Select Debug Logs.
3. 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 package 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.

Build Your Reputation on Customer Satisfaction

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.

Resources

• Second-Generation Managed Packaging Developer Guide: Troubleshoot Subscriber Issues
• Salesforce Developers Blog Post: Salesforce for VS Code: Apex Replay Debugger and More
• Salesforce Extensions for Visual Studio Code: ISV Customer Debugger