User Roles and Security

Overview

• What you’ll learn: How to configure role-based access control (RBAC) in iDempiere, including window, process, form, and data-level permissions, to secure your system with the principle of least privilege.
• Prerequisites: Lesson 1 (Introduction to iDempiere), Lesson 3 (Navigating the Interface), Lesson 5 (Organization Structure)
• Estimated reading time: 22 minutes

Introduction

Security is not an afterthought in ERP systems — it is a foundational requirement. An iDempiere installation typically serves users across multiple departments, each with different responsibilities and different needs for data access. A warehouse clerk should not be modifying the chart of accounts. An accounts payable specialist should not be approving their own purchase orders. A regional manager should see data only for their region, not for the entire company.

iDempiere implements security through a comprehensive role-based access control (RBAC) system. Roles are the central mechanism: every permission — what windows a user can open, what processes they can run, what data they can see, and even whether they can read or write — is controlled through role configuration. This lesson covers the entire security model, from the AD_Role table to record-level access rules, and provides best practices for designing a secure, maintainable role structure.

The Role Concept (AD_Role)

What Is a Role?

A role in iDempiere is a named collection of permissions stored in the AD_Role table. It defines what a user can and cannot do within the system. Roles are not users — they are permission templates that are assigned to users. A single user can be assigned multiple roles and selects which role to use at login time. This means the same person can log in as “Sales Manager” to process orders during the day and switch to “Report Viewer” when they only need read-only access to reports.

Key fields on the AD_Role record include:

• Name: The descriptive name of the role (e.g., “Accounts Payable Clerk,” “Sales Manager,” “System Administrator”).
• User Level: Defines the data scope the role operates at. Options include:
  • System: Access to system-level data and configuration (Application Dictionary, system clients).
  • Client: Access to data at the client (company/tenant) level.
  • Organization: Access restricted to specific organization(s).
  • Client+Organization: Access to both client-wide and organization-specific data. This is the most common setting for regular business users.
• Is Manual: When checked, the role uses explicit permission grants (whitelist approach — only specifically granted windows/processes are accessible). When unchecked, the role starts with access to everything and uses exclusion rules (blacklist approach). The Manual/whitelist approach is more secure and recommended for production environments.
• Max Query Records: Limits the number of records returned in queries to prevent performance issues from unrestricted searches.
• Overwrite Price Limit: Whether users in this role can override the limit (floor) price on sales orders.
• Is Can Approve Own Doc: Whether users can approve documents they themselves created (disabling this enforces segregation of duties).
• Approval Amount: The maximum monetary value a user in this role can approve without escalation.
• Confirm Query Records: A threshold that triggers a confirmation dialog when a query returns more than this many records.

System Administrator vs. Regular Roles

iDempiere ships with a pre-configured System Administrator role that has unrestricted access to everything — all windows, all processes, all data, across all clients and organizations. This role is used for initial setup, system configuration, and Application Dictionary modifications.

The System Administrator role should be assigned to a very limited number of users (ideally one or two) and should never be used for day-to-day business operations. Here is why:

• It bypasses all security restrictions, making accidental data modifications catastrophically easy.
• It provides access to the Application Dictionary, where changes can break the system.
• It operates across all clients in a multi-tenant environment.
• Audit trails lose meaning when changes are made by an omnipotent account.

For regular business operations, create purpose-specific roles with only the permissions each job function requires.

Access Control Configuration

Window Access (AD_Window_Access)

The AD_Window_Access table controls which windows (screens) are visible to a role. For each window, you specify:

• Window: The specific window being granted (e.g., Sales Order, Business Partner, Product).
• Is Read Write: When checked, the user can view and modify records in this window. When unchecked, the user has read-only access — they can see the data but cannot create, update, or delete records. Read-only access is valuable for transparency without risk — allowing a sales manager to view inventory levels without the ability to adjust them.

If a role does not have an entry in AD_Window_Access for a particular window, that window is completely invisible to the role — it will not appear in the menu, and directly navigating to it will be blocked. This is the default behavior for “manual” roles and is the essence of the whitelist approach.

Process Access (AD_Process_Access)

Processes in iDempiere are executable actions — reports, data imports, batch operations, and document processing routines. The AD_Process_Access table grants or restricts access to these processes per role.

• Process: The specific process being granted (e.g., “Generate Invoices,” “Import Bank Statement,” “Aging Report”).
• Is Read Write: For processes, Read Write means the user can execute the process. Read Only is less commonly used but can restrict the user to viewing the process definition without executing it.

Process access is particularly important for controlling who can run powerful batch operations like “Generate Invoices from Shipments” or “Reset Accounting” — operations that affect many records at once and should be restricted to authorized personnel.

Form Access (AD_Form_Access)

Forms are special interactive screens that go beyond standard window-based data entry. Examples include the Payment Allocation form, the Bank Statement Match form, and the Material Receipt form. The AD_Form_Access table works identically to window access:

