This document describes the roles, responsibilities, and regular activities from the perspective of an Okta Technical Support Engineer (TSE) working as the primary contact with customers resolving their support inquiries at Okta. This includes basic duties handling inbound support queries through the entire support case lifecycle, specifically:

• Initial assignment of the support case
• Working with support administrators throughout the entire process 
• Initial problem identification and validation based on information provided by the customer
• Troubleshooting and remediation
• Confirmation of the remediation resolving the customer issue
• Closure of the support case    

Support engineers use several tools to accomplish their jobs, including the usage of Okta’s internal tools as well as third-party applications. Many tasks require in-house applications, which are used to perform basic management functions for Okta customer Orgs. It is important to note that this tool does not provide “god-like access” to all users. Rather, the app is built with security and least privilege to ensure that Support Engineers are granted only the access required to perform their duties. Support Engineers are unable to create or delete users or access source code repositories.

What follows is a general overview of a normal working day for a TSE, with additional details where necessary.

Okta Portal

The day begins by opening the Okta portal. The Okta portal provides all the required access for everything a TSE needs throughout the lifespan of a support case.

Email and Calendar

The Support portal automatically updates with notifications sent to the TSE’s work email. Additionally, meetings, both internal and customer-facing, will appear on the TSE’s work calendar.

Customer Support Platform

The Okta Support platform is where all cases originate and are administered. This is where the majority of Support work takes place. Cases are shown in an individual queue for the Support Engineer. Case correspondence, case uploads, escalations, internal posts, and more are completed on this platform. Cases are generally sorted by priority, status, and case age. This helps to determine which cases require immediate attention based on Okta’s Service Level Agreement (SLA). Troubleshooting begins by reviewing case details and requesting more information when necessary. Often, a case may be reviewed, and an issue may be resolved with a Knowledge Article referencing the exact or similar behavior. 

When additional internal research is required, the Support platform provides the Org URL and the Org ID. This information will be used to review the Org in an internal Support application. Contact is attempted via email or phone, depending on the Customer’s preference and/or case priority.  Additional information is requested, and a remote session is generally offered. 

If additional assistance is required, a TSE may consult with a Team Lead or Manager or request commentary from the Customer Success or Account Teams. This correspondence is recorded on the Support case.

Internal Support Application

Using the information obtained from the Support platform, the internal Support application is accessed to verify the information for an Org, research an Org’s system log, and perform limited actions requested by the Customer. 

Verifying information for an Org includes:

• Finding additional details required for research, such as user IDs, application IDs, and/or group IDs.
• Determining the user/group/application data appears as expected.

Using the Org system log to find event data, formulate timelines, and provide root cause information. Sometimes, it may be required to perform limited administrative actions for an Org. This will never happen without the verbal or written consent of an Okta Admin who created the case or is currently associated with the case. Following is a brief but not exhaustive list of some of these actions:

• Reset passwords: Includes “Password Reset” and “Send a temporary password” functions, which trigger a password reset link that is sent to an individual user(s) or allows Okta to create a temporary password for an account that is then sent to the user's primary and secondary email.
• Reset MFA: Resets all of the user's secondary authentication factors for users.
• Enable/disable feature flags: Toggle on/off to add or remove a product feature.

If additional troubleshooting is required, a Support Engineer may ask for Support Access to review or verify configurations.

Support Access

There are times when 'Support Access', also known as Impersonation, is used for better visibility of an Org. By default, TSEs cannot see what an Okta Admin sees, except in the case of the Okta system log. A Support Engineer with Support Access can view the Org as though they were an Okta Admin, giving insight into Rules and Policies, Profile mappings, Groups, Profile Sources, etc. Support Access is never taken lightly, and a Support Engineer never makes changes. This level of access is necessary to validate existing settings and obtain screenshots if Okta Engineering must address an issue.:

• Only an Org Super Administrator can grant access to Okta Support using the Account Settings in the Admin Console
• When enabled, access is granted for 8 hours by default but can be extended by the Super Administrator.

When an Okta Support Engineer initiates or terminates Support access into an Org, there is always an entry logged in the Okta System Log. For more information on using System Log queries to verify impersonation entries, see Auditing customer support actions in your Okta tenant using System Log.

Internal Logs

When it is necessary to research how an issue or event interacts with the platform itself, internal logs are reviewed. Not every issue requires internal logs, but it can be very helpful to determine whether a race condition occurred or compile a timeline of the general order of events. This log is accessed by Engineering and Support alike and cannot be altered by either team. Events are generally filtered by Org, timeframe, and requestIDs, which are pulled directly from syslog. If any information must be conveyed to a customer, Support will paraphrase and/or redact information taken from internal logs but never divulge exact messages or events.

Internal Messaging

Support communication between colleagues, Team Leads, Managers, and any other Okta employee/team occurs in the Internal Messaging platform. No communication with external users is allowed on this platform.

Internal Boards

When case work must be escalated to Engineering teams, the TSE will request assistance from the Internal Board, a project management platform. This request will provide all necessary data collected on a case and present it concisely to the Engineering team. Every request on this platform must go through an approval process, and depending on the type of request, the approval process can vary from an individual confirmation to a multi-layered and multi-approval process. When Engineering accepts a request, the TSE remains the intermediary between the customer and Okta Engineering. If the case has an active Escalation with an Escalation Manager (EM), the intermediary may instead be the EM assigned to the case.

Continuing Investigation and Technical Escalation

There are several internal sources of information that a TSE may find a solution or a piece of information to share with the Customer. This can include external documents found on help.okta.com or support.okta.com, but may also be found in internal wikis, archives of internal messaging, internal boards, external websites, etc. Any information deemed crucial to the case and/or that will help to resolve a Customer’s issue will be utilized. 

Case Closure

When a solution is determined, the TSE updates the Support case and will request that the case be closed. The case status will be set to “Pending - Customer” or “Resolved - Pending Confirmation”  to allow the Customer to validate the fix and confirm the resolution. Once the customer confirms the solution, the case will be closed. A Support case may be reopened within 21 days of its closure. If a case is reopened outside of 21 days, the original case will remain closed, and a new case will be automatically opened referencing the original.