3 tips to help your Esri Tech Support save your day.
When working with software, dealing with bugs and problems is a part of your life. GIS software and Esri’s technology are no exception. There is always a bug somewhere. You might get ArcMap’s infamous error 999999. You might get ArcGIS Pro to crash. You might just end up with a geoprocessing tool not working as planned. When it happens, you will reach out to Esri’s Tech Support.
I have been logging a lot of cases with Esri Canada’s Tech Support in the last decade and learning a lot. Sometimes it was a fantastic experience, sometimes it was a complete nightmare. I have realized that when my cases were not moving along as quickly as I wanted, there was often something I could have done better.
In this article, we’re going to include the recipe to report a problem to tech support. The good news is that it is not really specific to Esri’s Tech Support, so you will get some good transferrable skills. I even expect those tips to be used when my clients communicate bugs about my custom apps.
Tip 1: Provide a good bug description
Any email logging a bug should start with a bug description. The bug description should meet 2 criteria:
- Simple: a good bug description should take 1 or two sentences. All you need is a structure like when I do “X” with the software, “Y” happens. It should be doing “Z” instead.
- Specific: use words that describe the problem accurately. Don’t use the expression “it does not work”. This means nothing. Don’t use the word crash if the software does not crash.
Tech support juggles between multiple cases a day. They can’t read minds, and they need to be able to open your case multiple times and quickly remember your situation. Cases might also get assigned based on your bug description. Help them assign the right person: provide a good bug description.
Tip 2: Provide information about your environment
Whenever you're reporting a bug, you should include information related to the environment in which the bug happens. Always consider including:
- The operating system: are you running Windows 7? Windows 10? A version of macOS? Or is it a version of Linux? This can have an impact.
- The software version: what version of ArcMap, ArcGIS Pro, or ArcGIS Enterprise are you using?
- What web browser are you using: if the bug happens when you’re working in a web app, what browser are you using?
- What’s your deployment pattern if you’re working with ArcGIS Enterprise. Do you have everything on a single machine?
- Where is your data stored? In a file geodatabase? In an enterprise database? In the data store?
Tip 3: Provide steps to reproduce
One of the first things the tech-support analyst is going to be doing is to reproduce your case. If you don’t do that part well, you’re going to waste a lot of time emailing back and forth. Always provide steps by steps instructions. A good description of the steps to reproduce follow the 3 principles.
- Simple: describing steps to reproduce can take time to write, and to read. Keep it simple. That means simple vocabulary, simple sentence structure. It has to be clear and concise.
- Specific: don’t write the steps to reproduce from memory. Do it as you write it. Make sure you’re using the proper name of the button or tool you’re clicking on, if relevant include the screenshots.
- Comprehensive: include the errors messages you’re getting. If you can share logs, share them. If your browser console returns error messages, send them. If you have test data, send it. If you don’t have a small test data set, make one, and send it.
Why do you have to do all of that?
The short answer is because that is the easiest route. You want to increase your chances to get your case solved quickly, and good communication is key. Don’t take shortcuts, here is why:
- If you’re not sending all the information that Tech Support needs, Tech Support will write back to you asking for it. This might take 1, 2, 3 emails when that happens. While you exchange emails, your problem does not get solved.
- Tech Support does not just deal with your case. When the information the support analyst needs is spread across multiple emails, it takes more time and energy from them. In that case, you’re just hurting your chances of having your case solved quickly.
- Tech Support people are humans. As your case does not progress, they will move on to other work and will forget something about your case. The person in charge of your case might move into a new role and your case might get assigned to someone new.
When the situation has reached the third bullet, you're up for a wild ride. If a case is transferred, and everything they need is in one email, this situation would be very simple to handle.
Help them help you.
We all get frustrated when a bug happens. Sometimes, they impede our deadlines, mess up our budget, or prevent us to solve a critical issue. The support analyst is not responsible for that. All they can do is try their hardest to help you. Help them help you by having the right attitude: be kind.
The mechanism to report bugs, coordinate the support between your local distributor and Esri Inc might not be perfect. You cannot change that. You can give the support analyst the information they need and put yourself in their shoes. Help them help you by sending this information as simply, clearly, and as comprehensively as possible. It is a win-win situation.
Putting it all together.
Let’s take a bug I logged in the past to see how it all comes together. Let’s start with the email subject. It all starts there. For this case I will start my email with a meaningful object:
ArcGIS Pro — Bug on the geoprocessing tool: Simplify Line
The person in tech support knows right away what the email is about. They also know the technology impacted. This will help the case be assigned to the relevant person quickly. Now let’s move on with the body of the email.
Bug Description
The geoprocessing tool Simplify Line (in the toolbox Cartography) returns an error when executed on an empty feature class.
Assuming the tool should have the same behavior in ArcMap and ArcGIS Pro, it should create the simplified feature class and then return a warning saying that the feature class is empty.
This bug is particularly painful when executed in batch in Model Builder or in automated processes since it will stop any running process.
Software
ArcGIS Pro 2.0.1.
Environment
Windows 7.
Steps to reproduce
- Create an empty line feature class
2. Call the Simplify Line tool using the new feature class as an input
3. Validate that the output of the geoprocessing is the following;
In ArcMap, the tool would simply return a warning saying that the feature class is empty. (I could also include a screenshot of what I would get in ArcMap)
Conclusion
It is okay to feel frustrated. We’ve all been there. The empowering way out is to think about what you can do to make things better. Everyone will benefit in that case, and you will be a better human being. If that recipe is useful, feel free to clap to support the blog and subscribe for more content.
Credits for images
- Help Icon: https://icon-library.com/icon/help-icon-19.html.html>Help Icon # 362753
- Tool Icon: https://icon-library.com/icon/tools-icon-17.html.html>Tools Icon # 178682
- Computer Icon: https://icon-library.com/icon/free-computer-icon-images-7.html.html>Free Computer Icon Images # 237215
