Skip to content
CursareDocs
Sign in

Start here

  • Overview
  • Getting started
  • Platform concepts

Create

  • Content
  • Editor and blocks
  • Block reference

Publish & access

  • Publishing and access
  • Custom domain & white-label

Learners

  • Learner experience
  • Learners and enrollments
  • Progress and certificates

Teams & cohort

  • Teams
  • Cohorts

Sales

  • Offers & checkout
  • Payments & payouts
  • Affiliates
  • Insights and reports

Admin

  • Organization & security
  • Plans, trial & billing
  • Appearance
  • Members & roles
  • Audit log

Developer

  • Integrations
  • API keys & webhooks
  • MCP server
  • API reference
Explore the API
Teams & cohort

Teams

Teams decide who, within the organization, can operate each piece of content. A team is about the staff who produce and maintain courses — not about the learners who take them.

Teams appear once you're not alone

While you're the only person in the organization, the Teams entry stays hidden — there's no one to delegate to yet. It appears in the sidebar as soon as you invite a second person. Everything below applies from that point on.

Members versus learners

Before anything else, keep two populations apart:

  • Members are the organization's staff — the people who create, price, and moderate. Teams are made up of members, and only members.
  • Learners are the students who take the courses. They reach the organization through the content, never through the internal roster, and they never join teams.

If someone belongs to a team, they are staff. The people who learn together inside a course are organized separately, as cohorts.

Teams map your curriculum

In an education organization, the natural way to slice the staff is by curriculum area, not by company function. Think of each team as a teaching department that owns the courses in its slice of the catalog. A Programming team owns the language and fundamentals courses, plus the learning path built on them; a Backend team owns the runtime, API, and shipping courses. Who edits, prices, or tutors inside each team is then decided by the per-member roles described below.

Composition does not blur this line: a course path's referenced children can belong to a different team than the path's root, and editing rights follow each content's own team — an editor on the Programming team who opens a module owned by the Backend team is an outsider there. The Content list reflects the same slicing: its profile chips scope the list to your personal view first, then to each team.

What a team is

A team is a subgroup of the organization's staff — people who are already members of the organization. Each team has:

AttributeRule
Name2 to 60 characters; unique within the organization (case-insensitive)
LogoAn already-uploaded image (the team avatar)
BioFree text, up to 500 characters

Creating, renaming, and deleting teams, managing members, and defining roles are actions restricted to the organization owner or admin. A regular member can see every team in the organization — including each team's members, their roles, and the content it is responsible for — but does not administer the structure.

The owning team is the authority

Each piece of content can belong to one team, through the content.teamId field. That team is the single authority over the content, and who within it does what is defined by the per-member roles below.

When a piece of content has no team, the owner (ownerId) is the fallback and holds all the functions.

Deleting a team does not remove people

When you delete a team, member associations are dissolved, but the people remain in the organization. The courses the team owned are unlinked and revert to answering to each one's owner. Check the team's ‘Responsible for’ section before deleting.

Per-member roles (team_member_role)

Being on a team, by itself, grants no power over its courses. What grants it are the per-member roles (team_member_role), assigned individually on the team's members screen through a per-person role popover.

Each role corresponds to a function (domain) of the content. The role's name matches the function's name:

RoleFunction (domain)What it allows
editorcontentEdit the course content
financefinancePrice, campaigns, refunds, and listing (commercialization)
cohortcohortManage and moderate the cohorts and make up the tutor pool
learnerslearnersManage enrollment, progress, intake answers, and attachments

The roles are cumulative and granular: the same person can have editor, cohort, and learners, or only finance. A member with only finance opens the editor straight into the commercial sections (Offers/pricing) — the Content, Basics, Catalog, Learners, and Insights sections are hidden from the nav entirely, not shown read-only. The restricted-access screen appears only for a team member who holds none of editor/finance/cohort/learners on the owning team. Likewise, someone with only editor does not touch price, cohorts, or learner intake data.

The operation to set roles replaces the entire set of a member's roles at once (it does not increment). Unknown roles are rejected.

No one promotes themselves

Setting roles requires organization owner/admin rights — the same bar that governs team membership. This prevents a member with only editor from granting themselves the finance role. Roles change the operational scope; granting them is an administrative decision.

How access to a piece of content is resolved

Every action on a piece of content is checked against a specific function (content, finance, cohort, or learners). Resolution follows this order:

StepWho passes
ReadAny member of the organization can view
Organization owner/adminAlways have access to all functions (bypass)
Owner (ownerId)Holds all functions of the content
Member of the owning teamPasses only on the function whose role they carry
Content with no owner or teamOnly the organization owner/admin can change it

In other words: editor, finance, cohort, and learners take effect only when the person is a member of the owning team of that content. Holding the role on another team is not enough.

Owner-level actions — transferring ownership and the danger zone — sit at an even higher tier: only the owner or an organization owner/admin. No team role (editor/finance/cohort/learners) reaches this level; the team can operate the course but cannot delete or reassign it merely by being on the team.

Managing a team

From the team profile, an organization owner/admin can:

  • Create the team (unique name) and adjust its name, logo, and bio.
  • Add members from the organization's staff roster — only organization members can join; adding twice is harmless (idempotent).
  • Remove members (the person stays in the organization) or let someone leave on their own — leaving removes only that person's own association and requires no administrative rights.
  • Set the per-member roles in the popover on the members screen.
  • Consult the ‘Responsible for’ section, which lists all the courses the team owns (content.teamId).

Next steps

CohortsHow the learners of a single course are grouped and moderated.Members & rolesThe organization roster and the owner/admin rights that govern teams.Learners and enrollmentsThe other population — how students enter courses and how to track each relationship.
PreviousProgress and certificatesNextCohorts

Your privacy choices

Necessary cookies keep Cursare working. Analytics and marketing technologies are optional and stay off until you choose them. Privacy Policy.

Sign-in, security and core platform functions.

Audience measurement such as Google Analytics.

Tag Manager and campaign attribution.