User Management

Manage who can access your FLXBL tenant. Invite team members, create service accounts for automation, and assign appropriate roles to each user.

Scope: This page covers managing your FLXBL tenant team (developers, admins, collaborators). For managing your application's end-users, see End-User Authentication.

User Types

FLXBL supports different types of users for different use cases:

100% Drag to pan 
flowchart TB
    subgraph tenant [Your FLXBL Tenant]
        subgraph team [Team Members]
            TM1[Admin User]
            TM2[Editor User]
            TM3[Viewer User]
        end
        
        subgraph accounts [Service Accounts]
            SA1[CI/CD Pipeline]
            SA2[Backend Service]
        end
        
        subgraph keys [API Keys]
            K1[Frontend Key]
            K2[Mobile App Key]
        end
    end
Types of identities in a FLXBL tenant
Type Authentication Use Case
Team Members Email + Password Human users who access the dashboard and APIs
Service Accounts API Key only Automated processes, CI/CD pipelines, backend services
API Keys Token-based Application integrations without user identity

Inviting Team Members

Invite colleagues to collaborate on your FLXBL projects. Invitees receive an email with a link to create their account and join your tenant.

100% Drag to pan 
flowchart LR
    A[Admin] -->|Sends Invite| B[Email Sent]
    B --> C[User Clicks Link]
    C --> D[Creates Password]
    D --> E[Joins Tenant]
    E --> F[Role Assigned]
Team member invitation flow

Send an Invite

// Invite a new team member
POST /api/v1/users/invite
{
  "email": "colleague@company.com",
  "roleId": "role_editor_abc123",  // Optional: assigns role
  "message": "Join our team to collaborate on the project"
}

// Response
{
  "inviteId": "inv_xyz789",
  "email": "colleague@company.com",
  "status": "pending",
  "expiresAt": "2025-01-22T10:30:00Z"
}

Via Dashboard

  1. Log in to platform.flxbl.dev
  2. Navigate to Settings → Team
  3. Click Invite Member
  4. Enter the email address
  5. Select a role for the new member
  6. Click Send Invite
Invitations expire after 7 days. You can resend or cancel pending invitations from the Team settings page.

Managing Users

List Team Members

// List all users in your tenant
GET /api/v1/users

// Response
{
  "users": [
    {
      "id": "user_abc123",
      "email": "admin@company.com",
      "role": {
        "id": "role_admin",
        "name": "Admin"
      },
      "status": "active",
      "lastLogin": "2025-01-16T14:22:00Z"
    },
    {
      "id": "user_def456",
      "email": "colleague@company.com",
      "role": {
        "id": "role_editor",
        "name": "Editor"
      },
      "status": "active",
      "lastLogin": "2025-01-15T09:15:00Z"
    }
  ]
}

Change User Role

// Change a user's role
PATCH /api/v1/users/user_def456/role
{
  "roleId": "role_admin_abc123"
}

// Response
{
  "id": "user_def456",
  "email": "colleague@company.com",
  "role": {
    "id": "role_admin_abc123",
    "name": "Admin"
  }
}

Remove a User

// Remove a user from your tenant
DELETE /api/v1/users/user_def456

// The user's FLXBL account remains but loses
// access to your tenant and its data

Service Accounts

Service accounts are special users designed for automated processes. Unlike regular users, they authenticate only via API keys and don't have passwords.

When to Use Service Accounts

Use Case Why Service Account
CI/CD Pipeline Deploys schema changes, needs audit trail tied to "CI System"
Backend Service Processes orders, needs its own identity separate from developers
Scheduled Jobs Runs maintenance tasks, audit logs show "Cron Job" not a person
Third-party Integration Zapier, n8n, etc. - identifiable in logs and manageable separately

Service Accounts vs API Keys

Feature Service Account API Key
User Identity Yes - appears in audit logs No - only key ID tracked
Role Assignment Full role-based permissions Explicit scope list
Multiple Keys Can have multiple API keys One key = one set of scopes
Dashboard Access No (API-only) No
Best For Systems that need identity Simple integrations

Creating Service Accounts

// Service accounts are special users for automated processes
// They authenticate via API key, not password

// Create a service account via MCP
"Create a service account called 'ci-pipeline' with 
 read access to all entities and write access to deployments"

// The service account gets:
// 1. A user identity for audit logs
// 2. An API key for authentication
// 3. Scoped permissions like regular users

Audit Logging

All user actions in FLXBL are logged for security and compliance. Query audit logs to see who did what and when. 

// All user actions are logged for audit
GET /api/v1/audit-logs?userId=user_abc123

// Response
{
  "logs": [
    {
      "id": "log_xyz",
      "userId": "user_abc123",
      "action": "entity.created",
      "entityName": "Product",
      "entityId": "node_prod_123",
      "timestamp": "2025-01-16T14:22:00Z",
      "ipAddress": "192.168.1.1"
    }
  ]
}

Audit logs capture:

  • Who - User ID and identity
  • What - Action performed
  • When - Timestamp
  • Where - IP address
  • On what - Entity and record affected

Best Practices

Team Management

  • Principle of least privilege - Assign the minimum role needed
  • Review access regularly - Remove users who no longer need access
  • Use descriptive roles - Create roles that match job functions

Service Accounts

  • One account per service - Makes auditing and revocation easy
  • Name accounts clearly - "ci-github-actions" not "bot-1"
  • Rotate keys periodically - Even for automated systems

Security

  • Require email verification - Enable in identity configuration
  • Monitor audit logs - Watch for unusual activity
  • Remove inactive users - Offboard promptly when people leave

Next Steps