Who Can Do What in Epicor—and When Did You Last Review It?
Epicor access tends to expand as people change roles, cover colleagues and inherit responsibilities. A useful access review connects permissions to current job responsibilities, business risk and segregation of duties.
The short answer
Epicor user access should be reviewed against what people are responsible for now, not what they needed when their account was created. Role changes, temporary cover, projects and accumulated permissions can gradually give users broader access than the business intends.
A practical access review maps permissions to current job responsibilities, identifies incompatible combinations of authority, confirms temporary access has expired and records who approves any exception.
The objective is not to make security restrictive. It is to make access explainable.
How this connects to the pillar
The wider control framework is covered in Epicor Is Full of Controls. How Do You Know They Still Match the Way the Business Operates?. User access is one of the first places where a well-designed Epicor control can drift from the current organization.
Role creep happens gradually
Most access problems are not created by one dramatic decision.
A buyer covers for a colleague and receives additional authority. A supervisor joins a project and gets a temporary role. A finance user changes responsibility but keeps access needed for the previous position. A manager receives broader company access during an acquisition.
Each decision can be reasonable individually.
The control gap appears when nobody later removes access that is no longer required.
Review capability, not only account status
A basic access review asks whether the user still needs an account.
A stronger review asks what the account can actually do.
For important roles, examine capabilities such as:
- create or change master data;
- release or approve transactions;
- adjust inventory;
- post financial activity;
- change prices or terms;
- access multiple companies or sites;
- override normal workflow;
- maintain security or configuration.
The review should connect these capabilities to current responsibilities.
Look for incompatible combinations
Segregation of duties is not about avoiding every overlap.
Small teams may need people to perform several roles. The important point is to identify combinations where one person can initiate, approve and conceal the same high-risk transaction without meaningful review.
Examples can include creating a supplier and approving related purchasing activity, changing sensitive master data and posting the resulting transaction, or maintaining security while also operating the process being controlled.
If the business accepts an overlap, document the compensating review rather than pretending the conflict does not exist.
Separate normal access from emergency access
Some users need broader permissions occasionally.
Instead of keeping those rights permanently, define a controlled temporary-access process where practical. Record why the access is needed, who approved it and when it expires.
This reduces the number of permanent exceptions and makes unusual authority more visible.
The administrative effort should be proportionate to risk; not every minor permission needs a formal emergency process.
Join access review to employee movement
Security governance is much easier when role changes trigger review automatically as part of the business process.
New starters, transfers, promotions, site changes, extended leave and departures all affect access.
A move within the company can be as important as a departure. A user who changes from operations to finance may require new rights, but old operational permissions should not remain simply because the account stays active.
Avoid role design around individual names
Security roles are easier to govern when they describe responsibilities rather than particular people.
A role such as “warehouse supervisor” can be reviewed against an operating responsibility. A collection of one-off permissions built for a specific employee is harder to understand after staff changes.
Individual exceptions may still be necessary, but they should remain visible as exceptions.
Use real transactions to validate access
Configuration reports are necessary, but they may be difficult for business managers to interpret.
For high-risk permissions, show what the access means in practice.
Can the user adjust inventory? Can they approve a purchase above a threshold? Can they change a bank-related supplier field? Can they see another company?
Business owners can make better decisions when the permission is expressed as an operational capability.
Review shared and service identities separately
Not every Epicor identity represents a person.
Integrations, service accounts or shared operational devices may require technical access. These accounts should have a clear owner, defined purpose and appropriately limited permissions.
Shared human accounts make accountability difficult because the business cannot reliably connect an action to a responsible person.
Where shared devices are necessary, the user-identification method should still preserve appropriate traceability.
Remove unused access deliberately
Unused accounts and roles can remain invisible because they create no daily problem.
That is exactly why they should be reviewed.
If a role is no longer assigned, determine whether it should be retired. If an account has not been used for a long period, confirm whether the access is still required before leaving it active indefinitely.
Reducing unused security objects makes later reviews easier.
What management should measure
Useful indicators include:
- users whose role has changed without access review;
- temporary access past expiry;
- users with high-risk incompatible permissions;
- security exceptions without business approval;
- inactive accounts still enabled;
- generic or shared accounts without named owners;
- roles containing permissions no owner can explain;
- time between employee movement and access change.
These measures show whether access governance is keeping pace with the organization.
ACC context
ACC’s Epicor work includes the process and governance layer around implementation and ongoing improvement. Security roles are most sustainable when they follow real operating responsibilities rather than becoming a growing list of historical permissions. Explore ACC’s Epicor capabilities.
Operational review point
Select a small group of users who have changed responsibilities during the last year.
Compare their current job responsibilities with their actual Epicor capabilities. Ask the relevant manager to explain why each high-risk permission is still required.
This sample often reveals whether the formal review process is working without requiring an immediate full-system redesign.
Review access at the level managers can understand
Security reports can be too technical for a business manager to make a good decision. Translate high-risk permissions into plain-language capabilities such as “can adjust inventory,” “can approve supplier changes” or “can post across companies.” This creates a more meaningful review because the manager is deciding on business authority rather than interpreting internal security object names.
For complex roles, group permissions into operational responsibilities and show the exceptions separately. The review remains efficient while unusual authority stays visible.
Use access exceptions as role-design feedback
If the same one-off permission is granted to many users in the same role, the base role may no longer match the job. Conversely, if a role contains permissions that nearly every manager asks to remove, it may be too broad.
Exception patterns therefore help improve role design. The objective is a role model that fits normal responsibility closely enough that individual exceptions remain genuinely unusual.
Separate company and site access deliberately
Multi-company and multi-site Epicor environments create another access dimension.
A user may need the same functional role but only for selected companies, plants or warehouses. Broadening organizational scope can create more risk than adding one extra transaction capability.
Access reviews should therefore consider both what the user can do and where they can do it.
This is especially important after acquisitions, temporary assignments and shared-service changes.
Join privileged access to change governance
Users who can maintain security, configuration or technical settings should be reviewed separately from normal transaction users.
Privileged access can affect the control environment itself.
That does not mean technical administrators should be unable to work. It means the business should know who holds elevated authority, why they need it and what independent evidence exists for sensitive changes.
Privileged activity should fit the wider Epicor change-control process rather than sit outside it.
Make leaver control immediate and transfer control intelligent
Removing access for a departing employee is normally straightforward.
Internal transfers are harder because some access remains valid while other access should disappear.
The review should therefore compare old and new responsibility rather than simply add the new role.
A clean transfer process is one of the best ways to prevent permission accumulation over time.
Frequently asked questions
How often should Epicor user access be reviewed?
Frequency should reflect risk and employee movement. High-risk roles and users with broad authority may need more frequent review than stable low-risk accounts.
Does segregation of duties mean one person can never perform two related tasks?
No. Smaller organizations may need overlap. The key is to identify material conflicts and add an appropriate independent review where necessary.
Should temporary cover be handled with permanent permissions?
Prefer time-bounded access where practical so temporary authority does not become permanent by default.
Who should approve access?
The manager or process owner who understands the user’s business responsibilities should approve the capability; technical teams can implement it.