How to work with Fortinet Support

Purpose of this document

Fortinet makes many products, from hardware-based firewalls to software that helps plan your wireless network layouts. As much as we may wish otherwise, no product is perfect. Eventually, you may need to make use of one or more of the available support mediums for your Fortinet product.

To help users in a variety of different circumstances, several methods of support are available. Each method accommodates different types of questions, issues, communication preferences, and levels of urgency. This document will help you determine which support is right for you.

This document describes:

  • What kind of support is available
  • What to expect from support
  • How to make your time with Fortinet Support more efficient and effective


This section will cover the different mediums that Fortinet documentation can be represented in.

Online help

The most readily available source of documentation is the online help. On any page in the FortiOS Firmware interface, there is a Help button (“?” inside a circle) in the upper-right that can be selected to get context relevant information.

Cookbook site

The Fortinet Cookbook site is available at

The Cookbook site focuses on specific tasks. If you have an idea of what you want to do, but don’t know the mechanics of it, the Cookbook is a great place to look. This site presents information in an approachable manner, with diagrams and screenshots to guide you. With dozens of authors and new content added every week, this site is a go-to spot for:

  • Cookbook Recipes: Step-by-step instructions for completing specific configuration tasks. These recipes are available in text and often in video format.
  • SysAdmin Notes: In-depth articles on general topics that go into granular detail. These documents provide useful information non-specific to a particular firmware version.

The Cookbook is presented in a blog format which has the advantage of being flexible and easily searchable.

Fortinet YouTube channel

The Fortinet YouTube channel is available at

You can find instructional, informative, and even entertaining videos on our channel. Check out our tutorials and more:

FortiGate Cookbook Tutorials


Step-by-step how to video tutorials, demos, and feature overviews.

 Fortinet Stories


Meet Fiona and Nathan, and learn how to set up your network with Fortinet products.

Fortinet Video Library

While the YouTube Channel hosts all Fortinet videos, you can also go to the Fortinet Video Library to directly access our how-to video tutorials.

This website is geared towards users who learn more effectively by listening to the subject matter and watching someone go through the process of performing a specific task.

The Fortinet Video site is available at

Knowledge Baseknowledgebaselogo

This website is for searching and obtaining detailed information. It is the central repository for technical notes and tips, created by the Technical Support Teams.

The Fortinet Knowledge Base is available at

Fortinet Forumsfortinetforum

The discussion forums are here for you to pose questions and share technical information with Fortinet users around the globe. If you are experiencing difficulties, chances are someone else may have already experienced similar issues and asked about it in the forums.

The Fortinet Forums are available at

Documentation sitefortinetwebsite

This site provides access to Fortinet product documentation, including:
    •    Administration handbooks and guides
    •    Reference manuals
    •    Release notes
    •    Hardware manuals
    •    Quick start guides

This site focuses on documentation that is thorough and comprehensive—information that can expand your existing knowledge of the subject matter.

The documentation site is available at


We rely on your feedback to improve our documentation, and encourage your participation. If you are not sure who to contact about a document or support method, please email us at

Things to remember when giving feedback regarding documentation:

  • Be specific about which documentation you are referring to, the location within that document, and what it is that needs improving.
  • If you have the correct or improved information, specify what it is.
  • If you don’t have the correct information, specify why it’s wrong.
  • If it needs to be expanded, specify in which direction.
  • If it is difficult to understand, specify where the confusion occurred.

Feedback about documentation that does not need improvement is also useful. It helps define a good model to be used in other documentation and allows the documentation team to know what works well.

Support Portal

The Support Portal is the primary point of contact for initiating communications with support services. 

The Support Portal provides a range of options including:

  • Phone contact information for TAC
  • Links to web chat
  • Firmware downloads
  • Viewing customer support bulletins
  • FortiGuard information
  • Accessing asset management
  • Lifecycle management information

The Support Portal is available at, and for FortiPartners at

Firmware/Software downloads

