How to set up a document approval workflow with team roles in Chaindoc

A document approval workflow is the path a contract takes from draft to signature: who can open it, who has to approve it, in what order, and what record is left behind. In Chaindoc that path rests on two settings. Roles decide who sees and edits a document inside your team. On the Business plan, an approval route fixes the order in which people approve and sign. Everything else, from the first invite to the audit trail, hangs off those two. This guide shows how to set them up with Chaindoc's team management, what each plan includes, and where bigger tools such as SharePoint go further.

Most problems in a document approval workflow start before the approval. A draft lands on a shared drive, the link travels, and by the time legal opens it, five people have read it and two have edited it.

That's the default in a lot of tools. In Google Drive, anyone you make an editor can share the file and change its permissions unless the owner switches that off, and access you give on a folder flows down to every file inside it (Google Drive Help). Handy for a slide deck. Less handy for a supplier contract with your margins in it.

Document access control in Chaindoc works on two levels, plus a third for developers:

• Workspace. Each user has a personal workspace, and team plans add a shared one. The two don't overlap, so a draft kept in your personal space stays out of the team's view. Team contracts belong in the shared workspace.
• Role. Inside the shared workspace, what a person can do with a document (view, edit, approve, sign) follows the role they hold, not a link someone forwarded.
• Through the Chaindoc API, which needs the Business plan, each document carries an access type: private, public or restricted. A restricted document lists by email the people who may open it, with a level such as read.

Our rule of thumb: give the draft to the people who must read it before approval, not to everyone who might like to. You can widen access after signing. Pulling it back after someone has downloaded the file doesn't work.

One honest limit: files travel over TLS, but there's no end-to-end encryption, so Chaindoc's servers can read what they process. Inside your company, roles keep a contract in front of the right people.

Role-based access control (RBAC) attaches permissions to a role and then gives people the role. NIST's glossary describes it as access control based on user roles, a role being a collection of access authorizations. When someone changes job, you change one role and their access follows.

Chaindoc team management ships with four built-in roles, the access half of any document approval workflow:

• Owner: full rights over documents plus the team's admin controls. Usually the founder, or whoever holds the budget.
• Admin: manages users and keeps an eye on workflows. An ops lead or office manager, typically.
• Member: reads and edits within the permissions the role allows. Most of your team sits here.
• Accounter: sees the financial and analytical side of documents. Think bookkeeper or outside accountant.

Each built-in role can be adjusted, and you can add as many custom roles as you need, with any mix of permissions. Two we see often: a legal reviewer who can view and approve contracts but doesn't send them, and a sales role that drafts and sends but never approves. Role changes made in the Roles tab apply right away to every active workflow.

Is four roles enough? For a team of five to fifty, usually yes. Enterprise suites offer longer menus. In our experience small teams rarely need them, and every extra role is one more thing somebody has to review each quarter.

The four eyes principle says two people have to be involved before something important counts: a payment, a change to a record, a contract. Auditors call the wider idea separation of duties. NIST's definition is blunt: no user should get enough privileges to misuse the system on their own (NIST CSRC glossary). The same entry splits it in two. Static separation means conflicting roles are never given to one person. Dynamic separation applies at the moment of action, the two-person rule being the classic example.

In a contract team, that translates into three habits:

1. 1.
   The person who drafts a contract isn't the person who approves it.
2. 2.
   Big contracts have more than one name between draft and signature.
3. 3.
   Finance can see what a contract is worth without being able to rewrite it.

None of this needs special software. It needs someone to decide, and a tool that remembers the decision.

Least privilege, in plain terms

NIST SP 800-12 puts least privilege as restricting each user's access to the minimum needed for their tasks. In Chaindoc that means Member is the default, Admin is rare, and Owner belongs to one or two people. Honestly, most small teams get this backwards: the first five people all become Admins because it was quicker, and nobody revisits it.

Where the approval route fits in a document approval workflow

Roles cover the static half. The route covers the dynamic half. A normal Chaindoc signature request invites every recipient at once, so whoever opens it first signs first. On the Business plan, an approval route fixes the sequence instead: the next person gets the document only after the one before has acted. Legal, then the finance lead, then the managing director. If your policy says contracts above a certain value need the CFO, write that rule down and have whoever sends the contract pick the matching route.

