Expert Call Troubleshooting

Overview

The AlphaSense Enterprise Insight platform provides access to Expert Call transcripts through two content subtypes: AlphaSense Expert Calls (CodeLevel2 3610–3616) and Tegus transcripts (CodeLevel2 3617). Access is governed by user-level feature flags (EXPERT_CALLS_ONLY and TEGUS_TRANSCRIPTS), compliance lock rules that can restrict access based on document metadata, and the expert-calls-api service which manages entitlement properties and applies compliance configuration.

The expert-calls-api service operates a few variants: MAIN, PROCESSOR, CONSUMER

The processor variant is used exclusively by the indexer service and intentionally skips caching mechanisms in order to always provide the search service with the most up-to-date information. When entitlements are updated, a message is published and consumed by the indexer, which in turn recalculates tokens.

The consumer variant subscribes to various messages queues (from user-service and dds mainly) to be informed of changes to users and documents.

The main variant handles everything else, and publishes asynchronous events so downstream services can invalidate caches and react to permission changes

Primary dependencies include user-service for identity and permission events, feature-storage for entitlement data, and document-data-realtime for document metadata.

This document serves to outline common failure scenarios related to Expert Call access and provide troubleshooting steps for resolution.

Entitlement Quick Reference

Important: Even when feature flags grant access, a user may still be blocked from specific EC documents due to compliance locks based on document metadata — for example, analyst domain, expert employment type, or time since public employment. Compliance locks are independent of CodeLevel2 grouping.

Failure Scenarios

1. User Cannot Open Any Expert Call Transcripts

Triage:

A user reports they cannot open Expert Call transcripts they believe they are entitled to access. Before investigating the service layer, first confirm whether the issue affects AlphaSense EC documents, Tegus transcripts, or both — as each subtype has a separate feature flag and the root cause will differ.

Troubleshooting:

Confirm the following before investigating:

• User ID or email
• Environment (SaaS, EU SaaS, or Private Cloud)
• Example transcript or document ID(s)
• Whether the failure affects all EC documents or only specific subtypes

Verify pod readiness and check for recent restarts or CrashLoopBackOff events:

kubectl get pods -n platform | grep -E "expert-calls-api|expert-calls-api-processor"

Fetch the user's entitlement properties from expert-calls-api to determine whether the entitlement data is correct:

curl --location 'http://expert-calls-api.platform/v1/entitlements/user-entitlement-properties' \
  --header 'accept: */*' \
  --header 'Content-Type: application/json' \
  --data '{
    "userIds": [<user-id>]
  }'

Check what feature flags the user currently has. Confirm the presence of:

• EXPERT_CALLS_ONLY — required for AS EC docs (3610–3616)
• TEGUS_TRANSCRIPTS — required for Tegus transcripts (3617)

If neither flag is present, consult Alphasense Support team to help with add these flags.

If entitlement properties appear correct but the user still cannot access transcripts, the issue is likely downstream cache propagation — proceed to the cache propagation scenario below.

Check for errors in expert-calls-api logs and connectivity to primary dependencies:

kubectl logs -n platform deployment/expert-calls-api --tail=300

2. User Cannot Access Tegus Transcripts Specifically

Triage:

A user can open AlphaSense Expert Call documents but cannot open Tegus transcripts. This indicates the user has the EXPERT_CALLS_ONLY flag but is missing the TEGUS_TRANSCRIPTS flag, which is required separately for CodeLevel2 3617 content.

Troubleshooting:

First, Confirm the document being accessed is a Tegus transcript by verifying CodeLevel2 = 3617 in document metadata if available.

Fetch the user's entitlement properties and confirm whether TEGUS_TRANSCRIPTS is present:

curl --location 'http://user-service.platform/internal/user/{user_id}/features'

Second check if the user has Tegus license assigned to them. If not then assign the license. Then TEGUS_TRANSCRIPTS should be present in the user permission list.

As a mitigation step TEGUS_TRANSCRIPTS can use add to the user permission list, use the following API to add the missing permission. Also escalate to Alphasense Support

curl --location --request PATCH 'http://user-services.platform/internal/user/{user-id}/permissions?noRegion=true' \
  --header 'Content-Type: application/json' \
  --data '{
    "add": [
      "TEGUS_TRANSCRIPTS"
    ]
  }'

3. User Can Access Some EC Documents but Not Others (Compliance Locks)

