Axelor Permissions Need Review Across Objects, Fields, and Roles
Axelor Open Suite combines CRM, sales, finance, inventory, production, HR, and project modules on a low-code platform. That breadth is the point of an integrated business suite. It also creates a permission graph that a single login page cannot describe.
Axelor documentation describes permissions, roles, groups, users, object rules, and field-level rules. A role can carry read, write, create, delete, or export rights. Conditions can narrow access to individual records. The security task is to verify the effective result across every module a user can reach.
A broad suite with a narrow login signal
A ZoomEye query for title="Axelor" returned 404 matches on November 8, 2026 at 21:45 UTC. The query used sub_type=all, page 1, and page size 1. app="Axelor" returned 0 and http.body="Axelor" returned 1,864.
The title result is a useful candidate list for an application with a broad business surface. The missing app fingerprint means the product name is not enough to classify every instance. Body matches may include documentation and project pages, so they are not a substitute for endpoint validation.
Model the effective permission
Start with the object. A permission attached to SaleOrder, for example, should state whether a user can read, write, create, delete, or export records. Then check the field rules. A user may read an object but not a cost, margin, bank, or personal-data field.
Next, check the condition. Axelor can apply record-level rules based on values or the acting user. A rule that limits a salesperson to their own orders is different from a role that has global read access. Verify the condition with test records created by two different users.
Review roles and groups as layers. A user can receive permissions through a group and a role, and a specific rule may narrow or expand the result. The effective permission is the combination, not the label on one role. Export permissions deserve special attention because the export of a permitted object can create a new copy outside the application.
Review integration and administration
Axelor deployments often connect to PostgreSQL, mail, document storage, and external APIs. Review the service accounts used by integrations and their object permissions. An integration with a broad administrator role can undo the careful separation applied to human users.
Keep administrative menus, user management, role management, and low-code customization behind a restricted path. A user who can change a permission or field rule can alter the security model without touching the underlying code. Record who has that authority and review changes.
Review attachment and document access separately from database fields. A record the user cannot read may still have a downloadable file, a preview, or an export that reveals its content. Test the route that serves the file, not only the form that displays the record.
Monitor access changes
Alert on role and group changes, new users, permission conditions, field-rule updates, and bulk exports. Correlate those events with the administrator identity and source network. A role change during a business-critical period should have a clear approval record.
Use a staging company with low-sensitivity data to test one end-to-end workflow. Create a sales record as one user, then verify that a second user sees only the fields and records allowed by the role and condition. Repeat after removing one group. Confirm that a new session cannot use the removed authority.
Build the permission map
The 404 title matches are a candidate population, not an affected count. The useful inventory records the deployment owner, modules enabled, authentication mode, administrative accounts, and the external integrations that can reach business objects.
Axelor is designed to express fine-grained business authority. That flexibility is also the review burden. A permission model is secure when the effective object, field, condition, and export results have been tested for the people and software that use it.
Top comments (0)