Team management

A Chaindoc workspace has one owner, any number of invited members, and a set of roles that control what each member can do. This page covers the three default roles, how to build custom ones, and how document access ties into the role system.

How workspaces are structured

Chaindoc keeps team structure deliberately flat. There are no departments, nested teams, or projects. just one workspace per owner, plus the members they've invited. If you need functional grouping (Legal, HR, Sales), layer it on top using roles and hashtags on documents rather than looking for a sub-team feature. Learn more in the SOC 2 Trust Services Criteria.

Default roles

Every workspace ships with three roles out of the box:

• Owner: full control, including billing and workspace deletion. Exactly one per workspace; ownership can be transferred.
• Admin: can manage members, roles, documents, contracts, and templates. Everything except billing and workspace deletion.
• User: can create and work with documents, contracts, and signature requests. Doesn't manage other members.

You can rename any of these, change their permission set, or leave them alone. they're editable, not hard-coded. Most teams start with the defaults and only branch out once someone clearly needs a narrower or broader role.

Custom roles

If the three defaults don't fit, create a custom role. Roles store a list of permission flags. flip on the ones you want, leave the rest off. Permissions cover the main areas of the product: documents, signature requests, contracts, templates, member management, billing, and so on.

A few recipes that teams commonly build:

• Read-only reviewer: view documents and contracts, no create/edit/send.
• Contract specialist: full contract permissions, no access to billing or member management.
• Signing-only: can be listed on signature requests but can't create documents.

Inviting members

Invite members from Dashboard → Team → Invite member. Enter an email, pick a role, and send. The recipient gets an email with a signup link; when they accept, they join the workspace with the role you chose.

• Invites are one-at-a-time. there's no CSV bulk import or domain-based auto-join at the moment.
• The invitee doesn't need an existing Chaindoc account. Signing in with the invitation link creates one automatically.
• Pending invites can be revoked or re-sent from the team page.

Granting document access by role

Actually, when you set a document's access policy you can reference team roles directly. every member holding that role inherits the permission. This scales better than listing individual emails as people join and leave.

await chaindoc.documents.updateRights(documentId, {
  accessType: 'restricted',
  accessEmails: [
    { email: 'legal-lead@company.com', level: 'write' },
  ],
  accessRoles: [
    { roleId: 2, level: 'read' }, // e.g. everyone with the 'Contract specialist' role
  ],
});

Access levels are read and write. same two tiers the documents system uses everywhere. The two lists stack: a member gets whichever level is higher between any matching email and any role they hold.

Managing members

• Change a member's role: pick a different role on the team page. The change applies immediately.
• Remove a member: they lose access to the workspace right away. Anything they already signed stays signed (the signature is tied to the document, not to their account state).
• Transfer ownership: the Owner can hand the role to another member; there's always exactly one Owner.

External signers

Actually, people outside your workspace don't need to become team members to sign documents. When you create a signature request, list any email you like. Chaindoc emails them a signing link (or opens the embedded flow if you're using the Embed SDK). They don't consume a seat and they don't get workspace access beyond the single document they're signing.

Audit trail

Chaindoc keeps an activity log per document and per contract. every upload, access change, signature event, and contract state change shows who did it and when. The log persists after a member is removed, so you can always reconstruct who touched what.

Best practices

• Start with the default Owner / Admin / User roles. Only build custom roles once you've hit a concrete gap. speculative permission-tuning is a time sink.
• Prefer accessRoles over accessEmails for ongoing access. Lists of emails rot every time someone joins or leaves; role-based grants don't.
• Review workspace membership at a regular cadence (monthly or quarterly). Access doesn't auto-expire.
• Give custom roles descriptive names ("Contract specialist", not "role-2"). The name is what you'll see in the dashboard later.
• Remember that removing a member revokes access but doesn't touch their signed documents. those remain cryptographically valid.

Troubleshooting

Invitation email not received

Check the spam folder first. Corporate filters sometimes block signup-style emails from external domains. ask the recipient's IT team to allowlist *@chaindoc.io. You can re-send the invite from the team page if needed.

Member can't access a document they should see

Open the document and check its accessType. If it's restricted, verify that the member's email or one of their roles is in the access list with the right level. If the member's role was changed recently, the new permissions apply from that point forward. but document access policies pinned to the old role still work if the role still exists.

Can't remove the workspace Owner

Actually, ownership has to be transferred first. The current Owner picks another member and hands over the role; the previous Owner becomes an Admin by default. Only then can the account be deleted or the previous owner removed.

What to do next

• Documents. access control details and how accessRoles integrates
• Signatures. external signers, signing order, and email vs embedded flows
• API documentation. endpoint reference including document rights management
• Security. API key hygiene, IP allowlists, and webhook verification
• Webhooks. real-time events for workspace and document changes