Fortinet device operating systems, commonly referred to as firmware, are located on the Fortinet Customer Service and Support site. Once you have logged into the site, the Software Download Center can be found at

To find the firmware for your product, select the product from the dropdown menu and use the Download tab. From here you can work your way through the folder tree until you find the version and model that you need.

If you are looking for assistance in determining which version of firmware to upgrade to, you can check to see if there is a supported upgrade path document for your product on the documentation site, at

Customer Service

Customer Service is a group within Fortinet Support that specializes in the non-technical areas where a customer may need assistance. This could include issues or questions relating to:

  • Service entitlement
  • Contracts registration or transfer
  • Product registration or transfer
  • Customer accounts
  • Service extensions
  • Fortinet support portal
  • Premium RMA replacement

You can find the phone number for your country by going to Once support has been contacted open up a support ticket. No contract is needed for Customer support tickets. The menu path to create a ticket is Assistance > Create a ticket > Customer Service > Submit ticket.

If you purchased your Fortinet product through a reseller, you should contact the reseller first before calling Fortinet Customer Support.


The WebChat medium is just what you would expect; real-time texting with a Fortinet support person. This medium is perfect for those with short questions looking for definitive answers.

There are two types of web chats that you can engage in:

  1. Customer Service web chats
  2. Technical Support web chats

Customer Service web chats

These web chats are intended as support for administrative issues with Fortinet products.

Examples could be:

  • You need help with registering your products or service contracts on the Support portal.
  • You have a question about the service coverage for one of your products.

The Customer Service web chats are available at:

Technical Support web chats

These are intended, as the name implies, for technical issues where knowledge of the devices and firmware is paramount.

Examples could be:

  • You know what it is that you want to research on one of the documentation sites but don’t know what terminology you should use.
  • You want to know which documentation will give you information on a topic.
  • You want to know which product will perform a specific function.
  • You have basic questions about the implications of using a particular setting in the configuration.

Some of the limitations of technical support web chats are:

  • No remote sessions – Technicians on web chat duty will not be able to setup a remote access session to look at your device.
  • Only new issues – Web chat technicians do not work on existing tickets. If you already have a ticket regarding your issue, work with your assigned technician so that multiple resources are not wasted in redundant efforts to solve an issue.
  • Currently, North American web chats focus on FortiOS/FortiGate, but the support centers handling web chats in other areas will accept chats on all products.

WebChat is available from the Fortinet Support Portal at – Assistance > Technical Web Chat.

Technical Web Chat has the following requirements:

  • Current Fortinet credentials to access the Fortinet Support Portal
  • Serial number for the device being discussed
  • Current support contract for the device being discussed

Technical Assistance Center (TAC)

The Technical Assistance Center is what most people think of when they envision support for a technical device; lots of people using phones and computers to answer questions as they call into a 1-800 number. Fortinet does have a slightly different model than many other companies. 

To get the number for calling TAC, click here.

Before you contact the TAC

As talented and knowledgeable as the TAC technicians are, the troubleshooting process can occasionally be a time-consuming process where eliminating possible causes is as important as recognizing symptoms. In order to limit the amount of time spent with a technician, and to make that time as efficient and effective as possible, you should gather some information before you call. This helps you avoid searching for needed information while on the phone, and gets some of the basics out of the way as quickly as possible. Some of this useful information is described below.

Know the full firmware version number

When filling out the information for the ticket, you will be asked which firmware version you are using. While it may seem sufficient to say 5.0 or 5.2, it is important to include the 3rd number if there is one, for example, 5.2.3. Knowing the patch level of the firmware can assist technicians in narrowing down an issue.

Serial number

Another thing that technicians will request is the serial number of the device that you need support for. It usually speeds things along if you don’t have to go searching for this information, so it’s best to collect it in advance, especially if you have to go crawling around the racks of a server room to find it.

Check your organization’s security policies

While it will not assist in fixing an issue, it is important to be aware of the limitations surrounding how much access to security devices you can allow someone who is not part of your organization.

