As organizations grow, so does the complexity of managing who can access what inside their ERP system.
New hires come on board, responsibilities shift, and data volumes increase. At the same time, leadership teams are thinking more about internal controls, data protection, and compliance. The challenge becomes finding the right balance: maintaining oversight without slowing down the people who rely on the system every day.
Acumatica approaches this balance with a layered security framework. From broad system settings to highly granular data restrictions, the platform offers tools that allow organizations to shape access around real-world roles and responsibilities. When configured thoughtfully, these features support both operational efficiency and stronger governance.
System-Wide Security Settings
Security begins with global preferences that apply across the organization. These settings establish the baseline for how users interact with the system.
Password policies can be configured to require a minimum length or added complexity. Two-factor authentication can be enabled to add another layer at login. Account lockout rules can be adjusted to define how many failed attempts are allowed before access is temporarily blocked.
Because these settings apply to everyone, they create consistency. Whether someone works in finance, operations, or sales, the same foundational login standards are enforced across the board.
In addition, individual user profiles allow for more tailored controls. Administrators can determine whether a user can reset their own password, whether passwords expire after a certain period, and what roles are assigned to that user. This blend of global and user-level configuration gives organizations flexibility without sacrificing structure.
Role-Based Security: Controlling What Users Can See and Do
At the heart of Acumatica’s security model is role-based access.
Each user is assigned one or more roles, and those roles define what parts of the system they can access. Roles can be based on job function (AP Clerk, Marketing Manager, Controller, or Project Manager, for example) and Acumatica includes many prebuilt roles that can be adjusted as needed.
Role-level security operates across three primary layers:
| 1. Modules | Access can be granted or restricted at the highest level. If someone does not need access to Accounts Payable, that module can simply be removed from their view. It will not appear in their navigation menu. |
| 2. Screens and Pages | Within a module, access can be limited further. A user might be allowed to view vendor records but not release payments. Another user may be able to enter bills but not modify vendor profiles. |
| 3. Fields | For even more precision, permissions can be set at the field level. A user might be able to view a payment method but not edit it. Others may have full rights to insert, update, or delete records. |
These permissions range from fully restricted (no visibility) to view-only access, all the way to full read/write capabilities. This structure supports segregation of duties by aligning system access with actual responsibilities.
One important note: when a user is assigned multiple roles, the least restrictive permission typically applies. That makes role design and assignment an important part of maintaining proper access controls.
To provide visibility into changes, role modifications can also be tracked. Organizations can monitor who updated a role, what was changed, and when. Notifications can even be triggered automatically to alert administrators if role assignments are modified.
Row-Level Security: Restricting Access to Specific Records
While roles determine what areas of the system a user can enter, row-level security, managed through restriction groups, controls which specific records they can see.
This is particularly helpful when access needs to be limited within the same screen.
For example:
- A team member may only work with international customers.
- Certain employees may need access to regulated vendors.
- A branch manager might only view data related to their location.
Without row-level controls, anyone with access to the vendor or customer screen would see all records. Restriction groups allow organizations to narrow that visibility.
Two primary approaches are available. With the direct restriction, users are explicitly granted access to a defined list of records. In the inverse restriction, users are denied access to a defined subset, while retaining visibility to everything else.
The choice between these approaches often comes down to maintenance. If only a few records need to be hidden, an inverse restriction may be simpler. If access should be tightly limited to a small set, a direct approach may make more sense.
Once configured, restricted records disappear from lookups, listings, and transaction entry screens for affected users. They cannot search for or associate those records with transactions. This provides a deeper level of data separation without requiring separate databases or environments.
Restriction groups can be applied to vendors, customers, inventory items, general ledger accounts, projects, warehouses, and more, making them a powerful tool for organizations with complex operational structures.
Audit Trails: Tracking Change with Detail
Visibility into who changed what (and when) is another important part of a strong control environment.
Acumatica includes native tracking of record creation and modification. Users can see who created a transaction, when it was entered, who last updated it, and the date of the update.
For more detailed oversight, audit trails can be activated on specific screens and fields. Once enabled, the system records:
- The type of action (created or modified)
- The specific field that was changed
- The previous value
- The new value
- The user who made the change
- A timestamp
Audit history inquiries allow organizations to review this information in a centralized location. Instead of manually investigating discrepancies, administrators can quickly trace updates to vendor records, payment details, contact information, or other sensitive data points.
Because auditing can be configured at the field level, organizations can focus on high-impact areas—such as payment methods or billing contacts—without generating unnecessary noise from less significant updates.
Approval Maps: Structuring Review and Authorization
Security is not just about access. It also involves controlling how transactions move through the organization.
Approval maps allow businesses to route documents like AP bills, purchase orders, expense claims, and change orders through defined review paths before they are finalized.
These workflows can be simple or multi-layered. For example:
- All AP bills might require approval from an accountant.
- Bills above a certain dollar threshold might require a second approval from a department head.
- Certain vendors or transaction types might trigger additional review steps.
Rules can be based on amounts, vendor attributes, document fields, or other related data. The system tracks who approved each step and when, creating a documented approval history.
By formalizing these processes, organizations reinforce segregation of duties and reduce the risk of unauthorized or inappropriate transactions moving forward without review.
