Take the free assessment

Documentation

Account Permissions

Authentication
Updated Nov 26, 2025

Roles

ChangeBreeze implements distinct roles, each with specific permissions designed around ITIL change management principles:

Change Creator

Purpose: Users who initiate and create change requests

Permissions:

  • ✅ View changes
  • ✅ Create new changes
  • ✅ Edit own changes (before approval)
  • ❌ Cannot approve changes (separation of duties)
  • ❌ Cannot manage users or templates

Best For:

  • Technical staff
  • System administrators
  • Project managers
  • Anyone who needs to submit change requests

ITIL Principle: Ensures changes are properly documented by those closest to the technical work while maintaining separation between creators and approvers.

Technical Approver

Purpose: Provides technical review and approval for changes

Permissions:

  • ✅ View changes
  • ✅ Approve technical aspects of changes
  • ✅ Review technical implementation plans
  • ✅ Create new changes
  • ❌ Cannot provide operational approval
  • ❌ Cannot manage users

Best For:

  • Senior technical staff
  • Solution architects
  • Technical subject matter experts

ITIL Principle: Technical approval ensures changes are technically sound, feasible, and properly planned before implementation.

Operational Approver

Purpose: Provides operational/business impact approval

Permissions:

  • ✅ View changes
  • ✅ Approve operational aspects of changes
  • ✅ Assess business impact
  • ✅ Create new changes
  • ❌ Cannot manage users

Best For:

  • Operations managers
  • Service delivery managers
  • Business stakeholders
  • Compliance officers

ITIL Principle: Operational approval ensures changes align with business needs, timing requirements, and service level agreements.

Company Admin

Purpose: Organisational user accounts with Company Admin permissions have full administrative control within their company. In multitenant environments, these users also inherit full administrative rights across all sub-companies, with permissions cascading automatically from the parent organisation.

For customer users within a sub-company who have Company Admin permissions, their access is limited to the administrative settings of that specific sub-company only.

Permissions:

  • ✅ View changes
  • ✅ Create changes
  • ✅ Edit own changes
  • ✅ Approve technical changes
  • ✅ Approve operational changes
  • ✅ Manage users within the company
  • ✅ Manage change templates

Best For:

  • IT managers
  • Change managers
  • Company administrators
  • Department heads

ITIL Principle: Company admins have full control to manage change processes within their scope, including user management and template creation.

Read-Only Viewer

Purpose: Visibility without modification capabilities

Permissions:

  • ✅ View changes and their details
  • ❌ Cannot create changes
  • ❌ Cannot edit changes
  • ❌ Cannot approve changes
  • ❌ Cannot manage users or templates

Best For:

  • Executive stakeholders
  • Auditors
  • External consultants
  • Team members who need awareness without modification rights

ITIL Principle: Provides transparency and oversight while protecting the integrity of change records.

Common Role Assignment Scenarios

Scenario 1: New MSP Technician
Recommended Role: Change Creator

Can submit changes for clients
Cannot approve own work (maintains accountability)

Scenario 2: Senior MSP Engineer
Recommended Roles: Change Creator + Technical Approver

Can create and technically approve changes
Should not approve their own submissions

Scenario 3: MSP Operations Manager
Recommended Role: Company Admin

Full oversight of change processes
Can manage users and approve all change types

Scenario 4: Client IT Manager
Recommended Role: Change Creator (or Viewer if read-only)

Can submit changes affecting their company
MSP handles approvals unless otherwise agreed

Scenario 5: Auditor/Compliance Officer
Recommended Role: Read-Only Viewer

Complete visibility for compliance
Cannot modify change records

Previous

No previous article

Next

Azure - Enable signed assertions

Related Articles

Authentication

Azure - Enable signed assertions

If you see the following warning it means you have certificate signing disabled in ChangeBreeze and in your SAML configuration in Entra / Azure. The Verification Certificates section must be set to required in Microsoft Entra under you Enterprise app along with the SP certificate uploaded.
Authentication

Enforcing Multi-Factor Authentication for All Users

Enforcing MFA protects your organization by adding a layer of security beyond passwords. Admins can enable it in ChangeBreeze’s Organization settings. SAML-authenticated users may already have MFA via their identity provider and can be excluded from additional enforcement.
Authentication

How to enable MFA for local accounts

Steps to Enable Multi-Factor Authentication (MFA) for Enhanced Account Security
Authentication

How to setup SAML authentication with Microsoft Entra / Azure

This guide walks you through setting up SAML Single Sign-On (SSO) for ChangeBreeze with Entra ID, allowing users to log in automatically using their company credentials. By integrating with your existing identity provider (such as Entra ID), ChangeBreeze can provide a secure and seamless login experience without the need for separate passwords. Once complete, users can access ChangeBreeze instantly through their organization’s sign-in portal, improving both security and convenience.
Authentication

Managing Global User Permissions for Organizational Accounts

In a multitenant system with organizational user accounts, permissions are global and apply to all sub-companies within the organization. Any permissions set at the organizational level automatically cascade to the sub-companies. User accounts can have roles set during their creation, with the option to edit these roles later from the User Management page. Editing a user's role will update their role across all companies within the organization, override any custom role settings at the company level, and take effect immediately.