Back up your configuration

There are two important reasons that you will want to create a backup of your configuration:

  1. As part of the troubleshooting process, you will likely be making changes to the configuration but you will not want to lose any of the existing information.
  2. The technician may ask for a copy of your configuration. The most concise method of getting the information about your device’s existing setup to the TAC is to send the configuration file. This is a basic text file so it should easily attach to an e-mail.

Recent Changes

If the issue is software-based, the most likely cause is something that has changed. One of the best troubleshooting strategies when something stops functioning properly is to determine what has recently changed. Try to compile a list in advance of all the things that have recently changed, not just on the device but in the entire network environment.

Troubleshooting already done

In order to save time and not re-cover old ground, keep track of any troubleshooting steps that you have already taken and the results that they produced.

Product Life Cycle

Another thing to do in advance is to make sure that the device and/or the firmware are still supported. If the firmware has gone out of support, one of the first things that a technician will likely do is ask you to bring the firmware up to date, so it becomes a supported product. In fact, the act of upgrading may fix the problem.

To see if the product you are working on is still supported, check the Product Life Cycle document at

Understanding tickets

Once you have connected with TAC and created a ticket, it helps to understand a little of what’s going on in the background so that your expectations are in line with reality.

Service levels

The two basic service levels are:

  • 8 x 5: This support subscription is defined as from 8 a.m. to 5 p.m., according to the local time of the customer, Monday through Friday.
  • 24 x 7: This support subscription is just what it sounds like; service 24 hours a day, 7 days a week.

Priority levels

Support tickets are assigned priority values 1 to 4, with 1 having the highest priority. Each priority level will have its own associated Service Level Agreement (SLA). While everyone feels that, from their perspective, their issue is the most important and most urgent, this does not help the TAC center prioritize the large number of tickets they receive. Just like in a hospital, there has to be an objective method to serve as the basis for setting priorities.

These priorities, and a brief guideline as to their criteria, are described below. They are not absolute definitions. The system is flexible enough to accommodate changing a priority if it is warranted.

Priority Level 1

The Priority Level 1 designation is intended for issues involving a total loss or continuous instability of mission-critical functionality in a live or production environment.

Priority Level 1 issues might include:

  • A loss of connectivity where a large part of your network is affected.
  • You are losing money every minute the functionality is being affected.
  • Something critical to business that becomes impossible because of the issue.
  • You are going to fail your SLAs because of the issue.
  • There is a security flaw impacting a vital component of your organization.

In these cases, both the customer and Fortinet should be prepared to commit dedicated technical resources around the clock, through telephone and remote sessions, toward arriving at a solution.


Initial response: The initial response to the customer for a Priority 1 ticket should take place within one hour of it being designated as a Priority 1 ticket.

Updates: The customer should be given a status update at a minimum rate of every six hours until the priority changes.

Sometimes a complete solution for such critical issues is not immediately possible, but a workaround can sometimes mitigate the threat until a more permanent solution can be achieved.

A workaround could be:

  • Reverting configuration changes
  • A firmware upgrade or downgrade
  • Replacement of the hardware
  • A change to the configuration

In cases where a workaround has been found, with the agreement of both parties, the priority of the issue can be reclassified.

Priority Level 2

The Priority Level 2 designation is for issues that cause significant impact to mission-critical functionality in a live or production environment.

Priority Level 2 issues might include:

  • Serious loss or frequent instabilities of mission-critical functionality impacting active user sessions.
  • Loss of redundancy of a critical component impacting live business services. 

The Customer and Fortinet commit to dedicated technical resources 8 hours a day, 7 days a week for Priority 2 tickets. If a workaround is accepted by the customer, the priority of the issue can be reclassified.


Initial response: The initial response to the customer for a Priority 2 ticket should be within one hour of it being designated a Priority 2 ticket.

Updates: The customer should be given a status update at least once a day until the priority changes.

Priority Level 3