Roles and the shared workspace, the access side of a document approval workflow, start on Team. The fixed order needs Business, and so does API access. The figures below come from Chaindoc's plans as published on September 20, 2026; the pricing page carries the current ones. If you're comparing approval workflow software on price, count seats too: each extra team member is a €19 monthly add-on on both team plans.

One number is missing on purpose. The Team plan's monthly signature allowance shows one figure on the plan card and another in the plan's configuration, so we've left it to the pricing page rather than print the wrong one.

A document approval workflow only helps if you can show later who approved what. Chaindoc keeps the evidence in two places, and they do different jobs.

The audit trail is the application's own event log for the document. Its entries are chained by hashes, so a missing or altered entry breaks the chain. You can export it as an audit trail PDF, and there's a separate verification report PDF for the signed file. If you used an identity check, its result lands in the audit trail too.

The blockchain records two moments: the version's hash when you publish, and each signer's proof when signing completes. That hash is what a later verification checks the file against.

In practice, most disagreements never get as far as the chain. They're settled by a readable record of who did what, which is why the PDF export matters more day to day. For what an auditor or a court tends to ask for, see how an e-signature record holds up in an audit.

Plenty of teams already run a document approval workflow in a tool they own, or think they do. Here's what the three most common ones cover.

SharePoint and Power Automate

A SharePoint approval workflow is usually a Power Automate flow. Microsoft's tutorial builds one around the "Start and wait for an approval" action, and approvers answer from their inbox, the approvals center or the mobile app (Microsoft Learn). Sequential and parallel approvals each get their own guide, and guests from outside the company can approve through Microsoft Entra. The catch is that you build and maintain the flow yourself, and the tutorial says plainly that security is outside its scope.

DocuSign

People searching for DocuSign roles and permissions usually land on its three default permission profiles: DS Admin, DS Sender and DS Viewer. DocuSign also documents an internal approval workflow in its support center, so a DocuSign approval workflow is a configuration job inside an account you may already pay for.

Google Drive

Google Drive sharing permissions come in three roles: Viewer, Commenter and Editor. They decide who can open, comment on and change a file. Who approves it and who signs it is a separate question you'll answer elsewhere.

Where they're ahead: Power Automate can branch an approval on almost any condition and run it across SharePoint, Dynamics 365 or Salesforce, and Microsoft 365 approvers use the company accounts they already sign in with. Chaindoc has no single sign-on or SCIM provisioning. People sign in with a password or a Google, GitHub or Apple account, and you remove leavers by hand. What Chaindoc puts in one place is the access, the order, the signature and the record for the same contract.

No. In the US, ESIGN says a contract can't be denied legal effect just because an electronic signature or record was used to form it (15 U.S.C. § 7001). In the EU, Article 25(1) of eIDAS says the same of electronic signatures before a court. Your document approval workflow is governance, not part of how the contract is formed. What it changes is your position if someone later claims the contract was signed without authority.

Access shows up in law twice, though. ESIGN's retention rule in § 7001(d)(1) is met by an electronic record that stays accurate and remains accessible to everyone entitled to access it, for as long as the law requires. So access control cuts both ways: keep out the people who shouldn't see a contract, and don't lock out the ones who must. For the time limits, see how long to keep signed contracts.

If your contracts hold personal data, GDPR Article 25(2) asks that by default it isn't made accessible to an indefinite number of people, and Article 32(4) that anyone with access acts only on the controller's instructions. A link anyone can open is hard to square with either. This is general information, not legal advice for your company.

The same five failures turn up again and again:

• Everyone is an Admin. It happened during setup and stuck. Bring it down to one or two people.
• The contract approval workflow lives in someone's head. When that person is away, contracts either stall or go out unapproved. Write the routes down and name them after contract types.
• Approvals happen in email. A "looks good" in a thread isn't in the audit trail, and six months later nobody can find it.
• Leavers keep access. Without automatic provisioning, offboarding needs a checklist line: remove from Chaindoc.
• The approved version isn't the signed one. Edit after approval and you need a new published version and a fresh pass through the route. The old version's hash is already on chain, which is exactly what you want when someone asks what changed.

Fix those five and a document approval workflow in Chaindoc mostly looks after itself. Roles keep drafts private, the route keeps the order, and the record answers the questions later.