Docs
Search K

Appearance

Security & Role Access ​

Overview ​

Capture uses role-based access control (RBAC) to determine who can create, view, and act on captures. Security is configured at the template level and enforced consistently across all capture interfaces.

How Security Works ​

Role-Based Control ​

Each Capture Template defines which roles are allowed to:

  • Create captures from the template
  • View captures in their inbox
  • Approve or Reject captures (for Approve/Reject templates)

User-Role Assignment ​

Users are assigned roles in:

Console → User Management

When a user attempts to interact with Capture, the system checks:

  1. What roles does this user have?
  2. What roles does this template allow?
  3. Grant or deny access accordingly

Configuring Template Security ​

In Template Settings ​

  1. Open the Capture Template in Console
  2. Navigate to Security or Role Access section
  3. Select roles that should have access
  4. Define access level for each role:
    • Create captures
    • View captures
    • Approve/Reject

Access Levels ​

Create Access ​

Grants: Ability to create new captures from this template

Typical roles:

  • Engineers
  • Project Managers
  • Document Controllers

Use when: These users initiate the process

View Access ​

Grants: Ability to see captures in the inbox and view details

Typical roles:

  • Reviewers
  • Approvers
  • Auditors
  • Management

Use when: These users need visibility but may not create captures

Approve/Reject Access ​

Grants: Ability to complete the capture with approval decision

Only applies to: Approve/Reject submission type

Typical roles:

  • Senior Engineers
  • Project Leads
  • Quality Managers
  • Authorized Approvers

Use when: These users have authority to make approval decisions

Common Security Patterns ​

Pattern 1: Self-Service Submission ​

Template: Submit type Security:

  • All users: Create + View

Use case: Anyone can submit, everyone can see submissions Example: IT help desk requests, general inquiries

Pattern 2: Separated Creator/Reviewer ​

Template: Approve/Reject type Security:

  • Engineers: Create + View
  • Senior Engineers: View + Approve/Reject

Use case: Junior creates, senior reviews and approves Example: Engineering drawing reviews, design approvals

Pattern 3: System-Triggered Review ​

Template: Approve/Reject type Security:

  • No create access (system creates)
  • Reviewers: View + Approve/Reject

Use case: Automation creates captures, specific reviewers handle them Example: AI output validation, automated quality checks

Pattern 4: Restricted Access ​

Template: Any type Security:

  • Specific roles only: Create + View + Approve/Reject

Use case: Confidential or sensitive processes Example: Executive approvals, confidential transmittals

Best Practices ​

Start Broad, Restrict as Needed ​

Begin with broader access and narrow down based on actual requirements. Over-restriction creates friction and workarounds.

Example:

  • Phase 1: All engineers can create and view
  • Phase 2: Based on usage, restrict to project engineers only

Separate Creator and Approver Roles ​

For accountability and audit purposes, avoid allowing the same role to both create and approve captures.

Good:

  • Role A: Create
  • Role B: Approve

Risky:

  • Role C: Create + Approve (same person can approve their own work)

Document Role Requirements ​

Maintain documentation of:

  • Which roles have access to which templates
  • Business justification for access levels
  • Contact person for access requests

This helps with:

  • Onboarding new users
  • Audit compliance
  • Security reviews

Test with Multiple User Accounts ​

Before deploying, test with accounts having different role assignments:

  • Can creators create?
  • Can viewers only view?
  • Can approvers approve?
  • Are inappropriate users blocked?

Plan for Role Changes ​

Consider what happens when:

  • User roles change
  • User leaves the organization
  • Access requirements evolve

Ensure you have processes for:

  • Reviewing access periodically
  • Revoking access when roles change
  • Transferring ownership of captures

Security Enforcement Points ​

Security is enforced at all interaction points:

1. Capture Creation ​

Checked: Does user have Create access? Location: Mesh, Inbox, API

2. Inbox Display ​

Checked: Does user have View access? Result: Only shows captures user can access

3. Capture Details ​

Checked: Does user have View access? Result: Access denied if no permission

4. Review Environment ​

Checked: Does user have appropriate access level? Result: Actions available based on role

5. Approve/Reject Actions ​

Checked: Does user have Approve/Reject access? Result: Action blocked if insufficient permission

Advanced Security Scenarios ​

Scenario 1: Multiple Review Stages ​

Requirement: First-level and second-level reviewers with different permissions

Solution:

  • Use two separate templates with different role assignments
  • Chain templates via workflows
  • First template: Role A approves, triggers creation of second capture
  • Second template: Role B provides final approval

Scenario 2: Project-Specific Access ​

Requirement: Access varies by project

Solution Option 1 - Multiple Templates:

  • Create separate templates per project
  • Assign project-specific roles to each

Solution Option 2 - Dynamic Fields:

  • Single template with project field
  • Use workflows to route to appropriate reviewers
  • Still enforce base role requirements

Scenario 3: External Reviewer Access ​

Requirement: External users need review access but limited system access

Solution:

  • Create specific external reviewer role
  • Grant minimal system permissions
  • Assign to external-facing template only
  • Consider additional authentication requirements

Artifact Access vs Capture Access ​

Important distinction:

Capture Access ​

Controlled by template role configuration:

  • Who can create captures
  • Who can view captures
  • Who can approve/reject

Artifact Access ​

Controlled by Model Viewing Service Account:

  • What files reviewers can see
  • What data can be loaded in review environment
  • Vault permissions applied during review

Note: Reviewers may see artifacts in Capture that they couldn't normally access in Vault. This is intentional—the service account provides the necessary access for review purposes.

Security Audit & Compliance ​

Audit Trail ​

Capture provides complete audit trail:

  • Who created each capture
  • Who viewed each capture
  • Who approved/rejected
  • When all actions occurred
  • What changes were made

Compliance Features ​

For regulated industries:

  • Role-based separation of duties
  • Complete action history
  • Documented approvals
  • Timestamp tracking
  • User accountability

Reporting ​

Use Capture data for:

  • Access reviews
  • Usage audits
  • Role effectiveness analysis
  • Security compliance reporting

Troubleshooting Security Issues ​

User Can't See Template ​

Check:

  • Is user assigned to appropriate role?
  • Is role granted access to template?
  • Is template enabled?
  • Is user logged in correctly?

User Can't Create Capture ​

Check:

  • Does user have Create access?
  • Is template available in Mesh (if creating from Mesh)?
  • Are there other restrictions (project-specific, etc.)?

User Can't Approve Capture ​

Check:

  • Is template configured as Approve/Reject type?
  • Does user have Approve/Reject access?
  • Is capture in correct state for approval?
  • Has capture already been approved/rejected?

User Sees Captures They Shouldn't ​

Check:

  • Role assignments—too broad?
  • Template security settings
  • Inherited permissions from groups
  • System configuration

Next Steps ​

Continue with configuration topics:

Tentech