Any technical ticket created for an issue in the Customer network that has minimal impact to business operations is designated as Priority Level 3. One example is occasional or intermittent instabilities of core functions. 
A Priority Level 3 ticket may also cover the root cause analysis for a Priority 1 or Priority 2 ticket for which a workaround has been accepted. 
Fortinet and the customer will assign resources eight hours per business day until a resolution or workaround has been provided. 


Initial response: The initial response to the customer for a Priority 3 ticket should be within the next business day of it being designated a Priority 3 ticket.

Updates: The customer should be given a status update at a minimum rate of every three business days until the priority changes.

Priority Level 4

A Priority Level 4 designation is assigned to any technical ticket created for additional information, including basic configuration assistance, and errors in documentation or minor defects which do not impact business services. 
Fortinet and the customer will assign resources eight hours per business day until a resolution or workaround has been achieved. 


Initial response: The initial response to the customer for a Priority 4 ticket should be within the next two business days of it being designated a Priority 4 ticket.

Updates: The customer should be given a status update at least once a week until the priority changes.

Changing priority

If the circumstances surrounding a ticket changes, it may be necessary to change the priority of the ticket.
Changes that would warrant increasing the priority could include:

  • Reoccurrence of the issue
  • Spreading of the issue
  • Increased impact on the business
  • Discovery of new information that means the impact is greater than originally perceived

Changes that would warrant decreasing the priority could include:

  • A workaround has been implemented
  • The solutions will be provided in an upcoming release
  • The impact is not as serious as originally perceived

To make arrangements to change the priority of a ticket, contact the TAC. The status of Priority 3 and 4 tickets can be changed either by changing the status on the ticket or by phoning the TAC. Priority 1 and Priority 2 tickets require a phone call to change the priority.


Normally, a single technician is assigned to be in charge of each trouble ticket. They will use other peers as resources but they are the point of contact for the ticket. If it turns out that the person assigned to a ticket does not have the experience, or does not have access to the resources required to provide a solution to the issue, an escalation to another (or a more senior) technician can be requested.

Before considering an escalation, you should ensure that you have all the prerequisite items in place to support your request and to enable rapid ticket resolution. Typical questions to consider are:

  • Have you verified that all relevant information has been provided in the ticket and communicated to Fortinet Support?
  • Have you clearly documented in the ticket the increased business impact or extended deadlines caused by the incident?
  • Have you informed your management of the situation and assured their availability to engage if necessary?
  • Have you designated the appropriate level and availability of technical resources within your organization that can work with technical support? This is key, as those resources will be required immediately for Priority 1 incidents.
  • Once the escalation conditions have been met and checklist items validated, you should telephone the Technical Support Center, ensuring that you have the relevant ticket number in hand. The Customer Service representative will connect you with the on-call Duty Manager.

A ticket escalation will bring the ticket to the attention of support management and ensure focus on the ticket. However, this does not necessarily mean the resolution time will be accelerated or that the priority will automatically change.

If required, a technical plan of action will be developed in cooperation with the stakeholders to map out a strategy for the resolution of the technical issue. An assigned Manager can be the point of contact for providing ticket progress updates to the people involved, including your account team and upper management. The escalation will be considered resolved when the following conditions have been met:

  • Agreed objectives have been accomplished
  • A monitoring phase has passed without incident
  • A workaround has been implemented and a final solution accepted
  • It is agreed that the ticket has been resolved

Working with your technician

Once a ticket has been created:

  • You will receive a Ticket Number.
  • The incident will be assigned to a Support Engineer in accordance with the ticket priority.
  • You can expect to receive an Initial Response, either by telephone or email.
  • Each time communication about the ticket occurs, or new information is added to the ticket, the information will be updated in the ticket log. In all but strictly internal communications regarding the issue, you will be sent a notification. You have the ability at any time to log in and check the status of that ticket.

