Mapping ReBAC Across
Two Merged ERPs

When two manufacturers merge their ERP estates, the access control work almost always starts with a role mapping table. Someone exports the role lists from both systems, places them side by side, and starts drawing lines between them - Sales Manager East on the left, Regional Sales Director on the right.

A role in an ERP is not just a set of permissions. It is a permission set plus an implicit data scope, and the scope often carries most of the meaning. The Plant Controller for Plant 3 and the Cost Accountant can have access to the same transaction codes and still be authorized to do entirely different things because one is scoped to a plant and the other to a cost center.

2.1 Pull the Relation Vocabulary Before the Role List

Review both ERP environments and identify the relationships that actually determine access. In manufacturing, these typically include:

Both companies will have many of these relationships. They will not necessarily implement them the same way.

After the merger, you need to decide which approach becomes the standard, or maintain both and deal with two separate authorization paths.

Relations Settle After Object Types

Relations point to objects, so you must resolve the object model first: account, order, plant, cost center, price list, item, employee record, warehouse, and legal entity. They may all exist in both ERP estates, but under different names and at different levels of granularity.

Until these object boundaries are resolved, the relationship model cannot be trusted.

Figure Out the Relations That Cross the Entity Boundary

This is where the merger-specific complication begins. Before the merger, most relationships existed within a single entity. Now a rep from legacy A can sell a legacy B product line into an account previously owned by legacy B, with fulfillment coming from a plant inherited from A.

The relation "owns account" now requires more context. Whether a user can see margin on an order may depend on:

• which entity booked the order,
• which entity manufactured it,
• which product line is involved, and
• when ownership of the account changed.

Decide Whether Relationships Need to Be Tracked Over Time

Access control is not only about who can see something today; during an audit, you may need to show who had access at a specific point in the past, such as March.

The relationship model most teams use, based on tuples of object, relation, and subject, is essentially a current-state model. It efficiently answers authorization questions about now. Historical reconstruction requires versioned relationships or another authoritative history store.

If territory ownership shifts on April 1, simply replacing the relationship may remove the previous assignment from the current authorization state. Supporting historical access means preserving effective dates and, ideally, the policy version that interpreted those relationships at the time.

The first post-consolidation audit can produce a question the system structurally cannot answer, leaving the team to reconstruct access manually from change logs and migration records.

Budget for Evaluation Depth Before Designing Relationship Chains

In manufacturing, access decisions can span multiple connected objects. A user may be linked to a plant, cost center, work order, item, and standard cost. As those chains grow, each additional relationship can add lookup and evaluation overhead, making performance an important consideration when designing the authorization model.

If someone opens one order, a few milliseconds for an authorization check does not matter. The same approach becomes expensive when a consolidated margin report returns forty thousand rows.

This creates an important technical distinction: point authorization and list authorization are two different workloads.

That introduces another problem: invalidation. If a salesperson's territory changes on the first of the month, all derived account permissions based on that relationship may change as well.

2.2 AI Makes the Authorization Model More Important, Not Less

Once an AI assistant can query orders, summarize customer margins, create transactions, or operate across ERP and WMS systems, authorization can no longer stop at the application screen. The AI needs to inherit the authorization context, relationships, and constraints of the user or process it represents.

A sales copilot asked to "show me our highest-margin accounts" should not simply retrieve every account the underlying model or application can technically reach. The request still has to respect:

Agentic workflows make this more important because one task can cross several systems. An AI agent might:

2.3 The Warehouse Is the Last Part Left

WMS and execution systems have their own access models, often cruder than the ERP model: badge, terminal role, work area, supervisor, shift, or equipment qualification.

But authorization in a warehouse depends on relationships that often live in HR: who reports to whom, who is qualified on which equipment, who belongs to which facility, and who is currently scheduled on a shift.

Qualification also introduces time into the model. An individual may be qualified to operate equipment today and not next month. These operational relationships can therefore require effective dates and expiration rather than simple present-or-absent membership.

Why the Role Mapping Table Belongs Later

This is why the role mapping table belongs later in the consolidation:

At that point, roles become useful again as a projection of a relationship model whose semantics are already understood.

We are mapping how this is being handled across specialty vehicle and safety equipment manufacturing, a segment that has changed ownership faster in the last eighteen months than in the previous ten years.

And increasingly, that question extends beyond employees. ERP consolidation is no longer only about whether people can access the correct data. The authorization architecture being built today will also determine whether future AI assistants and agents can safely operate across the combined enterprise.

FAQs