• Form: The specific form being granted.
• Is Read Write: Whether the user can interact with the form fully (read-write) or view only (read-only).

Task Access

Tasks represent operating system-level operations that can be triggered from within iDempiere (though these are rarely used in modern deployments). Task access controls which roles can execute these external tasks.

Workflow Access

Controls which approval and process workflows a role can participate in or manage. This is relevant when you have document approval workflows configured — only roles with appropriate workflow access can act as approvers.

Data Access Levels

Understanding Access Levels

Every table in iDempiere has a defined Access Level that determines which roles can access its data. This is a fundamental security layer that operates beneath window and process access. The access levels are:

• System Only (Level 4): Only the System Administrator role can access this data. These are Application Dictionary tables and system configuration tables. Regular business roles cannot see this data regardless of their window access settings.
• System+Client (Level 6): Accessible by the System Administrator and by Client-level administrator roles. Used for tables that have both system-level defaults and client-specific overrides.
• Client Only (Level 2): Accessible by roles with Client or Client+Organization user level. Used for client-wide configuration data like price lists and payment terms.
• Client+Organization (Level 3): The most common level for transactional data. Accessible by roles with Client+Organization user level, which is the standard setting for business users. Orders, invoices, payments, and shipments all use this access level.
• Organization Only (Level 1): Accessible only within the specific organization context. Each record belongs to one organization, and users can only see records from organizations they have access to.
• All (Level 7): Accessible by all roles regardless of level. Used for universal reference data like countries, currencies, and units of measure.

Access levels act as a safety net. Even if you accidentally grant a regular business role access to a system table’s window, the access level prevents them from seeing the data. This defense-in-depth approach is a hallmark of iDempiere’s security architecture.

Organization Access (AD_Role_OrgAccess)

In a multi-organization setup, you need to control which organizations each role can access. The AD_Role_OrgAccess table defines this mapping:

• Role: The role being configured.
• Organization: The organization being granted. You can grant access to specific organizations (e.g., “US East Division”) or to the special organization “*” (asterisk), which represents all organizations.
• Is Read Only: Whether access to this organization’s data is read-only.

This is a powerful feature for multi-branch, multi-division, or multi-country deployments. A regional sales manager might have read-write access to their region’s organization and read-only access to the parent company’s organization (to see consolidated data). A corporate controller might have read-only access to all organizations for reporting purposes.

Organization access works as a filter on virtually all queries in the system. When a user with access only to “US East” opens the Sales Order window, they see only sales orders belonging to the “US East” organization — orders from other regions are completely invisible.

Record-Level Security (AD_Record_Access)

For scenarios where window-level and organization-level security are not granular enough, iDempiere provides record-level security through the AD_Record_Access table. This allows you to grant or deny access to specific individual records within a table.

Record access entries specify:

• Role: The role this rule applies to.
• Table: The table containing the record.
• Record ID: The specific record to control.
• Is Exclude: When checked, this is a deny rule (the role cannot access this record). When unchecked, it is a grant rule (the role can access this record).
• Is Read Only: Whether access is limited to read-only.
• Is Dependent Entities: A critical flag — when checked, the restriction cascades to all records in other tables that reference this record. For example, denying access to Business Partner ID 1000001 with dependent entities enabled would also hide all orders, invoices, and payments for that business partner. This cascading behavior is extremely powerful but must be used carefully to avoid unintended data hiding.

Record-level security is commonly used for:

• Restricting access to specific bank accounts (only the treasury team can see the main operating account).
• Hiding sensitive business partner records from certain roles.
• Controlling visibility of specific document types.

User-Role Assignment (AD_User_Roles)

The connection between users and roles is stored in the AD_User_Roles table. This is a many-to-many relationship — a user can have multiple roles, and a role can be assigned to multiple users.

To assign a role to a user:

1. Navigate to the User window (or the Role window — both provide access to the assignment).
2. In the User Roles tab, add a new record selecting the desired role.
3. Save the record.

When a user logs in, they are presented with a list of their assigned roles and must select one. The selected role determines their entire permission set for that session. Users can switch roles without logging out by using the role selector in the toolbar, but switching roles refreshes the session and resets the navigation context.

It is a best practice to assign users the minimum number of roles they need. While having multiple roles provides flexibility, it also increases the risk of a user inadvertently operating under an overly permissive role.

The Role Window: A Walkthrough

The Role window is the central location for configuring all security settings for a role. Navigate to System Admin → General Rules → Security → Role. The window contains the following tabs:

1. Role (Header): Configure the role’s basic settings — name, user level, manual flag, approval amount, price limit override, and other role-wide settings described earlier.
2. Organization Access: Define which organizations this role can access. Add one entry per permitted organization.
3. Window Access: Grant access to specific windows. For manual roles, only windows listed here will be visible. For each window, set the read/write flag.
4. Process Access: Grant access to specific processes and reports.
5. Form Access: Grant access to specific forms.
6. Task Access: Grant access to specific OS tasks.
7. Workflow Access: Grant access to specific workflows.
8. Record Access: Define record-level security rules.
9. User Assignment: View and manage which users are assigned to this role.