The Technical Support Engineer will do whatever is necessary to provide a solution. If that is not immediately possible, a workaround to reduce the business impact will be arranged. However, troubleshooting is a little different than the customer simply stating what they want and the vendor delivering the solution. In many cases, troubleshooting is an ongoing collaboration between the customer and the technician, working together towards a common goal. The technician brings experience and knowledge of the product and the customer brings the knowledge of the environment and context as well as being physically at the location of the issue.

Maintain communication

Resolving a ticket requires that the customer and technician maintain good lines of communication while working together towards a solution. You cannot submit a ticket and expect the problem to be solved without you. At times, you may be asked for information or to perform a task, the results of which will contribute to the solution.

Fortinet realizes that things get busy. To help prevent requests from falling through the cracks there are procedures followed by the technicians and features built into the ticketing software that a) prompt for responses so that the tickets are not forgotten and b) make sure that “dead” tickets are not clogging up the queue. 

There can be variations that depend on the SLA level but generally speaking, if a technician is waiting to hear back from a customer and hasn’t heard from them in 2 days, the technician will try to contact the customer either by phone or by email to check the status of the issue. This attempted contact will reset the 2 day countdown back to 0.

Sometimes due to circumstances, customers forget or don’t get a chance to get back to the technician with the needed information. These communications are intended as a prompt so that tickets do not languish in the queue.

The technician will try 2 times to get a hold of the customer, at least one of the attempts being a phone call,  mentioning in the second contact attempt that the third unsuccessful attempt at contact will trigger the closing of the ticket. This closure will usually take place 24 after the latest contact attempt. Of course, if any of these contact attempts are successful and the customer wants work on the ticket to continue, the process gets reset.

Technicians are human too, so there are backup for them as well. There is a feature within the ticketing system that will send automated prompts for updates. The system will send weekly reminder emails when the status of the ticket indicates an action is pending by the customer and there has been no activity on the ticket.

If there has been no response from the customer for fifteen days, the ticket status will change to “Pending Close Confirmation”. After this status change, a final email requesting feedback will be sent.

The reason for closing the tickets after an appropriate length of time without contact is that occasionally the issue that prompted the opening of the ticket gets solved or becomes irrelevant. IT people are busy so sometimes they don’t get back to the technician to close the ticket because they have already moved on to the next thing that they have to get done.

The world tends not to work neatly around policy schedules so allowances sometimes need to be made. If you, or the information, will be unavailable for a long period of time, you and the technician can put the ticket on hold until it is time to resume work.

Supply configuration file

At times, the configuration will need to be reviewed in detail. Because the settings in a number of different places can affect a single function, it is necessary to see the whole configuration. While screenshots from the GUI may seem more intuitive to look at, technicians can more readily understand the content of the text-based configuration file. It is also simpler for you to send one configuration file rather than numerous screenshots.

Sending a configuration file is straightforward: back up the configuration file by your preferred method and send a copy of the file. If you are security-conscious, you can encrypt the file with a password and send the password in a separate communication.

Remote access

In some cases, a technician may ask for permission to access your device. It is imperative that your decision is informed by your organization’s security policies and the urgency of the situation.

There are two basic methods of access for the technician:

Method 1 – Create an account

It is a fairly straightforward procedure to create an administrative account (not a user account) so that a technician can quickly see your configuration, look at the monitoring features, and run some diagnostics.

Often when setting this up, some people configure it so that it is a read-only account. It is done this way so that no changes can accidentally be made that would impact your network. The drawback is that a number of diagnostic commands are not available to a read-only account.

This method is not the most commonly used for a few reasons:

  • It is quite often against the organization’s security policy.
  • The access to your devices is effectively unsupervised.
  • The technician may not be able to ask questions about the settings.
  • The customer does not get to see what is going on and therefore doesn’t learn anything about the administration of their device.
Method 2 – Share a computer accessing the device

There are a number of software applications that allow two computers to share access over the Internet. The one that TAC uses predominately is a Citrix product that gives the customer the choice of whether to give the technician control or limit them to only seeing what the customers see.

