Skip to main content

Role Permissions Overview

What are Role Permissions?​

Role Permissions control what users can view, create, edit, or delete across all modules in Bizconnekt. Instead of managing permissions for each user individually, you assign permissions to department roles (L1, L2, L3), and users inherit permissions based on their role assignment.


Who Uses This?​

Tenant Administrators

Configure system-wide access control policies

Business Owners

Define what each role can do across the platform

Department Heads

Review permissions for their team's roles

Security Officers

Ensure data access complies with policies


Key Features​

Permission Management​

Department-level editing allows you to configure all three roles (L1, L2, L3) in one department at once

Module-wise control provides granular access to Items, Purchase, Sales, Finance, and Reports

Two permission types - View (read-only) and Add/Edit (full access) for each module

Automatic enforcement ensures pages appear or disappear based on role permissions instantly

Smart Dependencies​

Permission validation prevents creating transactions without required master data access

Dependency rules automatically enforced (e.g., Purchase Orders require Item and Supplier view access)

Visual matrix shows all permissions at a glance with checkmarks for clarity

Role hierarchy supports different permission levels (L1, L2, L3) within same department


How It Works​

Permission Flow

  1. Administrator configures role permissions for department roles (L1, L2, L3)
  2. Users are assigned to specific department roles through Manage Users
  3. System checks permissions when user logs in and navigates
  4. Pages and features appear or disappear based on assigned role permissions
  5. Real-time enforcement ensures users only access permitted modules

Permission Structure​

Entity Groups and Modules​

Permissions are organized into logical groups:

Item Management

  • Item (product/service master data)
  • Bill of Material (product composition)

Purchase Operations

  • Supplier (vendor master data)
  • Purchase Request (internal purchase requisitions)
  • Purchase Order (orders to suppliers)
  • Bill (supplier invoices)
  • GRN (Goods Receipt Notes)
  • Payment Made (supplier payments)
  • Expense (expense tracking)

Sales Operations

  • Customer (customer master data)
  • Quotation (sales quotes)
  • Sales Order (customer orders)
  • Invoice (customer invoices)
  • Delivery Challan (delivery notes)
  • Payment Received (customer payments)

Finance Operations

  • Credit Note (sales returns/adjustments)
  • Debit Note (purchase returns/adjustments)
  • Journal (manual journal entries)
  • Audit (audit logs access)

Reports

  • Business Report (Balance Sheet, P&L, AR, AP)
  • Inventory Report (stock reports)
  • Sales Report (sales analytics)
  • Purchase Report (purchase analytics)
  • Tax Report (GST and tax reports)

Permission Types​

PermissionWhat User Can DoWhat User Cannot Do
ViewSee records, open details, export data, view reportsCreate new records, edit existing records, delete records
Add/EditCreate new records, modify existing records, all View permissionsDelete records (requires separate admin permission)
No AccessNothing - module completely hidden from userCannot see or access the module at all

Permission Dependencies​

Critical Dependencies to Remember

Some modules require view access to master data before Add/Edit permission works:

Purchase Orders require:

  • View access to Items (to select products)
  • View access to Suppliers (to select vendors)

Sales Orders require:

  • View access to Items (to select products)
  • View access to Customers (to select buyers)

Invoices require:

  • View access to Sales Orders (to convert orders)
  • View access to Customers (to select buyers)

Bills require:

  • View access to Purchase Orders (to convert orders)
  • View access to Suppliers (to select vendors)

Payment Made/Received require:

  • View access to Bills/Invoices (to link payments)

The system prevents misconfiguration by validating these dependencies.


Role-Based Access Example​

Sales Department Permissions​

ModuleL1-Sales (Executive)L2-Sales (Manager)L3-Sales (Head)
ItemView onlyView onlyAdd/Edit
CustomerView onlyAdd/EditAdd/Edit
QuotationAdd/EditAdd/EditAdd/Edit
Sales OrderAdd/EditAdd/EditAdd/Edit
InvoiceView onlyAdd/EditAdd/Edit
Business ReportNo accessView onlyView only
Purchase OrderNo accessNo accessView only

What this means:

  • L1 users can create quotations and orders but not invoices
  • L2 users can manage customers and invoices
  • L3 users can add items and see purchase data
  • Everyone sees only modules they have access to

Real-World Impact​

Before Role Permissions​

Problems:

  • Users could access all modules regardless of role
  • No way to restrict sensitive financial data
  • Purchase team could see sales margins
  • Junior staff could modify master data
  • No control over who creates invoices or payments

After Role Permissions​

Benefits:

  • Each role sees only relevant modules
  • Financial data restricted to Finance department
  • Master data control limited to senior roles
  • Clear separation between view and edit access
  • Pages automatically hidden based on permissions

Getting Started​

TaskGuideTime Required
View Current PermissionsHow to View Guide2 minutes
Edit Role PermissionsHow to Edit Guide10 minutes
Understand DependenciesDependencies Section5 minutes


Quick Tips​

Best Practices

Start with restrictive permissions and gradually expand based on user needs

Always grant View access to master data (Items, Customers, Suppliers) before Add/Edit on transactions

Test permissions by logging in as a test user with that role before rolling out

Document your permission matrix for reference during onboarding

Review permissions quarterly to ensure they match current org structure

Use L1 for executors, L2 for approvers, L3 for administrators within each department


Need help? Contact support at support@bizconnekt.com