- Checking your product versions are supported
- Raising a ticket
- A ticket or a call?
- Ticket priorities
- What should I include in my Support Ticket?
- Reopening a ticket in Solved or Closed status
- Diagnostic logs
Please refer to Best practice for raising an Identity Cloud ticket with ForgeRock Support for guidance if you are raising a ticket for Identity Cloud.
ForgeRock supports customers using the versions and platforms specified in the product Release Notes and End of Service Life policy, our End of Service Life (EOSL) policy and currently supported version are listed in the KB articles listed below:
- ForgeRock End of Service Life (EOSL) policy determines how long certain releases are supported for.
- Checking your product versions are supported provides version specific EOSL dates and accompanying Release Notes.
Support can only be offered on versions of the products that remain within the contracted EOSL dates.
- Suspected bugs or problems with ForgeRock software.
- Requests for assistance (please look at the documentation and Knowledge Base first wherever possible).
You can raise a ticket using BackStage our Customer Support Portal that provides one stop access to ForgeRock services. This link shows all currently open support tickets and allows you to raise a new one by clicking New Ticket.
What information should I provide?
When submitting a Support ticket, you should provide a detailed use case and problem statement with the following: Name and version of the product, platforms, reproducible steps, changes made to the system or environment prior to the issue, exact error messages, logs etc. See What should I include in my Support Ticket for further guidance. This will allow us to properly identify and diagnose your technical issue and speed up response and resolution of the ticket. Lack of this information could cause delay in solving your issue.
For issue tracking purposes please submit a separate support ticket for each incident. This also allows us to better focus on the new issue and not mix vital information which can delay time to resolution.
Can my team see all the ticket updates?
Yes. You can cc individual users on a support ticket as needed. Navigate to: Tickets, select the required ticket and add any users who should receive updates to the CCs field.
If you would like individuals or your entire team included on all ticket updates, please let us know through a support ticket so we can set up permissions correctly to allow your team members to view and comment on all tickets.
What can I do if I am having issues accessing BackStage?
If you are having any issues using the system or have any queries about your subscription, you can email: firstname.lastname@example.org
The most efficient model of supporting you and resolving an issue is through our ticketing system on BackStage. This is because through a ticket we can:
- Analyze technical detail accurately that is only possible to see when written down, for example, configuration files or architecture diagrams.
- Take uploaded logs and examine these against the product codebase.
- Get several technical resources to review the details, including our support, engineering and management teams.
- Attempt to reproduce your issue in our test environments.
- Follow a logical path of troubleshooting.
- Keep a record of the actions taken, for accountability and auditing purposes.
- Progress multiple issues asynchronously.
- If required, hand over urgent issues to the next timezone.
Phone calls and web conferences are generally not optimal, especially in the early stages of troubleshooting and diagnosis. However, they can be useful in some circumstances.
What if a call is needed?
In the event that a call is needed, we will set up a time-limited web conference and send you the link. If it is not urgent, we will schedule this for the following day or later in the week (as appropriate).
- We will agree an agenda at the start of the call (or in the ticket prior to the meeting if there is time) and determine next steps at the end of the call.
- It should be determined before the call who the most relevant person(s) from your organization and ForgeRock are to join the meeting to help with a successful resolution. Uncontrolled calls with large audiences are not productive.
- We will attempt to determine the full extent of the issue and offer a workaround if this is possible.
- The support/sustaining engineer will not make changes to your systems. We operate a hands-off approach, allowing for you to make changes once you have deemed them appropriate.
- Notes will be made about the content of the call and documented in the appropriate support ticket.
You may be asked to show us that the problem is not related to your environment/infrastructure and that it is a ForgeRock product issue.
What should you do prior to a call?
- You should make a full backup of your system.
- You should provide all the troubleshooting information pertinent to the case, that is, problem description, debug logs, infrastructure details, context of the issue etc. See What should I include in my Support Ticket for further guidance.
- You should read the appropriate documentation and Knowledge Base around the topic area.
- Urgent (P1) - there is a production down issue affecting all or most end users. No workaround is available. Does not include development issues, problems in staging environments or ForgeRock products running on non-supported versions or platforms.
- High (P2) - there is a major feature or function that is not working correctly in production and it is blocking full use of the system but other features are operational, or there is a major feature or function that is not working correctly in a pre-production environment that could delay deployment or upgrade. This priority can also be used for root cause analysis on a production failure where service has been restored.
- Normal (P3) - there is a minor issue or non-production issue impacting usability or administration of the system but a workaround is available and major functionality is working correctly.
- Low (P4) - there is intermittent or unexpected behavior observed which suggests a possible problem or a request for enhancement (RFE). Low or no user impact.
These priorities should be used with prudence and only be selected if they meet your situation. Our aim is to always respond and progress your requests in a timely manner.
We treat Urgent issues very seriously; we will expect that you have carried out all reasonable testing and that you have good reason to suspect the ForgeRock software as being in some way the cause of your issue.
Why did you change the priority of my ticket?
When you raise an Urgent ticket and the production system operation is restored, we will normally change it to High. We recognize that even after the service is back to normal there will be some focus on finding the root cause to regain confidence that the same thing will not happen again.
There are a few situations where we might downgrade a ticket without asking, for instance, installation issues or questions that have been raised as High or Urgent priority but where it is clear from the context that the wrong priority has been selected.
If you have multiple tickets open simultaneously, please help us to prioritize them for you by using the appropriate level for all your tickets. Using High or Urgent for all tickets will dilute the focus on which tickets require the highest attention. Our primary focus will be to help you get the system back up and running; root cause analysis will then follow. For issues outside the scope of Support, we may refer you to Deployment Support Services, or we can introduce you to one of our local partners.
Can I request to change the priority of a ticket?
Yes. You can submit a change request by clicking on the 'Change Priority' button, located in the Comments section of the ticket form.
Ensure the Ticket subject contains a clear problem summary. Please identify which product and component in the stack you are having issues with and what the problem is.
For example, "Users can't log in" isn't particularly useful, whereas "AM login page returns 'invalid domain' error for users in another region" is much more descriptive and gives us immediate context and scale of the problem.
Include the following details where possible to ensure we fully understand your issue and can start troubleshooting immediately:
- Detailed problem description with product version and steps to reproduce the issue. Some issues are version specific, knowing your version will help us focus on relevant issues only.
- Include any error messages that are appearing on the console or in the logs. Refer to the Diagnostic logs section below for information on the logs you should collect depending on the type of issue you are experiencing.
- Explain in as much detail as possible what you were doing at the time of receiving the errors, include any URLs relevant to the issue.
- Include the type and version of the Web application container / Web server you are using.
- Is the problem seen in Dev? QA? or Production?
- Please provide the use case. What are you trying to achieve, what are the expected results? (Provide use case details).
- What led you to try this approach? (Provide links to any documentation or KB articles you followed).
- Date and time at which the issue was first seen?
- Has this worked in the past?
- If yes, what has recently changed prior to the issue being seen? (For example, new install, upgrade, configuration, applications, introduced load balancer, SSL, replication, increased user load, new SP or IdP etc.)
- How frequently is the issue seen? (Is the issue seen during specific times or is it intermittent?)
- Can you reproduce the issue at will?
- If yes, please provide the exact timestamp(s) of when the issue was reproduced so we can correlate this with the logs.
- Provide reproducible steps.
- Have any patches been applied to the system?
- What troubleshooting steps and debugging have already been tried?
- Provide an updated deployment diagram if applicable. Ensure to include any load balancers, proxies and firewalls.
- Assign an appropriate priority to the ticket. See Ticket priorities for further details.
You can attach log files to tickets in the BackStage support portal. See Sending troubleshooting data to ForgeRock Support for analysis for further information.
- Solved tickets can be reopened and updated. Tickets marked as solved can be reset to an open status by either responding in the ticket on BackStage or replying to an email notification that was sent from the solved ticket that you want to reopen.
- Closed tickets cannot be altered or reopened. However, you can create a follow-up request by email. This creates a new ticket that references the closed request and includes a link back to the original ticket history where support can review previous comments. Alternatively you can open a new ticket via BackStage.
- Follow up tickets can be created by replying to an email notification that was sent from the closed ticket that you want to create a follow-up for.
This section provides information on how to collect the necessary data needed for troubleshooting depending on the product and type of issue you are experiencing. Please note most issues require adjusting the logging level in order to get more detailed log data as described in the references below.
Access Management and Agents
- How do I collect all the data required for troubleshooting AM and Agents (All versions)? - this article provides a matrix of what data to collect based on issue type.
- How do I record troubleshooting information in AM (All versions)? - this tool automates the collection of troubleshooting information for AM, including all log files.
Best practice for recording troubleshooting information in AM (All versions) -
this article provides a Postman collection for recording troubleshooting information.
- Troubleshooting AM and Agents - this book provides information on troubleshooting various issues in AM, including collecting useful troubleshooting information such as logs, heap dumps and stack traces.
- How do I use the Support Extract tool in DS (All versions) to capture troubleshooting data? - this tool automates the collection of troubleshooting information for DS, including all log files.
- Troubleshooting DS - this book provides information on troubleshooting various issues in DS, including collecting useful troubleshooting information such as heap dumps and stack traces.
- Troubleshooting IDM - this book provides information on troubleshooting various issues in IDM, including collecting useful troubleshooting information such as logs, heap dumps and stack traces.
- How do I generate more detailed debug logs to diagnose an issue in IG (All versions)? - this article provides information on collecting IG debug logs.
- Troubleshooting IG - this book provides information on troubleshooting various issues in IG, including collecting useful troubleshooting information such as logs, heap dumps and stack traces.