This is actually the preferred method of access, because:

  • No additional potential security holes are opened.
  • The access is supervised by the customer.
  • The technician can ask questions about settings that are discovered in real time.
  • With the customer’s permission, changes can be made under supervision and the results can be checked, and if the results are inconclusive the changes are reverted.
  • The customer has the chance to learn about the operation, administration, and troubleshooting of their device by following along with a trained technician.

Configuration changes

During the course of troubleshooting, it is always preferable to come across a setting that is obviously wrong and causing the symptoms, but often a small amount of experimentation is required to pinpoint the root cause of the problem. This may involve changing a setting to see if it fixes the problem or eliminates a source of the problem. For this reason, it is best that the customer representative working with the technician has the authority to make changes in the course of troubleshooting.


Replicating the symptoms of an issue is very important in the troubleshooting process. The two primary reasons are:

  1. The problem can only be troubleshot while it is in effect.
  2. The best way to test whether or not a solution is effective is to try a known method of triggering the issue and see if it still causes the issue.

This is why it makes sense to contact TAC if you are actively experiencing symptoms of the issue. Trying to do a root cause analysis on something that has only happened once is very difficult. An intermittent symptom is at least possible to troubleshoot if it occurs while the troubleshooting takes place.


Sometimes (though it is never fun to admit) the source of the problem is a defect in the code, popularly known as a “bug”. This means that the optimal solution is to find a workaround until the code can be changed.

If the bug is already known, the technician should be able to give the customer a reference number and perhaps, if the development team has found a proven solution, a release number for a firmware version in which the code is expected to be fixed.

If the symptoms for a ticket have been isolated to a previously unknown defect of some kind, the technician will open up a bug report. A Bug ID reference number will be assigned and you will be informed of the number through the ticket. Once a bug is resolved, the fix is typically incorporated into the next firmware release.

Ticket resolution

There are a few possible criteria for what is considered resolved or closed:

  1. During the course of a call, a solution is found and, upon agreement with the customer, the ticket is considered successfully resolved and is closed.
  2. After the ticket has been opened, the customer discovers a solution on their own, and it is communicated to the TAC that no further assistance is required.
  3. The customer fails to maintain an open line of communication with the technician.

After three attempts to contact the customer, over a period three times the minimum status update period of their priority level, and there is no answer and no response, the technician will close the ticket. This does not apply if prior arrangements have been made.

The ticket resolution process requires constant communication and collaboration.
If no response is received for another five days, the ticket will be automatically closed. If feedback is not possible within the notification period, you may contact the TAC engineer to inform them when you are able to provide an update.

This means that the technician will periodically ask for assistance from the customer to provide knowledge that the technician doesn’t have, or to perform actions that the technician cannot in order to progress towards a solution.

Ticket closure survey

Upon closure of a support ticket, users may be asked to fill out a survey where you are asked to rate such elements as:

  • Ease of doing business
  • Overall satisfaction

The part that can potentially have the most impact is the free-form feedback. This is where you can be specific about your thoughts, and if you have a lot to say on the subject you can even request to be contacted directly by a technical support representative. If the service was good, this is the place to explain what was good and why!

Critical feedback is equally important, to explain not only what can be improved, but how it can be improved. All of this feedback is collected, kept, and analyzed for trends. If a point comes up repeatedly and ideas are consistently presented for improvements, it is likely that greater effort and resources will be spent in developing a solution to the issue.

Professional Services

The scope of the Professional Services team starts where the TAC ends. Where the TAC is intended to assist customers with issues in the customer’s work environment, Professional Services personnel are there to assist customers in setting up new configurations and new environments.

To put this in real-world terms, if while making some minor setting changes to a VPN tunnel’s configuration that the VPN tunnel stopped working, then a customer should contact TAC. However, if the customer plans to set up a mesh topology of VPN tunnels between the offices of their organization, and requires a professional to plan out the configuration, they should contact Professional Services. 

