Investigating support tickets across integrations

A customer reports an access problem. Their IT admin says the account is configured correctly. Your application shows something different. Before support can suggest a fix, someone has to work out where those two views stopped agreeing.

WorkOS’s September 18 release offers a useful example of making that investigation easier. Its SCIM Logs tab shows 30 days of requests from identity providers, the responses WorkOS returned, and diagnostic messages for failures. It also links requests to the events they produced, with navigation in both directions.

That gives support a way to follow a specific change through the integration. The next question is whether your own application provides enough evidence to finish the investigation.

• WorkOS: Debugging with SCIM Logs

Start with the customer’s symptom

Consider an illustrative ticket: an administrator removed a user from a group in Okta, but that user can still access a project in your application. This example assumes the application uses directory groups to grant project access; it is not a reported WorkOS incident.

There are several possible explanations. The membership update may not have reached the directory service. Your application may not have processed it yet. Or the application may have processed it correctly while another group still grants access. Each explanation calls for a different next step.

Begin with the customer’s organization, the affected user and project, and the approximate time of the change, including the time zone. Those details give you a search you can run. Asking the customer to collect every available log before you know which system needs attention creates extra work without necessarily narrowing the problem.

Find the change at the integration boundary

SCIM is the protocol identity providers use to manage users and groups in other services. In this example, the first question is whether the provider sent the intended membership change and what response it received.

WorkOS’s request logs expose that exchange. Its linked events let an investigator move between the incoming operation and the directory activity it produced. A group-removal event is evidence about the directory. It still leaves a separate question: what did your application do next?

If you cannot find the request, check the directory, filters, time window, and available history before concluding that nothing was sent. A search outside the retained period cannot establish whether an older operation happened.

Follow the event into your application

WorkOS documents two ways applications can consume events: its events API and webhooks. Whichever your application uses, keep the upstream event ID in the records your support team can search. That gives them a concrete way to connect provider activity to application processing.

• WorkOS: consuming events to sync application data

For the access ticket, look for the application’s processing record for the membership change. Receiving an event, adding it to a queue, and successfully updating permissions are different milestones. A log saying the event was received does not establish that the permissions update finished.

Retries matter here. If the first attempt failed and the second succeeded, support needs to see both outcomes. Keeping the event ID alongside a separate ID for each attempt makes that history readable. Otherwise, a failure log can look like an unresolved problem long after a retry repaired it.

Check why the user still has access

Even a completed membership update may leave the original ticket unresolved. In our example, another group could still grant access to the same project. Support needs to inspect the application’s effective permissions and the rule that grants them, rather than assuming a directory change must remove all access.

These findings also make an engineering escalation more useful. Instead of forwarding an access complaint with a pile of logs, support can identify the last confirmed step, link the relevant records, and explain which result is still unexplained.

Give the customer an answer that matches the evidence

A good update explains what changed, what the investigation confirmed, and what remains to be done. If another group grants access, identify that grant and explain its effect. If application processing failed, distinguish that failure from the customer’s configuration and give the status of the repair. Avoid asking an administrator to repeat setup steps that the evidence already shows succeeded.

The same discipline applies to uncertainty. If the request history has expired, say which part could not be verified. If a retry was queued but has not completed, do not describe the issue as fixed. Before closing the ticket, verify the relevant application state and confirm that it addresses the behavior the customer reported.

Build the investigation path support actually needs

For engineering teams, the useful improvement is a way to move from a customer account to the relevant event, its processing attempts, and the resulting application change. Preserve the identifiers as work crosses queues. Keep the outcome of each attempt. Provide links to provider records where they are available.

Make those lookups accessible within the support team’s existing permissions, scoped to the customer’s organization. Support should be able to inspect the evidence for the affected account without needing broad access to production data or unrelated customers.

WorkOS supplies one part of that path. Your application has to supply the rest. Together, those records let support explain where a customer’s change stopped, whether it eventually completed, and why the product is behaving the way it is now.