Access Control - Clearpoint Systems Docs

Role-Based Access Control (RBAC) in Clearpoint Systems Technology allows you to define exactly who can do what across your organization. Enterprise plans include advanced RBAC features like custom roles, approval workflows, and IP restrictions.

Permission Model

Clearpoint uses a hierarchical permission model:

Organization
├── Organization-level permissions
│   ├── Billing
│   ├── SSO configuration
│   └── User management
│
├── Department-level permissions
│   ├── Department settings
│   └── Department membership
│
└── Integration-level permissions
    ├── Workflow configuration
    ├── Data source access
    ├── Report generation
    └── Audit log access

Permissions can be granted at any level and cascade down.

Built-in Roles

Clearpoint includes four built-in roles:

Role	Description
System Administrator	Full control, including billing and organization management
Operations Manager	Manage integrations, workflows, and department members
Data Analyst	Access data and create reports
Compliance Officer	View audit logs and compliance documentation
Viewer	Read-only access

See User Management for the full permission matrix.

Custom Roles

Enterprise plans can create custom roles tailored to your organization:

Creating a Custom Role

Go to Settings → Roles → Create Role
Name your role (e.g., “Integration Specialist”, “Report Builder”)
Select permissions from the available list
Save the role

Example: Integration Specialist Role

{
  "name": "Integration Specialist",
  "description": "Can configure integrations but not manage users",
  "permissions": [
    "integrations:read",
    "integrations:create",
    "integrations:update",
    "workflows:read",
    "workflows:create",
    "reports:read"
  ]
}

This role can:

View and configure system integrations
Create and manage workflows
View reports and analytics

This role cannot:

Manage user accounts
Access billing information
Modify system settings

Example: Compliance Auditor Role

{
  "name": "Compliance Auditor",
  "description": "Full audit access without configuration permissions",
  "permissions": [
    "audit:read",
    "reports:read",
    "data_lineage:read",
    "compliance:read",
    "integrations:read"
  ]
}

Permission Reference

Organization Permissions

Permission	Description
`org:read`	View organization settings
`org:update`	Modify organization settings
`billing:read`	View billing information
`billing:manage`	Manage subscription and payment
`users:read`	View organization users
`users:invite`	Invite new users
`users:remove`	Remove users
`users:update-role`	Change user roles
`sso:manage`	Configure SSO settings
`audit:read`	View audit logs

Integration Permissions

Permission	Description
`integrations:read`	View integration details
`integrations:create`	Create new integrations
`integrations:update`	Modify integration settings
`integrations:delete`	Delete integrations
`workflows:read`	View workflow configurations
`workflows:create`	Create new workflows
`workflows:update`	Modify workflow settings
`workflows:execute`	Execute workflows manually
`data_sources:read`	View data source schemas
`data_sources:update`	Modify data source mappings

Reporting Permissions

Permission	Description
`reports:read`	View existing reports
`reports:create`	Create new reports
`reports:export`	Export report data
`analytics:read`	View analytics dashboards
`data_lineage:read`	View data lineage information
`compliance:read`	View compliance documentation

Department-Specific Permissions

Restrict actions to specific departments:

{
  "name": "Finance Data Analyst",
  "permissions": [
    "integrations:read",
    "workflows:read",
    "reports:create",
    "reports:export"
  ],
  "restrictions": {
    "departments": ["finance"],
    "data_sources": ["financial_data", "transactions"]
  }
}

This user can access finance-related data and workflows but not other departments.

Approval Workflows

Require approval for sensitive actions:

Configuring Approval Workflows

Go to Settings → Security → Approval Workflows
Click Create Workflow
Configure the workflow:

{
  "name": "Integration Configuration Approval",
  "trigger": "integrations:update",
  "approvers": {
    "type": "role",
    "roles": ["operations_manager", "system_administrator"],
    "required": 1
  },
  "timeout": "4h",
  "autoReject": true
}

Approval Flow

User initiates integration configuration change
Change enters “Pending Approval” state
Approvers receive notification
Approver reviews and approves/rejects
If approved, change is applied
If rejected or timeout, change is cancelled

Approval via API

# Request configuration change (enters pending state)
POST /api/v1/integrations/sap_erp/config
{
  "sync_frequency": "30m",
  "approval_required": true
}

# Approver approves
POST /api/v1/approvals/{approval_id}/approve
{
  "comment": "Reviewed configuration changes"
}

# Or rejects with reason
POST /api/v1/approvals/{approval_id}/reject
{
  "reason": "Sync frequency too aggressive for production"
}

IP Restrictions

Limit access based on IP address:

Organization-Wide IP Allowlist

{
  "ipAllowlist": {
    "enabled": true,
    "addresses": [
      "203.0.113.0/24",
      "198.51.100.50"
    ],
    "enforceFor": ["dashboard", "api", "cli"]
  }
}

Integration-Specific Restrictions

{
  "integration": "sap_erp",
  "ipAllowlist": {
    "configuration": ["203.0.113.0/24"],
    "monitoring": ["0.0.0.0/0"]
  }
}

Bypass for System Services

Allow monitoring and backup systems to bypass IP restrictions:

# Create a service token with IP bypass
POST /api/v1/tokens
{
  "name": "Monitoring Service",
  "scope": "read",
  "bypass_ip": true
}

Time-Based Access

Grant temporary elevated access:

# Grant admin access for 4 hours
POST /api/v1/users/{user_id}/access
{
  "role": "system_administrator",
  "duration": "4h",
  "reason": "Production incident response"
}

Time-based access:

Automatically expires after the specified duration
Is logged in the audit trail
Can be revoked early if needed

Audit Trail

All RBAC changes are logged:

GET /api/v1/audit-logs?filter=rbac

{
  "logs": [
    {
      "timestamp": "2024-01-15T10:30:00Z",
      "user": "admin@company.com",
      "action": "role.create",
      "details": "Integration Specialist",
      "ip_address": "192.168.1.100"
    },
    {
      "timestamp": "2024-01-15T10:25:00Z",
      "user": "admin@company.com",
      "action": "user.role-change",
      "details": "john@company.com → data_analyst",
      "ip_address": "192.168.1.100"
    }
  ]
}

Best Practices

Principle of least privilege — Start with minimal permissions and add as needed
Use custom roles — Create roles that match your organizational structure
Require approval for production changes — Add a human checkpoint for critical modifications
Enable IP restrictions — Limit access to known networks
Review permissions regularly — Audit who has access to what
Use time-based access — Grant temporary elevated access instead of permanent

Troubleshooting

”Permission denied” errors

Check the user’s effective permissions:

GET /api/v1/users/{user_id}/permissions

Approval workflow not triggering

Verify the workflow is enabled and matches the action:

GET /api/v1/approval-workflows
POST /api/v1/approval-workflows/test
{
  "action": "integrations:update",
  "user": "user@company.com"
}

IP restriction blocking legitimate access

Check if the IP is in the allowlist:

GET /api/v1/security/ip-check?address=203.0.113.50

Add the IP if needed:

POST /api/v1/security/ip-allowlist
{
  "address": "203.0.113.50",
  "reason": "New office location"
}