When creating a new role, a practical approach is:

1. Create the header record with the role name and set Is Manual to Yes (whitelist approach).
2. Set the User Level to Client+Organization for standard business roles.
3. Add organization access entries for the relevant organizations.
4. Add window access entries for every window the role needs, setting read/write appropriately.
5. Add process access entries for every report and process the role needs.
6. Add form access entries as needed.
7. Configure record-level security if required.
8. Assign users to the role.
9. Test by logging in as an assigned user and verifying that the correct windows, data, and actions are available.

Login Restrictions

Beyond role-based permissions, iDempiere supports additional login restrictions that add layers of security:

• IP Address Restrictions: Limit login to specific IP addresses or ranges. This is useful for restricting administrative access to the corporate network only.
• Time Restrictions: Define the hours during which a role can be used. For example, you might restrict the “Payment Processing” role to business hours only (8 AM to 6 PM).
• Password Policies: Configure password complexity requirements, expiration periods, and lockout policies after failed login attempts.
• Two-Factor Authentication: Available through plugins, adding an extra layer of security beyond username and password.

Best Practices for Role Design

Designing an effective role structure requires balancing security with usability. Here are proven best practices:

1. Follow the Principle of Least Privilege

Every role should grant only the minimum permissions required for its intended job function. Start with no access (manual/whitelist approach) and add only what is needed, rather than starting with full access and trying to remove what is not needed. The whitelist approach is inherently more secure because new windows and processes added to the system are automatically excluded until explicitly granted.

2. Design Roles Around Job Functions, Not Individuals

Create roles like “Accounts Payable Clerk,” “Sales Representative,” “Warehouse Manager,” and “Financial Controller” rather than “John’s Role” or “Mary’s Role.” Function-based roles are reusable, maintainable, and align with organizational structure. When John transfers from AP to AR, you simply change his role assignment rather than reconfiguring a personal role.

3. Enforce Segregation of Duties

Critical business processes should require multiple people across different roles. Common separations include:

• The person who creates a purchase order should not be the person who approves it.
• The person who receives goods should not be the person who processes the vendor invoice.
• The person who processes payments should not be the person who reconciles bank statements.

Use the “Is Can Approve Own Doc” flag and approval workflows to enforce these separations systematically.

4. Use Read-Only Access Liberally

When in doubt, grant read-only access. Visibility promotes transparency and informed decision-making. A sales manager who can see inventory levels (read-only) makes better promises to customers. Only grant read-write access when the role genuinely needs to create or modify records in that window.

5. Leverage Organization Access for Data Isolation

In multi-branch or multi-division deployments, organization access is your primary tool for data isolation. Grant users access only to the organizations relevant to their work. This not only improves security but also simplifies the user experience — users see less clutter and find relevant data faster.

6. Document Your Role Definitions

Maintain documentation that maps each role to its intended job function, the permissions it grants, and the rationale for those permissions. When audit time comes — and it will — this documentation is invaluable. It also helps when onboarding new administrators who need to understand the security model.

7. Regularly Audit Role Assignments

Periodically review who has which roles. People change positions, leave the organization, or accumulate roles over time. A quarterly review of user-role assignments helps identify orphaned access (former employees who still have active accounts) and role creep (users who have accumulated more permissions than their current job requires).

8. Test Roles Thoroughly

After creating or modifying a role, log in as a user with that role and verify the experience. Confirm that required windows are visible, necessary processes are accessible, data from the correct organizations appears, and restricted functions are genuinely blocked. Testing from the user’s perspective catches configuration gaps that are invisible from the administrator’s view.

Key Takeaways

• Roles (AD_Role) are the cornerstone of iDempiere security — every permission is controlled through role configuration.
• Use the manual (whitelist) approach for roles: grant only what is needed rather than revoking what is not.
• Window Access, Process Access, and Form Access control what users can see and do. The Is Read Write flag provides granular read-only vs. full access control.
• Data Access Levels provide a safety net, ensuring that system-level tables are never accessible to regular business roles.
• Organization Access restricts data visibility to specific organizations — essential for multi-branch deployments.
• Record-Level Security (AD_Record_Access) enables fine-grained control over individual records, with optional cascading to dependent entities.
• The System Administrator role should be reserved for system configuration only — never for daily business operations.
• Design roles around job functions, enforce segregation of duties, follow the principle of least privilege, and audit assignments regularly.
• Users can have multiple roles and select one at login, allowing flexible access patterns without compromising the security model.

What’s Next

Congratulations! You have completed the General Foundation module of the Beginner learning path. You now have a solid understanding of iDempiere’s core concepts — from the application dictionary and navigation to business partners, products, documents, reports, and security. With this foundation, you are prepared to move on to intermediate topics that cover the full procure-to-pay and order-to-cash business processes, advanced reporting, and system customization.