Profiles

Profiles represent the people who use Glow — instructors, teaching assistants, and administrators. Every user in your institution gets a profile that determines what they can access and how they interact with simulations through cohorts.

What is a Profile?

A profile is a user identity in Glow. Each profile has a name, email, role, department membership, and optional request limits. Profiles are the foundation of the platform: they are assigned to cohorts, which in turn give learners access to simulations.

University example: Your CS department might have profiles for Professor Smith (Instructional Staff), TA Johnson (Instructional Staff), and a University Admin (Super Administrator). Each profile’s role controls what they can create, edit, and view across the platform.

How It Connects: The 5-Step Workflow

Profiles participate in step 4 of the Glow workflow:

1. Create Personas — Define AI student characters with temperaments and behaviors.
2. Assign to Scenarios — Attach personas and documents to scenarios.
3. Add to Simulations — Group scenarios into simulations.
4. Add to Cohorts — Assign profiles and simulations to a cohort. Profile personas tell the AI who each learner is, so the AI character can adapt.
5. Run Attempts — Learners launch simulations from their cohort.

Profiles are the link between real users and the simulation experience. Without a profile assigned to a cohort, a user cannot access any simulations.

Create a profile

Via the CLI

Calls below use $GLOW_INSTANCE_URL + $GLOW_TOKEN — see Authentication to export them once.

glow profiles create --body '{
  "profiles": [
    {
      "name": "TA Johnson",
      "email": "johnson@university.edu",
      "role": "Instructional Staff"
    }
  ]
}'

Via the API

All endpoints use POST and require an Authorization: Bearer header.

curl -X POST $GLOW_INSTANCE_URL/profile/create \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "profiles": [
      {
        "name": "Professor Smith",
        "email": "smith@university.edu",
        "role": "Instructional Staff"
      }
    ]
  }'

Roles, departments, and request limits

Roles

Glow supports three profile roles, each with different permissions:

Example: TA Johnson has the Instructional Staff role and can run practice simulations in their assigned cohorts. The University Admin has the Super Administrator role and can manage profiles across all departments.

Department membership

Every profile belongs to one or more departments. Department membership controls:

• Which resources (documents, parameters, scenarios) the profile can see
• Which cohorts the profile can be added to
• Which other profiles the user can manage (for administrators)

Example: Professor Smith belongs to the “University” department and can see all resources scoped to that department.

Request limits

Profiles can have request limits that cap how many simulation attempts a learner can make. This is useful for controlling API usage in large courses.

Emulating another profile

Super Administrators can emulate any profile to debug what that user actually sees — cohort access, role-gated UI, request-limit warnings, the works. Emulation is a sub-operation on the profile artifact (POST /profile/emulate), and you exit it with POST /profile/unemulate.

Start emulation:

curl -X POST $GLOW_INSTANCE_URL/profile/emulate \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "profile_id": "ta-johnson-uuid"
  }'

Stop emulating and return to your own profile:

curl -X POST $GLOW_INSTANCE_URL/profile/unemulate \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

Emulation is audit-logged; only Super Administrators can invoke /profile/emulate.

Drafts

Profiles support the draft workflow. When you create or update a profile through the UI, changes are saved as a draft before being published. The draft endpoint enforces optimistic concurrency via expected_version.

# Save a profile draft
glow profiles draft --body '{
  "name": "TA Johnson",
  "email": "johnson@university.edu",
  "role": "Instructional Staff"
}'

Via the API, use PATCH /profile/draft with fields like input_draft_id, expected_version, name, email, flag_id, department_ids, and role_ids.

Search and filter

Profile search supports full-text plus facet filters across role, department, and cohort membership.

curl -X POST $GLOW_INSTANCE_URL/profile/search \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "search": "Johnson",
    "role_filter": "Instructional Staff",
    "page_size": 10
  }'

Bulk operations

Bulk delete and update follow the canonical all-matching shape — pass either explicit IDs, or all: true with flat filter fields + optional excluded_ids + a patch for updates.

# Delete every profile in a sunset department, except admins
glow profiles delete --body '{
  "all": true,
  "filter_department_ids": ["dept-sunset"],
  "excluded_ids": ["super-admin-uuid"]
}'
 
# Bulk update via patch (e.g. raise request limits for an entire cohort)
glow profiles update --body '{
  "all": true,
  "filter_department_ids": ["dept-cs"],
  "patch": { "request_limit": 100 }
}'

See the Personas guide for the canonical write-up of this pattern.

Common Operations

Related

• Profiles API
• Profiles CLI
• Cohorts Guide — assign profiles to cohorts
• Departments Guide — manage department membership