LogRocket User Management

LogRocket Permission Model

LogRocket uses a two-tier permission model: organization roles that control platform-wide capabilities, and app-level roles that control what a user can do within specific applications (production, staging, development environments). Every LogRocket user belongs to an organization and can have different permission levels across different apps within that organization.

The organization is the billing entity. Apps are the tracked environments, each with their own session data, error logs, and configuration. A user's effective permissions are the combination of their organization role and their per-app role.

Organization Roles

Every user has one organization-level role:

Organization role details:

• Owner is the highest privilege. There is always exactly one Owner per organization (the account creator). Ownership can be transferred to another Admin through Settings > Organization > Transfer Ownership. The Owner is the only role that can change the billing plan, update payment methods, or delete the organization.
• Admin can manage team membership, create and delete apps, configure integrations at the org level (Slack, Jira, PagerDuty), and view (but not modify) billing information. Multiple Admins are recommended for redundancy.
• Member is the default role for most team members. Members can only access apps they have been explicitly invited to and cannot see or modify any organization-level settings. Their capabilities within each app depend on their app-level role.

App-Level Roles

Each app (e.g., "Production", "Staging", "Internal Tools") has its own user list with role assignments:

App-level role details:

• App Admin has full control over the app's configuration: privacy rules (element masking, network sanitization, input exclusion), source map uploads, integration settings (error tracking, alerting), and retention policies. Grant this role to engineers implementing LogRocket or managing configuration.
• App Member can view all sessions, create saved filters and segments, share session URLs with team members, and use the session search. They cannot modify app settings, privacy rules, or integrations. This is the standard role for developers, QA, and support engineers.
• App Viewer has restricted access: they can view sessions shared via URL but cannot browse the session list, create filters, or search sessions independently. Use this for stakeholders or cross-functional team members who receive specific session links.

Admin UI Paths

Organization-level user management:

LogRocket dashboard
  > Settings (gear icon, left sidebar)
    > Organization
      > Team tab
        > Invite Member / [Edit existing member]
          > Set Organization Role (Owner / Admin / Member)

App-level user management:

Settings
  > [Select app from app switcher, top-left]
    > App Settings
      > Team tab
        > Assign App Role (Admin / Member / Viewer)
        > Or remove user from this app

Viewing a user's complete access:

Settings > Organization > Team
  > [Click user]
    > Shows: Org role, all app assignments with roles, last active date

Inviting a new user:

Settings > Organization > Team
  > Invite Member button
    > Enter email
      > Select Org Role
        > Select which apps to grant access to and the role per app
          > Send invitation

API Key Management

LogRocket uses several types of keys and tokens:

• App ID -- the public identifier for each app, used in the LogRocket SDK initialization (LogRocket.init('org/app-id')). Not secret, but identifies which app receives session data.
• API Key -- used for server-side operations like source map uploads (logrocket upload-sourcemaps --apikey=KEY). Found in Settings > App Settings > General. One API key per app.
• Personal API tokens -- used for the LogRocket REST API. Generated per user in Settings > Account > API. The token inherits the user's permission level across apps.
• Integration tokens -- tokens for specific integrations (Jira, Slack, PagerDuty) are configured at the app level by App Admins.

API key audit considerations:

• API keys are app-scoped, not user-scoped. Rotating an API key affects all integrations using it for that app.
• Personal API tokens are user-scoped. When a user is removed from the organization, their personal token is invalidated.
• Source map upload keys should be stored in CI/CD secrets, not individual developer machines. If a developer with the key leaves, rotate the app API key.

Analytics-Specific Permissions

How LogRocket roles affect analytics and session replay features:

• Session replay -- App Admin and Member roles can browse and replay all sessions. Viewers can only replay sessions shared with them via URL. Session data includes DOM replay, network requests, console logs, and Redux/Vuex state (if configured).
• Error tracking -- viewing error details, stack traces, and affected sessions requires App Member or Admin. Viewers cannot access the Errors dashboard.
• Performance monitoring -- page load metrics, Web Vitals, and performance dashboards are visible to App Member and Admin roles. Viewers cannot access performance data.
• User search -- finding sessions by user ID, email, or custom traits requires App Member or Admin. This is a critical analytics feature for support and debugging workflows.
• Funnel analysis -- creating and viewing conversion funnels requires App Member or Admin.
• Metrics dashboards -- custom metric dashboards (session counts, error rates, rage click frequency) require App Member or Admin to create. Existing dashboards are visible to Viewers if shared.
• Alerts -- configuring alert rules (error spike, new error type, performance regression) requires App Admin. Members can subscribe to existing alerts.
• Privacy-filtered data -- what appears in session replays depends on privacy configuration (set by App Admin). All users see the same privacy-filtered view; there is no per-user privacy override.
• Data export -- exporting session data or error reports via CSV requires App Member or Admin. API export requires a personal API token.

SSO and SCIM Integration

LogRocket supports enterprise identity management:

• SAML 2.0 SSO (Enterprise plan) -- configure in Settings > Organization > Security. Supports Okta, Azure AD, OneLogin, and other SAML providers. When enabled, all users must authenticate through the IdP. Direct email/password login can be optionally disabled.
• SCIM provisioning (Enterprise plan) -- automate user creation and removal through your identity provider. When a user is deprovisioned in the IdP, their LogRocket access is revoked automatically.
• Domain verification -- verify your email domain to enforce that all users with matching email addresses must use SSO.
• Just-in-time (JIT) provisioning -- with SSO enabled, new users who authenticate through the IdP are automatically created as Members. App-level roles must still be assigned manually or through SCIM group mappings.

Activity Log

LogRocket maintains an activity log that tracks:

• User additions and removals
• Role changes (org and app level)
• App creation and deletion
• Integration configuration changes
• Privacy setting modifications

Access the activity log at Settings > Organization > Activity. Only Org Admins and Owners can view the log. Export it for compliance records after any access change.

Step-by-Step Guides

• Add User Access -- invite users to the organization and assign app permissions
• Update Access & Roles -- change organization or app-level roles
• Remove User Access -- offboard users, handle API keys, and document changes