Triage:

A user can open most Expert Call transcripts but a specific subset is blocked with no obvious pattern based on content type. This typically indicates compliance lock rules are restricting access to specific documents based on document metadata (such as analyst domain, expert employment type, or time since public employment) rather than a missing feature flag.

Troubleshooting:

This issue can be complex to diagnose accurately. Collect the following before escalating:

Confirm the symptom by identifying whether failures correlate with a specific pattern — for example, documents from a particular company, analyst domain, or expert type.

Confirm the user's feature flags are correctly set (see scenario above). If flags are correct and the issue is isolated to a subset of documents, compliance locks are the likely cause.

Confirm whether the user is a compliance-gated user in the Expert Calls user model (internally referenced as expert_calls_users). If so, validate the specific document entitlement via the Entitlement Service or expert-calls-api entitlement endpoints.

Validate the compliance configuration being applied for the affected org or user:

kubectl logs -n platform deployment/expert-calls-api --tail=300

Escalate to the Expert Insights team with the example user, document IDs, and any observed patterns in the blocked documents.

4. User Can Access Transcripts They Should Not Have Access To

Triage:

A user can open an Expert Call transcript they should no longer have access to. This typically indicates incorrect entitlement mapping or a stale downstream cache that was not invalidated after access was removed. If this affects multiple users or involves compliance-restricted content, treat this as a potential data exposure risk and escalate immediately.

Troubleshooting:

If this issue affects multiple users or involves compliance-restricted content, escalate immediately before attempting resolution.

Verify entitlement properties returned by expert-calls-api for the affected user:

curl --location 'http://expert-calls-api.platform/v1/entitlements/user-entitlement-properties' \
  --header 'accept: */*' \
  --header 'Content-Type: application/json' \
  --data '{
    "userIds": [<user-id>]
  }'

If the properties show access that should have been revoked, check when access was removed and whether the removal event was published and consumed:

kubectl logs -n platform deployment/expert-calls-api-consumer --tail=300

Validate that the compliance configuration for the affected org or user is being correctly applied and has not been misconfigured.

Check for stale cache invalidation after permission removal.

5. UI Shows Stale Access State After Permission Changes

Triage:

A user's access state shown in the UI does not reflect recent permission changes — either access that was granted is not yet visible, or access that was revoked still appears active. This indicates the asynchronous event pipeline between expert-calls-api and downstream entitlement consumers is degraded or backed up.

Troubleshooting:

Verify that expert-calls-api-consumer pods are running and healthy:

kubectl get pods -n platform | grep expert-calls-api-consumer
kubectl describe pods -n platform -l app=expert-calls-api-consumer

Check processor logs for evidence of event backlog, consumer lag, or processing errors:

kubectl logs -n platform deployment/expert-calls-api-consumer --tail=300

If the processor is in a degraded state with a clear transient failure — such as a deadlock, stuck consumer, or event backlog with no underlying data issue — restart the processor to restore event consumption:

kubectl rollout restart deployment/expert-calls-api-consumer -n platform

If the issue is linked to a recent deployment, consider rolling back to the previous release. After any restart, monitor logs to confirm healthy event consumption before closing the incident.

6. Access Differs Between Environments (SaaS vs Private Cloud)

Triage:

A user can access Expert Call transcripts in one environment but not another despite having the same entitlements. This typically indicates a configuration or deployment difference between environments, or a delay in permission sync across environments.

Troubleshooting:

This issue can be complex to diagnose without access to both environments. Collect the following before escalating:

• Environment names where access is working vs failing
• User ID or email and example transcript/document ID(s)
• Expected vs actual behaviour in each environment
• Any recent permission changes or deployment activity
• API response from expert-calls-api in both environments for the same user, if accessible

If the issue is specific to Private Cloud, include both PC platform and entitlement owners in the escalation.

Validation Steps

After applying any resolution:

1. Re-fetch user entitlement properties from expert-calls-api and confirm they reflect the expected state
2. Impersonate the affected user and attempt to open an AS Expert Calls transcript (CodeLevel2 3610–3616)
3. If the user should have Tegus access, repeat with a Tegus transcript (CodeLevel2 3617)
4. Confirm that any compliance-restricted documents remain inaccessible for the affected user
5. If a processor restart was applied, monitor logs for healthy event consumption before closing the incident