Countly User Management — Global Roles, App Permissions

Countly Permission Model

Countly uses a two-tier permission model: global roles that control platform-wide capabilities, and per-app permissions that control what a user can do within specific applications. This separation means a user can be a restricted global user but have full admin rights on a specific app, or vice versa.

The permission model differs between Countly Community Edition (self-hosted, open source) and Countly Enterprise Edition (additional SSO, audit logging, and granular permissions). This guide covers both, noting where Enterprise-only features apply.

Global Roles

Global roles determine platform-level access. Every Countly user has exactly one global role:

Role details:

• Global Administrator has unrestricted access to the entire Countly instance. They can create and delete applications, manage all users regardless of app assignment, configure server settings (API limits, data retention, logging), and install or remove plugins. Keep this role to 1-2 infrastructure administrators.
• Global Admin (limited) -- available in some Countly versions as a middle tier. Can create new applications and manage users on applications they created or were granted admin access to. Cannot access server configuration or plugin management.
• Global User is the default role for most team members. They can only see applications they have been explicitly assigned to, and their capabilities within each app depend on their per-app permission level.

Per-App Permission Levels

Each application (e.g., "Production iOS", "Staging Web", "Marketing Website") has its own user access list. Users are assigned one of these levels per app:

App-level permission details:

• Admin on an app can configure the app's settings (data retention, event mapping, user property definitions), manage which plugins are active for the app, and add or remove other users from the app. App Admins cannot modify server-level settings.
• User can view all dashboards, drill-down reports, user profiles, and session recordings. They can create and save custom segments, dashboards, and filters. They cannot modify app settings or manage other users.
• Read-Only users see aggregated dashboards and reports but cannot access individual user profiles, raw event streams, or session recordings. They cannot create custom segments or export raw data.

Admin UI Paths

Managing users (Global Administrator):

Countly Dashboard
  > Management (left sidebar, gear icon)
    > Users
      > Create User / [Edit existing user]
        > Set Global Role
        > Assign App Permissions (select apps + permission level per app)

Managing users on a specific app (App Admin):

Countly Dashboard
  > [Select app from app switcher, top-left]
    > Management
      > Users
        > Shows users with access to this app
          > Modify permission level or remove

Viewing a user's complete access:

Management > Users
  > [Click username]
    > Shows: Global Role, all app assignments with permission levels, last login, API keys

Bulk user operations:

Management > Users
  > Select multiple users via checkboxes
    > Bulk actions: change global role, remove from apps, delete accounts

API Key Management

Countly uses API keys for programmatic access, and every user account has associated keys:

• App Key -- unique per application, used in the SDK to send event data. Not user-specific. Found in Management > Applications > [App] > App Key. Anyone with the app key can send data to the application.
• API Key (User) -- unique per user, used for reading data via the Countly API. Found in the user's profile or Management > Users > [User] > API Key. The API key inherits the user's permission level.
• API Key regeneration -- Global Administrators can regenerate any user's API key. App Admins can regenerate keys for users on their apps. Regeneration immediately invalidates the old key.

API access implications:

• A user's API key respects their per-app permissions. If a user has Read-Only access on App A and Admin on App B, their API key can read aggregated data from App A and full data from App B.
• Disabling or deleting a user immediately invalidates their API key.
• There is no separate API-only credential system. All API access goes through user API keys.

Analytics-Specific Permissions

How Countly roles affect analytics features:

• Dashboards -- all permission levels can view pre-built and shared dashboards. Creating custom dashboards requires User or Admin level.
• Cohorts and segments -- creating cohorts and custom segments requires User or Admin. Read-Only users can view existing segments but cannot create new ones.
• Funnels -- funnel creation and modification requires Admin. Users can view existing funnels. Read-Only users see funnel reports only.
• Crash analytics -- viewing crash reports requires User or Admin. Read-Only users see crash summary metrics but not individual crash details.
• Push notifications -- sending push messages requires Admin on the app. Users can view push campaign results but cannot create or schedule sends.
• Session recordings / Heatmaps (Enterprise) -- viewing session replays requires User or Admin. Read-Only users cannot access recordings. Configuring which pages or screens are recorded requires Admin.
• Data export -- CSV and API export of raw event data requires User or Admin. Read-Only users can only export aggregated dashboard views.
• Data retention -- modifying data retention policies (how long event data is kept) requires App Admin or Global Administrator.
• Revenue analytics -- if revenue tracking is configured, all permission levels can view revenue dashboards. Modifying revenue event mappings requires Admin.

Enterprise SSO and Directory Integration

Countly Enterprise Edition supports external identity providers:

• LDAP / Active Directory -- users can authenticate via LDAP. Group-to-role mapping is configured in server settings by a Global Administrator. When a user is removed from the LDAP group, their Countly access is revoked on next login attempt.
• SAML 2.0 SSO -- single sign-on through providers like Okta, Azure AD, or OneLogin. User provisioning can be automatic (just-in-time) or manual.
• SCIM (Enterprise) -- automated user provisioning and deprovisioning through SCIM-compatible identity providers.
• Audit logging (Enterprise) -- all user management actions (creation, role changes, removal) are logged with timestamp, actor, and details. Export audit logs from Management > Audit Logs.
• IP whitelisting (Enterprise) -- restrict dashboard and API access to specific IP ranges. Configured at the server level by Global Administrator.

Multi-App Management Patterns

For organizations with many tracked applications:

• Group related apps (production, staging, development) and assign the same user permissions across the group.
• Use App Admin for team leads who manage their own app's user access, reducing the need for Global Administrator involvement.
• Create a "demo" or "sandbox" app with User-level access for onboarding new team members before granting production access.

Step-by-Step Guides

• Add User Access -- create user accounts and assign app permissions
• Update Access -- modify global roles or per-app permission levels
• Remove Access -- revoke access, handle API keys, and document offboarding