Dolibarr permissions
Knot relies on native Dolibarr permissions. A user cannot bypass an ERP denial through a workflow, no matter how well the graph is built.
🔐 Knot roles
In Knot → Permissions (or Dolibarr groups depending on version):
| Typical permission | Effect |
|---|---|
| Read workflows | View definitions |
| Create / edit | Edit the canvas |
| Activate / deactivate | Go to production |
| Start manual run | Run button |
| Administer credentials | Manage encrypted secrets |
Grant least privilege: business users may edit a workflow without touching credentials.
🔐 Roles × Dolibarr actions
Each Dolibarr node checks the execution user’s rights:
| Node action | Equivalent Dolibarr right |
|---|---|
| Get / List | Read object |
| Create | Create |
| Update | Edit |
| Delete | Delete |
Example: a “sales” account without delete rights must not run a graph with invoice Delete.
🔐 Multi-entity
- Workflows and runs are scoped to the current entity.
- Multi-company admins must switch entity before editing or launching.
- Object event triggers inherit the triggering record’s entity.
See Dolibarr connector.
🔐 Technical account for Cron
For a Cron trigger, define which Dolibarr user runs the run (service account):
- dedicated role
[email protected]; - strict rights (read invoice OK, admin forbidden);
- rotated password and separate credentials from humans.
🔐 Audit
Sensitive actions (activation, export, credential access) appear in Knot audit log for admins. Correlate with run logs for incidents.