User & Team Management

Three options determine who uses the editor and what identity powers the collaboration features: currentUser names the active user for attribution, teamUsers lists who can be mentioned in comments, and role controls block and section locking. They matter most together with comments; locking works without them.

currentUser

The currentUser object identifies the active user for collaboration features. All three properties are required, and userId must be a string, even though authorize.userId also accepts a number:

• userId (string): unique user identifier
• name (string): display name
• profilePhotoUrl (string): URL to the user's avatar image

{
  currentUser: {
    userId: "user-123",
    name: "John Doe",
    profilePhotoUrl: "https://example.com/avatars/john.jpg"
  }
}

The editor uses this identity to attribute comments, track which comments the user has read, and send current_user_id with comment and autosave requests. Without currentUser, comments still render, but every request sends an empty current_user_id and read/unread tracking does not work. Always set currentUser when comments are enabled.

teamUsers

The teamUsers array defines the team members available for @mentions in comments. Each entry uses the same shape as currentUser: userId (string, required), name (required), profilePhotoUrl (required).

{
  teamUsers: [
    {
      userId: "user-123",
      name: "John Doe",
      profilePhotoUrl: "https://example.com/avatars/john.jpg"
    },
    {
      userId: "user-456",
      name: "Jane Smith",
      profilePhotoUrl: "https://example.com/avatars/jane.jpg"
    }
  ]
}

The editor offers these users in the mention suggestion list and displays their names and photos on comments; without the option, the mention list is empty. Including the current user in the list is harmless; the editor filters them out of their own mention suggestions automatically.

role

The role option ("manager" | "editor" | "reader", optional) controls block and section locking; it is not a general access-control mechanism. When it is not set, role-based permissions are disabled entirely and all locking controls are available.

Role	Can lock/unlock blocks and sections	Can edit locked blocks and sections
manager	Yes	Yes
editor	No	Yes
reader	No	No

{
  role: "editor"
}

WARNING

role: "reader" does not make the editor read-only. A reader can still edit, move, delete, and save any block that is not explicitly locked. For genuine view-only access, do not rely on role; render a preview of the exported HTML instead, or combine role: "reader" with locked sections and hidden top-bar controls.

Hiding the settings tab or top-bar controls is a separate concern, handled by the hideSettingsTab and hideTopbarControls options.

Common setups

Team collaboration

Multiple users comment on the same template: teamUsers powers mentions, enableComments enables in-editor discussion, and the manager role keeps locking in this user's hands.

{
  currentUser: {
    userId: "user-123",
    name: "John Doe",
    profilePhotoUrl: "https://example.com/avatars/john.jpg"
  },
  teamUsers: [
    { userId: "user-456", name: "Jane Smith", profilePhotoUrl: "https://example.com/avatars/jane.jpg" },
    { userId: "user-789", name: "Bob Johnson", profilePhotoUrl: "https://example.com/avatars/bob.jpg" }
  ],
  role: "manager",
  enableComments: true
}

Reduced-chrome review setup

A setup for reviewers who should mainly leave feedback. It prevents the reviewer from locking content or editing locked content, enables comments, and hides the save and undo/redo controls. Unlocked content remains editable; this reduces chrome, it does not enforce read-only access.

{
  currentUser: {
    userId: "client-001",
    name: "Client Name",
    profilePhotoUrl: "https://example.com/avatars/client.jpg"
  },
  role: "reader",
  enableComments: true,
  hideTopbarControls: ["save", "saveAndClose", "undoRedo"]
}