Skip to main content

Permission Actions

Permission actions are the fine-grained controls that determine what a member can do in Kazinex Workflows. Every UI button, API endpoint, and data write is gated by one or more permission actions.

There are 14 permission actions organised into four categories: Document, Workflow, Correspondence & Transmittal, and Admin.

How permission actions work​

A member has a permission action if:

  1. Their org role grants it, OR
  2. Their project role grants it, OR
  3. A permission override explicitly grants it

See Permissions Overview for the full layering model.


Document permissions​

view_documents​

What it controls: Access to the Documents tab; viewing document records, metadata, and file previews.

RoleHas by default
org_adminYes
org_managerYes
memberYes (in assigned projects)
workflow_responderNo
project_adminYes
initiatorYes
reviewerYes
viewerYes

When to override: Grant to workflow_responder if they need to view the documents they are reviewing (most setups require this).


create_documents​

What it controls: Creating new document records; uploading the first revision.

RoleHas by default
project_adminYes
initiatorYes
reviewerNo
viewerNo

When to override: Grant to reviewer if they also act as document controllers on small projects. Restrict initiator to prevent document creation if uploading should be restricted to document controllers only.


edit_documents​

What it controls: Editing document metadata (title, classification, status). Does not include uploading new revisions — that is controlled by upload_revisions.

RoleHas by default
project_adminYes
initiatorYes (own documents)
reviewerNo
viewerNo

upload_revisions​

What it controls: Uploading new file revisions to existing document records.

RoleHas by default
project_adminYes
initiatorYes
reviewerNo
viewerNo

When to override: Grant to reviewer when reviewers are expected to upload marked-up files as part of their review response.


delete_documents​

What it controls: Deleting document records. This is a destructive action — deleted documents and their revisions cannot be recovered.

RoleHas by default
project_adminYes
initiatorNo
reviewerNo
viewerNo

When to override: Rarely needed. Grant only to document controllers on projects where test documents need regular cleanup.


Workflow permissions​

create_workflows​

What it controls: Starting new workflow instances from templates.

RoleHas by default
project_adminYes
initiatorYes
reviewerNo
viewerNo

respond_to_workflows​

What it controls: Completing workflow steps (approve, reject, review with comments, delegate, etc.). This is the core action for reviewers.

RoleHas by default
project_adminYes
initiatorYes
reviewerYes
viewerNo
workflow_responderYes (only for steps assigned to them)

manage_workflows​

What it controls: Administrative workflow actions — terminating instances, reassigning steps across users, cancelling in bulk.

RoleHas by default
project_adminYes
initiatorNo
reviewerNo
viewerNo

When to override: Grant to senior initiators who need to terminate stale workflow instances without requiring project admin involvement.


Correspondence & Transmittal permissions​

send_correspondence​

What it controls: Creating and sending correspondence (RFI, NCR, TQ, etc.); composing replies.

RoleHas by default
project_adminYes
initiatorYes
reviewerNo
viewerNo

When to override: Grant to reviewer when reviewers are expected to send RFIs directly to contractors.


issue_transmittals​

What it controls: Creating and issuing transmittals to recipients.

RoleHas by default
project_adminYes
initiatorYes
reviewerNo
viewerNo

view_reports​

What it controls: Accessing the Reports tab; viewing and creating saved reports; exporting report data to Excel.

RoleHas by default
project_adminYes
initiatorYes
reviewerYes
viewerNo

When to override: Grant to viewer if clients or external observers need to see project health reports. Restrict from reviewer if report data is commercially sensitive.


Admin permissions​

manage_project_settings​

What it controls: Editing project settings — name, metadata fields, numbering schemes, review matrix rules, access control groups, distribution lists.

RoleHas by default
project_adminYes
org_adminYes
org_managerYes
initiatorNo
reviewerNo
viewerNo

manage_team​

What it controls: Inviting members to the project, changing project roles, removing members.

RoleHas by default
project_adminYes
org_adminYes

view_audit_log​

What it controls: Accessing the Audit Log and Activity Log for documents, workflows, and correspondence.

RoleHas by default
project_adminYes
org_adminYes
initiatorYes (own items)
reviewerNo
viewerNo

When to override: Grant to reviewer when the project requires peer review of audit records for quality assurance.


Permission actions quick reference​

Actionproject_admininitiatorreviewerviewer
view_documents✓✓✓✓
create_documents✓✓——
edit_documents✓✓——
upload_revisions✓✓——
delete_documents✓———
create_workflows✓✓——
respond_to_workflows✓✓✓—
manage_workflows✓———
send_correspondence✓✓——
issue_transmittals✓✓——
view_reports✓✓✓—
manage_project_settings✓———
manage_team✓———
view_audit_log✓✓*——

*Initiators can view audit logs for items they created.

For org-role permissions see Organization Roles.
For the full matrix including org roles, see Permission Actions Matrix.


What's next​