Epicor ERP provides powerful tools for customizing processes, forms, and logic to align with a company’s unique operations. However, with that flexibility comes a critical concern: security. Customizations can inadvertently expose sensitive data, allow unauthorized changes, or bypass business logic when not properly secured.

That’s why implementing role-based access control (RBAC) in your Epicor customizations is not optional—it is essential.

In this article, Epicforce Tech offers a technical yet practical deep dive into how to secure Epicor customizations using role-based access. This guide is intended to help ERP administrators, IT teams, and developers better protect their systems and maintain compliance, all while ensuring that users have access to the tools they need—and nothing more.

Why Security in Epicor Customization Matters

Epicor customization enables process efficiency, automation, and enhanced usability. However, the more custom features you introduce, the more potential entry points you create for misuse—intentional or otherwise.

Here are common risks when customizations are not secured by roles:

• Users accessing screens or reports they should not see

• Unintended overrides of business logic

• Exposure of sensitive data fields (e.g., pricing, costs, HR data)

• Elevated actions like posting, approving, or deleting records without accountability

When proper access controls are in place, these risks are mitigated by ensuring only the right users can trigger sensitive actions or view restricted information.

Understanding Role-Based Access in Epicor

Epicor allows access control at multiple levels:

1. Menu Security – Restrict access to specific screens or forms

2. Field-Level Security – Control access to individual fields on forms

3. Process Layer Security – Use BPM logic to conditionally allow or block user actions

4. Custom Code Security – Embed role checks in C# code or custom forms

5. BAQ & Report Security – Control access to saved queries and reports

When planning Epicor customization, you should evaluate which layers are relevant and how they interact to form a complete security model.

Step-by-Step: Securing a Custom Epicor Function with Role-Based Access

To illustrate these concepts, let’s consider a real-world use case: a custom button on the Purchase Order screen that allows expedited approval for emergency orders.

Step 1: Define User Roles

Start by defining which security groups or user roles should have access. In Epicor, these are typically managed under:

• User Security Groups

• Task Sets (for process workflows)

• Employee Work Groups (if routing is workflow-based)

Create a group called ExpediteApprovers in the system.

Step 2: Add a Custom Field or Control

On the PO Entry screen, add a custom button labeled “Expedite Approval.” This will invoke a method or BPM to process the PO outside the standard approval chain.

Step 3: Add Role Checks via BPM

Use a Method Directive on the custom method triggered by the button:

1. Add a condition:
   If the current user is not in ExpediteApprovers

2. Add an action:
   Raise Exception
   Message: “You are not authorized to use this action.”

This prevents unauthorized users from running the function—even if the button is visible due to a screen personalization.

Step 4: Hide Controls Using UI Scripts or Personalization

To improve usability, hide the button from users who do not belong to the role. In a UI customization, use C# like:

This way, unauthorized users won’t even see the option.

Step 5: Secure Any Underlying BAQs

If this function relies on a BAQ, secure the BAQ by:

• Setting read access for specific roles

• Preventing direct execution from BAQ Designer by setting the "Shared" property to false unless needed

Tips for Applying Role-Based Security in Different Epicor Customizations

Always consider layered security. UI-level hiding is for usability. BPM-level validation is for enforcement.

Best Practices for Managing Secure Customizations

Securing your customizations should not be a one-time event. Here are best practices to help maintain consistent and scalable access control:

1. Standardize Security Group Naming

Use consistent naming for custom roles (e.g., AP_Approvers, SalesAdmin) to avoid confusion and misconfiguration.

2. Document Custom Access Rules

Maintain documentation for all customizations that include role checks, including:

• BPM directives

• Field visibility

• Group dependencies

This ensures future developers or admins can maintain or update access logic without breaking workflows.

3. Review Security Regularly

Set a quarterly or semi-annual process to audit:

• Which users are in which groups

• Whether those roles still align with their job functions

• Whether any new customizations lack role validation

4. Use UDFs for Dynamic Role Handling

If your logic needs to change frequently, use a custom table or user-defined fields to store dynamic role assignments that BPM can reference.

5. Test All Scenarios

Simulate user behavior for:

• Authorized users

• Unauthorized users

• Boundary conditions (e.g., user in multiple roles)

Ensure there is no path that bypasses your intended control logic.

Epicforce Tech’s Role in Securing Epicor Systems

At Epicforce Tech, we prioritize security in every Epicor customization we deliver. Our team doesn’t just build features—we design them to be auditable, secure, and scalable.

Our approach emphasizes:

• Using Epicor-native role management features first

• Avoiding hardcoded user IDs in logic

• Applying layered security at UI, BPM, and database levels

• Maintaining change logs and documentation for traceability

Security should never be an afterthought. We build it into every customization from day one.

Real-World Use Case: Securing Sensitive Financial Approvals

One of our clients, a mid-sized manufacturer, needed custom logic on the Accounts Payable screen to fast-track payments to certain vendors during raw material shortages.

Our solution:

• Added a custom checkbox “Urgent Vendor” only visible to Finance Managers

• Controlled visibility with UI role checks

• Enforced BPM logic that prevented submission if the user was not in FinMan_Users group

• Created an audit table that logged user ID, timestamp, and PO reference for every override

This customization not only sped up operations but also passed internal audit reviews with no findings, thanks to its role-based traceability.

Avoid These Common Mistakes in Epicor Security

• Only relying on UI personalization
  Visibility ≠ security. If a user knows the method name or field ID, they can still execute it.

• Hardcoding User IDs in logic
  Instead of if Session.UserID == "JohnD", use security groups or dynamic lists.

• Skipping BPM enforcement
  All sensitive actions should be validated with BPM conditions, even if the UI hides the option.

• Failing to test security across environments
  Always validate that your logic works in test, pilot, and production environments.

Moving Forward: Build with Security from Day One

The best way to secure Epicor customizations is to integrate security planning into the design process. Every customization should answer these questions:

• Who should be able to see this?

• Who should be able to trigger this?

• What should be logged, and where?

When you embed security logic into your forms, methods, and reports using Epicor’s role-based tools, you reduce risk and increase system integrity.

Conclusion

Epicor customization gives your organization the agility to adapt processes to your specific needs. However, without role-based access control, those customizations can introduce more risk than reward.

Use the tools Epicor provides—BPM directives, UI logic, BAQ security, and structured groups—to ensure only the right people can act on the right data.

At Epicforce Tech, we help you balance power and protection by designing secure, well-documented, and future-proof customizations. If you're looking to strengthen your Epicor environment with scalable role-based security, this guide is your starting point.