Members and permissions
Invite teammates, choose what they can do, and manage roles and pending invitations.
Every Clog workspace is shared work. Members are people who can sign in and use the workspace, and permissions decide what each member can touch. This page covers inviting new members, the permission vocabulary, the difference between an owner and a member, and how to revoke or change someone's access.
You need members:read to see the Members page, and members:write to invite, edit permissions, or remove. The workspace owner has both implicitly.
The Members page
Open Members from the workspace sidebar. The page has two tabs:
- Members — everyone who currently has a
Membershipon this workspace. Search by name or email. - Pending invites — invitations that were sent but not yet accepted (or that were revoked / expired).
The Invite member button at the top right opens the invitation dialog.
Invite a new member
Click Invite member. Fill in:
- Email — the email of the person you want to invite. They don't need a Clog account yet; they'll create one when they accept.
- Permissions — check the boxes for the scopes they should have. See the permission vocabulary below for what each one grants.
Click Send invite. Clog generates a one-time accept URL and shows it on a confirmation screen titled Invitation ready:
https://your-clog-dashboard.example.com/invitations/accept?token=abc123…Clog does not send the email for you in v1. You need to send the accept URL to the invitee yourself — paste it into Slack, email, or however you usually share access. Clog shows the URL exactly once, on this confirmation screen. There's no way to recover it later, so if you close the dialog without copying, you'll need to revoke the invitation and create a new one.
Use the Copy button on the dialog to copy the URL, then send it to the invitee. They click it, sign in (or sign up first), and they're added as a member with the permissions you picked.
Pending invites tab
While an invite is waiting to be accepted, it shows on the Pending invites tab with its status:
- Pending — sent but not yet accepted. Will auto-expire 7 days after creation.
- Accepted — the invitee accepted; they should now be on the Members tab.
- Revoked — you cancelled the invitation.
- Expired — the 7-day window elapsed without acceptance.
You can revoke a pending invitation from this tab if you sent it by mistake or to the wrong address. A revoked invitation's URL stops working immediately.
The permission vocabulary
Permissions are explicit grants — a fixed, closed list. A member can do something only if they hold the matching permission (or if they're the owner, which carries everything implicitly).
| Scope | What :read grants | What :write grants |
|---|---|---|
| Posts | View posts in the workspace, including drafts. | Create, edit, publish, archive, and delete posts. |
| Pages | View pages. | Create, edit, publish, and delete pages. |
| Categories | View the category tree. | Create, rename, reparent, and delete categories. |
| Tags | View tags. | Create, rename, and delete tags. |
| Authors | View author profiles. | Create, edit, and delete author personas. |
| Media | View the media library. | Upload, edit metadata (alt / caption), and delete media files. |
| Members | View the Members and Pending invites tabs. | Invite, change permissions, and remove members. |
| API keys | View the API keys list. | Create, edit (name / expiry), reveal, and revoke API keys. |
| Settings | View the workspace settings. | Edit general settings, branding, and SEO defaults. |
| SEO | View per-entity SEO metadata. | Edit the SEO meta group (title, description, canonicalUrl, focus keyword, robots, OG, Twitter) on every entity. |
A few special rules
seo:*is cross-cutting. A member withseo:writecan edit SEO metadata on every entity — posts, pages, categories, tags, authors — without holding each entity's:writescope. This lets an SEO specialist tune metadata without being given content-edit rights. They can't change the post body or itsstructuredDatathough — those are content, gated onposts:write.- Some workspace settings require two permissions. Editing the workspace-level SEO defaults requires both
settings:writeandseo:write— see SEO. - Reading is more lenient. A member with either
settings:readorseo:readcan see workspace SEO defaults; reading the redirects / link-health views allows eithersettings:readorseo:read.
For the full per-endpoint matrix, see Reference → Permissions.
Edit a member's permissions
Click a member's row on the Members tab, then Edit permissions. Check or uncheck scopes and click Save. The change is wholesale — what you submit is exactly what the member ends up with — so review the full list before saving.
Permission changes apply immediately. If the member is in the middle of editing a post when you remove posts:write, their next save will fail with a permission error.
You cannot edit the owner's permissions. The owner has every permission implicitly; their permission list is empty in the database, and the Edit permissions dialog is disabled for that row. To strip an owner's power, transfer ownership first (Settings → Danger zone), then edit them like any other member.
Remove a member
Click a member's row, then Remove member. The confirmation dialog warns you of the side-effects. Confirm to proceed.
What happens:
- The
Membershipis hard-deleted. - The user loses access to this workspace immediately.
- Every API key they created on this workspace stops working immediately, even though the
ApiKeyrows still exist. The keys carry the membership's permissions at request time — no membership, no permissions, no access.
For this reason, if a removed member was running an integration with an API key, rotate the key first: create a new key from a teammate who's staying, swap it into the integration, then remove the leaving member. Better still, run production integrations from a dedicated service-user membership (a separate Clog account) so nobody leaving ever breaks production.
You can't remove the workspace owner via this button — to remove an owner, transfer ownership to someone else first (Settings → Danger zone).
Roles vs permissions — a recap
| Role | Granted to | What it means |
|---|---|---|
| Owner | Exactly one person per workspace. The workspace's creator by default; can be transferred. | Implicit holder of every permission. Sole holder of owner-only actions (transfer ownership, delete the workspace, edit-own-permissions which is always blocked). |
| Member | Everyone else. | Holds only the permissions on their grant list. |
The owner is not "a member with all permissions ticked." The dashboard treats them differently — their permission list is greyed out, and the Remove member action is unavailable on their row. To change them, transfer ownership first.
Common scenarios
| Scenario | What to grant |
|---|---|
| Author who only writes posts and edits images | posts:read, posts:write, media:read, media:write, plus categories:read, tags:read, authors:read for tagging and bylines. |
| Author + their own SEO | The above plus seo:read, seo:write. |
| SEO specialist (across all content, no content edits) | posts:read, pages:read, categories:read, tags:read, authors:read, plus seo:read, seo:write. |
| Integrator who manages keys but doesn't write content | api-keys:read, api-keys:write. Optionally posts:read etc. so they can sanity-check what the key sees. |
| Site admin (everything except ownership) | Tick every box. They can still never delete the workspace or transfer ownership — those are owner-only. |
| Read-only viewer | Every :read scope, no :write scopes. |
Related
- Workspaces — including how to transfer ownership.
- API keys — keys inherit the creator's membership permissions live, so member changes ripple into key behaviour.
- Reference → Permissions — the per-endpoint permission matrix.