Please create a new post in the Discussions section for any questions or comments.
ZTNA introduces in-product feedback to streamline bug reporting and product feedback.
We have streamlined and optimized the feedback collection process with ZTNA. If you wish to send the product & engineering teams feedback or encounter any issue, please use the integrated feedback button in Central, including as much detail as possible to help the engineering team troubleshoot and correct the issue. You can find the blue “Feedback” button in the ZTNA section, enter your feedback, and click send!
We encourage everyone to use this new feedback process as it ensures the correct teams have visibility into issues and feature requests.
We greatly appreciate it when someone takes time out of their day to evaluate our EAP and provide feedback. In the spirit of expediently understanding, triaging, and resolving a discovered bug, we put together a basic guideline for how to submit a bug report. Having the correct data upfront will help fast-path the entire process. It's not a requirement to follow the example listed below but it is strongly encouraged, where possible. If we get as much data as possible upfront it'll save cycles going back and forth to collect more data later. We want to save you time and fix issues as fast as we can. Let's first start with an example of what not do:
Example BAD bug report:
"I restared the appliance and it broke."
We get it, you're busy and may not have enough time to capture the details for what is broken. Unfortunately, in this example, there isn't enough detail to understand what feature is broken, how it is behaving, how you expect it behave, and without supporting data, it's difficult to understand what we need to investigate and how. In brief, we need a lot more data to help you out. As Jerry Maguire said, 'help me, help you!'
Example GOOD bug report template:
- What feature is impacted?
- What is the severity of the issue? (High, medium, low, minimal)
- Summary of the issues:
- Observed behavior (What it did or didn’t do):
- Desired behavior (How is it expected to or should behave):
- How do we reproduce it (Provide instructions to help us reproduce the behavior):
- Other (Any other detail that we need to know about):
- Supporting logs, pcaps, etc.:
Example GOOD bug report:
- Feature and severity: I have a bug with the Xstream SSL policy and I think the severity is minimal.
- Summary: There is a typo in a domain name that is used with policy exclusions.
- Observed behavior: the domain name ended in .cmo instead of .com
- Desired: the correct domain should end with a .com
- Reproduce it: open the managed exclusion list and review the strings of domain names
- Supporting logs: the actual domain was seen in the TLS logs and it had a decrypt action <insert LOG details or how we can retrieve them>
Again, the more data we can get upfront, the faster we can address the issue that you've found. We obviously hope that you don't find defects but we greatly appreciate any reported defects. Thanks for your support and for helping us to improve!
Pinned. Please create a new post in the discussions section if you had a question/comment regarding the KIL
[edited by: FloSupport at 8:12 PM (GMT -8) on 8 Mar 2021]