Smart Access Manager FAQs

These frequently asked questions cover the most common questions about configuring and using Smart Access Manager. For the full feature list, see Smart Access Manager Features.

Getting Started

Fully compatible with Odoo Enterprise (On-premise and Odoo.SH) and Odoo Community. Not compatible with Odoo Online (SaaS) — that hosting tier does not allow third-party apps.

No. Smart Access Manager depends only on standard Odoo components. Every rule points at a record type that already exists in your database, so it works with whichever apps you use.

Your Odoo administrator, plus anyone you give the Smart Access Manager / Manager group to — that group can build roles, assign them, and approve access requests without being a full Odoo administrator. Security Officer adds the compliance, conflict, and audit screens on top, and every administrator holding Settings receives it automatically.

No. Nothing changes until you create your first role. Smart Access Manager only adds restrictions on top of your existing Odoo access rights.

Yes. Create the role, assign it to a single test user, and log in as them. Nobody else is affected until the role is assigned, and removing the assignment puts that user back exactly as they were. A role can also be left Archived while you build it, or a record filter kept switched off with Apply Filter until you have reviewed it.

No, it works alongside them. Odoo decides what a user is allowed to do; Smart Access Manager narrows it further. Because it only restricts, a role can never give someone access they did not already have.

All roles, rules, grants, and logs created by the app are removed, and every user returns to their standard Odoo access rights.

Roles & Assignment

Assigned Users targets specific people. Apply to Groups targets everyone in the chosen Odoo groups, including members who hold the group indirectly — so anyone added to the group later receives the role automatically. Both can be used on the same role.

Yes. Field rules resolve to the most restrictive setting, record filters combine, and any role that hides an element hides it. Record permissions are the exception: an operation is allowed if any role allows it.

Use Access Control ‣ Granted Role Access and set an Expires On date. The role stops applying as soon as the date passes, and the user receives a reminder e-mail beforehand.

Yes. A role’s Companies field limits it to the companies you choose, and the role follows the company the user is currently working in. Leave the field empty and the role applies in every company. Two roles may share a name as long as their company scope differs, which is how the same policy is rolled out company by company.

Restrictions

Really hidden. The value is removed from the data itself, so it is also empty over the external API, cannot be exported, and cannot be grouped or aggregated.

No. Blocked export closes the export routes themselves; blocked import, duplicate, and archive are refused by the server; and locked or required fields are enforced on save, whichever way the save was made.

Yes. Field rules and value filters have an Apply on which screens? option. Leave it empty to apply everywhere, or pick specific screens.

Domain Access controls which records a user can work with. Filter Field Values controls which records appear in a dropdown, without restricting the records themselves.

Yes — that is what Conditional Rules do. Build a condition such as Status = Posted, then choose whether to lock the record, lock certain fields, block deletion, or hide elements.

Users & Administrators

Administrators are deliberately protected from lock-out: Block Login, the Kill Switch, Global Read-Only, and Block External API never apply to a user holding Settings or Access Rights. Remove those rights first, then apply the role.

Block Login is a role setting: users assigned to that role cannot authenticate. The Kill Switch is an immediate action on one user: it revokes their roles, blocks re-login, and logs them out of every open session within about a second. Both keep all data intact, and both are reversible.

Check whether a role they hold lists that menu under UI Control ‣ Hidden Menus, and remember that hiding a parent menu hides everything under it.

Compliance

No. Permission conflicts are informational — one role deliberately overriding another is a normal pattern. The role form shows the clash and which permission applies, so you can decide.

Use Compliance & Risk ‣ Compliance ‣ Audit Reports, choose a report type and a period, and click Generate Now. A monthly audit pack is also produced automatically each month.