User security settings in Acumatica Cloud ERP allow you to control who gets to view – and manage – what data and when, with strict role-based access rights (RBAC) levels that are engaged when anyone signs into your hosted tenant. From login to file uploads to transaction approvals, admins can adjust these permission settings from individual end users to role types at any given time.
Taken from a demo recorded by the Acumatica consulting team at SWK Technologies, this walkthrough covers what a user passes through before reaching their homepage, how their assigned role shapes that homepage and where record and field restrictions apply inside a live document. Here is how each layer works:
Protection at the Acumatica Login Page
Before any permissions come into play, Acumatica handles the sign-in itself. The login page runs over HTTPS, which is the secure protocol that guards the exchange between the browser and the ERP against interception. That is the baseline every deployment gets, and several additional controls sit on top of it.
Password Policy
Password rules are set company-wide on the Security Preferences form, with overrides available on individual user records. Administrators control minimum length, character complexity, reuse restrictions and expiration, and can lock an account after a defined number of failed sign-in attempts. Acumatica’s own guidance weights length over complexity, recommending a minimum of twelve characters, and pairs strong length requirements with a second authentication factor rather than relying on frequent forced password changes.
Multifactor Authentication
Multifactor authentication asks a user to confirm their identity with something beyond a password, using a second factor delivered by email, text message or an authenticator application on a phone or tablet. The user approves the prompt, and the sign-in completes. A stolen or guessed password on its own no longer reaches the data, because whoever holds it still needs the second factor.
Single Sign-On
Acumatica also supports single sign-on (SSO) against an existing identity provider, including Google and Microsoft directory accounts. Users authenticate once through the provider they already sign in to every morning and reach the ERP without a separate password to keep track of. Access can be narrowed further per user with an IP address filter, so sign-in attempts from outside an approved range are refused, and a user account can be switched off outright from the Users form when someone leaves or a contractor finishes an engagement.
Both multifactor authentication and single sign-on are configured per instance rather than being on by default, which is worth confirming during setup rather than assuming.
How Role-Based Access Rights Work
Once a user is authenticated, their assigned role determines what the ERP shows them. A role is a named set of access rights to system objects, and Acumatica ships with a set of predefined roles — Administrator among them — that most companies adapt rather than rebuild. Administrators grant rights through the Access Rights by Role and Access Rights by Screen forms, working down a tree that runs from the tenant through workspaces, forms, containers and individual form elements. Rights propagate down that tree and nested objects inherit from their parents, so a grant made at the workspace level carries to the forms beneath it until an administrator changes it. A newly created role starts with access revoked across the board, which means permissions are added deliberately rather than trimmed back from full access.
How granular the setting can be depends on the object: some allow a specific level of operation, while others are a straightforward allow or deny. Users can hold one role or a combination of several, and assignment happens on the user record.
The practical result is that an accounts receivable clerk and a controller can work in the same instance and see two different applications.
Module and Screen Visibility
The module list running down the left side of the screen reflects the signed-in user’s rights. An accounts receivable clerk with permission to receivables and nothing else sees the receivables icon and no others — the payables screens are not hidden behind a warning message, they simply are not there. Widening that same clerk’s work to cover both sides of the ledger is a matter of granting payables access, which produces a general accounting view without creating a second login.
Dashboard Assignment on Login
Roles also decide which dashboard a user lands on. Rather than dropping every employee onto the general customer view, an administrator can set the receivables clerk dashboard as that clerk’s homepage so the first screen they see each morning is the work in front of them. Individual widgets follow the same permission model as the screens behind them: if overdue receivables are not that clerk’s responsibility, the tile reporting them can be restricted and the rest of the dashboard stays intact. Every other preconfigured dashboard in the financial modules can be assigned and trimmed the same way.
User Personalization
Anything a user does to make the interface their own — favoriting screens and actions, rearranging what they reach for most — is saved to their own sign-in and carries no effect on anyone else’s. Nothing one clerk does propagates across the company. Administrators and managers retain the rights to reverse changes made inside a user’s instance, so activity that should not be happening on one login can be rolled back without touching anyone else’s setup.
Record and Field Restrictions Inside a Document
Screen access answers whether a user can open a form. It does not answer what they can do once they are inside one, and that is where the more granular controls apply. The payments and applications screen under Receivables is a useful example, since processing incoming payments is daily work for most AR clerks.
Which Customers a User Can Reach
A clerk creating a payment normally has the full customer list available to them. Restriction groups narrow that list to the accounts a particular user is responsible for, whether the split runs by region, by account size or by any other division the company already works with. The clerk keeps the screen and the workflow, and the records outside their assignment stay out of view. The same row-level mechanism governs visibility of branches, warehouses, inventory items, vendors and projects, so the pattern set for customers carries across the rest of the system.
Restricting Cash Accounts
Companies running multiple cash accounts can control which of those accounts a user is able to select on a payment. Access can cover one account, several or none, and the field can be locked to a single account so the entry point is fixed rather than chosen.
Approval Holds
Payments and similar documents can be placed on hold for approval instead of releasing straight to the general ledger. The clerk enters the payment as usual, and the document waits for an accounting manager to approve it before it posts. Routing runs through configurable approval maps rather than the access rights model, so the two work alongside each other: rights decide who can reach the payment screen, and the approval map decides what happens to a document after it is entered. Acumatica’s own role planning guidance recommends exactly this separation, noting that duties involving cash handling are commonly segregated, as are the duties of recording documents and processing them afterward.
Auditing Who Did What
Permissions govern what a user is able to do. Audit records cover what they actually did. Acumatica deploys with standard auditing active, and the results surface on the Access History screen — sign-ins, failed sign-ins, sign-outs, screens accessed and session expirations among the tracked events, with the audited items and retention period configurable under the audit settings in Security Preferences. Screen-level audit information shows who created and last modified a given transaction and when, and field-level auditing can be turned on to track creation, updates and deletions across specific screens such as customer and vendor records.
Alongside those logs, the access rights reports let an administrator review what a role can reach or what an individual user can reach across every role assigned to them. Acumatica recommends running that review on a quarterly cadence and after any promotion, change of duties or departure, which is also when temporary implementation and consultant accounts tend to get overlooked.
Where This Gets Defined for Your Business
What a single walkthrough covers is deliberately surface level, and the model goes considerably deeper. The version of user security a company actually runs on reflects how that company divides its work, and those decisions get made during implementation — mapping job duties onto roles, deciding where restriction groups apply and setting the approval thresholds that documents route through. Acumatica’s guidance is to plan that configuration when the system is first implemented and to revisit it whenever the security policy changes, working from least privilege: grant the access a job requires and no more, and reserve broad administrator rights for the accounts that genuinely need them.
Worth separating from all of this is the platform layer underneath. Encryption, backups, intrusion detection and the SOC audits behind the hosting environment are handled by Acumatica rather than configured by your team, and Acumatica publishes its current control set and compliance documentation in its Trust Center. User security is the part your business owns.
Improve Your Acumatica User Security with SWK Technologies
Setting up access rights that match how your team actually works — and adjusting them as duties shift — is where an experienced partner earns their keep. SWK Technologies has implemented and supported Acumatica for businesses across manufacturing, distribution, construction and professional services, and we can help you design a permission structure that empowers your team to work without friction while keeping your financial data where it belongs.
Contact SWK here to talk through user security in Acumatica with our consulting team and capture peace of mind over who reaches your ERP data.