Skip to content

29. Team, Roles & Permissions

Team settings control who can read, edit, publish, configure and administer a Klariton organization.

Open Settings -> Team.

The Team tab contains:

  • invite form,
  • pending invitations,
  • current members,
  • role selector per member,
  • permission matrix.
RoleMeaning
OwnerFull control. Owners can change billing, grant or revoke owner access, manage sensitive settings and delete the organization where supported.
AdminOperational editor. Admins can manage content, touchpoints, material, settings and team operations, but cannot grant or revoke owner access.
MemberRead-only or limited contributor role depending on the current app surface. Treat Member as non-admin for sensitive operations.

Assumption: if your workspace has custom role gates, the in-app permission matrix is the source of truth.

  1. Open Settings -> Team.
  2. Enter the email address.
  3. Choose the intended role.
  4. Create the invitation.

Pending invitations appear in the Team tab until accepted, expired or revoked. The current app text mentions that magic-link email delivery can be environment-dependent. If email delivery is not enabled in your environment, the invite record still exists but delivery may require a guided operational step.

For each pending invitation you can:

  • see the email address,
  • see the intended role,
  • see whether the invitation is waiting or expired,
  • resend,
  • revoke.

Use revoke when an invitation was sent to the wrong address or should no longer grant access.

Admins and owners can remove members where the role rules allow it. Owners are protected:

  • at least one owner must remain in the organization,
  • users cannot downgrade their own role,
  • users cannot remove themselves through the normal team-management action.

Best practice: keep at least two trusted owner/admin users before production launch, so billing, API keys and emergency settings are not blocked by one unavailable account.

The in-app role matrix explains which role can perform each action. Current areas include:

  • managing touchpoints and material,
  • using the FAQ wizard,
  • reading settings,
  • changing organization, branding and integration settings,
  • inviting and removing team members,
  • changing other members’ roles,
  • granting or revoking owner access,
  • switching billing plans,
  • changing provider and token limits,
  • deleting the organization.

The matrix is more authoritative than a static document because permission checks can evolve with plan tiers and environment setup.

  • Use Owner for legal, billing, API key and security responsibility.
  • Use Admin for people who create, publish or operate content.
  • Use Member for read-only review, reporting and collaboration.
  • Review pending invites before go-live.
  • Remove users who leave the team.
  • Rotate API keys when a person with access to server-side integrations leaves.
  • Re-run embed and API checks after changing ownership of an integration.

Check:

  • your own role is Owner or Admin,
  • the email address is valid,
  • there is not already a pending invite for the address,
  • the user is not already a member,
  • your workspace has not reached its team-seat limit.

Only owners can grant the Owner role. Ask an existing owner to make the change.

This is intentional. Add another owner first, then remove or downgrade the original owner.

This is expected for Member. Promote to Admin if the person needs operational edit rights.