Engaging Professional Services

Engaging Professional Services is a little more complicated than calling them up and stating what you want and getting started right away in the same way that you can with TAC and troubleshooting tickets. A lot of this has to do with the difference in the types of work or projects that are being requested. Generally, when working with Professional Services, you have a working network that you want to adapt; usually, the intent is to expand its functionality or make it more secure. This has the potential to impact its performance for a time, so a bit more planning and preparation is required to make sure that the impact is minimized. This is similar to doing renovations on a house—you wouldn’t want to knock down a wall and then pause to think, “Okay, how are we going to do this?”

Because a Professional Services project can go in many potential directions, it is important to concentrate on the process leading up to the start of the project:

  1. Develop a clear vision of the project’s objective.
  2. In North America, fill in the Pre-Engagement Form (PEF) document and return it to Professional Services in an email to You can obtain the form by contacting Professional Services and asking for the form, or by downloading it here. In other areas, the process is to talk first to your Fortinet Partner who will arrange things on your behalf through Fortinet.
  3. Once the PEF is received by Professional Services it is directed to the Bid Response Desk (BRD). The BRD contacts the customer to define the scope of the project. Each and every project and customer is different, so this call is to refine the project’s needs and to assess any accommodations that need to be made, such that all of the customer’s requirements are addressed. Determining the scope of the project at the outset is a very important step. It serves as a checklist to make sure everything gets done, as well as determining the project limits so that it doesn’t grow beyond intentions.
  4. Based on the results of the discussions, a customized quote for service will be generated along with either a Task List or a Statement of Work (SOW). Both the Task List and the SOW provide the engineer and the customer with the technical details that define the project.
  5. The customer can take the quote and submit it to the customer’s partner or re-seller for purchase, and a PO will be generated for the service.
  6. Once Professional Services receives the PO and, if the service requires it, the signed SOW, then the Delivery Team takes over to make the necessary arrangements that determine the schedule and the delivery of the service.

Statement of Work

A Statement of Work is more significant than just a quote for services. It is a contractual agreement between the customer and Fortinet. It commits Fortinet to achieving specific milestones within the project. Fortinet is then obligated to deliver on those milestones to the customer.

 The overlap between support services

There is always going to be a little overlap between the types of support available to you. How do you know if you should look up something on your own or log into the web chat? Is the question something that requires you to log into the web chat or should you open up a ticket with TAC? You’re looking for assistance on how to make a change to your environment; should you be talking to TAC or to Professional Services?

These are all going to be judgment calls, but quite often time is the best frame of reference for your decision. If it’s going to take longer to go through the proper channels with the proper support mechanism than it’s going to take to accomplish the objective, then it should be okay to use a different method.

  • If you’re not under a hard timeline to research a topic but you don’t want to spend more time looking for the relevant information than you intend, to research it, you could log into the web chat and ask where the information can be found.
  • If your issue is technically a troubleshooting issue and should go to TAC, but you’re certain that all you need is a little guidance to put you on the right track, log into the web chat. If the technician recognizes the issue right away, they may be able to write up a quick solution.
  • If you are setting up something new in your FortiGate environment, which is theoretically within the scope of Professional Services, but you just need someone to guide you through the first iteration so you know what to do for the remainder, it may be okay to open up a ticket through TAC (depending on the complexity).

In potential overlap situations, there are a few things to remember:

  1. Resolving an issue can often take more time and effort than you initially thought, and you might be unsure as to which support service is best for your situation. Let the support technician help you decide whether your issue is for TAC or for Professional Services. The support technician knows best.
  2. You should use the proper support medium when reporting an issue. For example, the web chat might be time-consuming and inadequate when the context of your scenario requires a thousand word description—this is better suited for a phone call.
  3. Support technicians want to help you and will try their best to assist you through the support medium of your choosing. You may wish to take advantage of the technician’s patient nature and eagerness to help, but using the proper support medium will result in the quickest and best solution.