ERP UAT: test roles, approvals and access boundaries

Test each ERP approval with the accounts and permissions people will use at launch. A purchase request should reach the right approver, an unauthorized approval should be blocked, and records outside the user’s agreed scope should stay inaccessible. Record the expected and observed result for each case, then have the responsible business owner review the evidence.

For an Arabic and English rollout across several entities, the useful unit of testing is a specific person, action and record. The worksheet below makes those combinations explicit, using a hypothetical purchasing policy. Adapt the requirements to your organization and selected ERP product before execution.

What should UAT prove about access?

User acceptance testing, or UAT, asks whether the implemented process is usable and acceptable to the people responsible for running it. Microsoft’s Dynamics 365 testing guidance places business users in an integrated test environment and calls for training before UAT. Its process testing guidance also includes intended security roles and negative tests.

Translate that into three questions for the process owner:

• Can the intended person finish the task and hand the correct result to the next person?
• Are prohibited actions and records outside the user’s scope handled according to the approved policy?
• Can the business understand and resolve a rejected, changed or exceptional transaction?

A consultant’s demonstration can help explain the process. The acceptance record should identify the business tester and the actual account used. If the consultant has administrator access, their successful transaction does not establish that a purchasing clerk can perform the same work.

Include this evidence in the agreed ERP implementation scope, with time for correcting defects and rerunning affected cases.

Define the permission decision before writing test steps

Start with a short business statement: who may do what, on which records, under which conditions? For example, “A requester may submit a requisition for their entity; a different authorized approver must approve it.” Agree whether that statement is an actual organizational requirement before converting it into a test.

Use “role-based” as a business shorthand. A product may also use organizational scope, record ownership, groups, relationships or other attributes to determine access. In Dynamics 365 finance and operations, Microsoft describes roles, duties, privileges and permissions, with data security policies able to restrict record access. Confirm the equivalent controls in the product and edition being implemented.

For each scenario, record:

1. Requirement and policy owner, including the policy version
2. Business persona, test account and all assigned roles or relevant groups
3. Entity, department, record ownership and any other applicable data boundary
4. Action, transaction state and the condition that allows or prohibits it
5. Expected business outcome and expected access outcome
6. Test data, prerequisites, evidence location and acceptance owner

Keep the business rule separate from the configuration label. A role called “Finance Approver” says little about its effective access until you inspect and test its assignments. Review combinations used by real people, as well as isolated roles. A person covering two jobs may need a different test set from someone holding only one of them.

Test permitted actions, boundaries and exceptions

The following worksheet is an original planning example. It assumes a policy that separates requesting and approving, restricts entity access, and requires renewed approval for specified material changes. These are illustrative requirements, not default behavior promised by any ERP vendor.

Do not mark a negative test as passed only because a button is hidden. OWASP’s authorization guidance recommends default denial and permission checks on every request. Ask the technical team to verify the relevant application, report, export and integration entry points within the authorized test scope. Record both the response and whether any business state changed.

UAT does not replace specialist security testing. Agree who owns deeper authorization testing, and link its findings to acceptance decisions when they affect the business process.

Run one approval scenario all the way through

Prepare a controlled example

Hypothetical example: an organization approves a test policy in which requests up to 10,000 units of a chosen test currency use one approval level; larger requests require an additional level. The requester cannot approve their own request, and the two example entities have separate access scopes.

Write down the amount basis before testing: net or gross, line or document total, rounding, and any currency conversion rule. Use values immediately below, exactly at, and immediately above the agreed threshold. Otherwise, two testers can report different outcomes while testing different interpretations of the policy.

Prepare distinct, approved test accounts for the requester, approver, substitute and user outside the permitted scope. Identify the baseline configuration and test data version. Use an isolated nonproduction environment, and confirm that supplier messages, payment interfaces and other consequential outputs use approved test destinations or are safely disabled.

Track the request through each state

Submit the request, inspect the next person’s queue, approve it, and verify the resulting state and downstream document. Repeat with a rejection and correction. Check who can edit the record at each stage and which changes require another decision under the agreed policy.

Then exercise the boundary cases. Confirm that self-approval is prevented, the extra approval level receives the larger request, and an unauthorized user cannot perform the same action. Test delegation inside and outside its allowed period. If delegation is unsupported or works differently from the requirement, record a fit gap for a business decision.

Add one deliberate control change in the test environment, such as removing a role assignment from an approved test account through the authorized administration process. Confirm the resulting access behavior, including when the change takes effect under the product’s session rules. Restore the agreed baseline before the next cycle and retain the change record.

Check duty conflicts independently

Segregation of duties concerns combinations of responsibilities that the organization has decided must be separated. Workflow routing and duty conflict checks answer related but different questions. A request may route correctly while a user holds an inappropriate combination of roles.

One product detail deserves attention: Microsoft’s segregation of duties instructions say that creating a rule does not validate existing roles or assignments; validation must follow creation or modification. Buyers should ask what validation step their chosen platform requires, then retain its result alongside transaction tests. Do not assume that saving a rule proves compliance with it.

Make English and Arabic testing operationally equivalent

For a bilingual rollout, keep a shared scenario ID and business expectation across both languages. In the hypothetical policy above, one case could test a request of exactly 10,000 units in Entity A. The Arabic and English executions must use the same amount basis, assigned approver and expected approval level. Check translated action labels against that same rule.

Ask an appropriate business reviewer in each language to check:

• Action labels: can users distinguish submit, approve, reject, return and cancel?
• Record context: are entity, supplier, currency and request references clear?
• Numbers and dates: does the displayed value match the underlying test record and agreed locale?
• Messages: does an access denial explain the permitted next step without exposing restricted information?
• Outputs: are required documents, notifications and reports usable in the relevant language and layout?
• Training: can users follow the same approved process using material in their working language?

Record language or right-to-left display defects separately from business rule failures, while preserving their process impact. A truncated approval message can still block a critical task. Confirm actual product language coverage and any customization required; a translated training guide does not establish that the application supports the same language.

For wider country and rollout dependencies, connect these results to the MENA rollout readiness guide.

Use evidence that survives a retest

A screenshot alone rarely identifies the configuration, access assignments and transaction history behind a result. Keep a compact record for each execution: scenario ID, release/configuration reference, test data version, tester, role assignments, timestamp, expected and observed results, and linked defects. Retain only permitted information; exclude passwords, tokens and unnecessary personal or commercial data.

If a case fails, identify whether the cause is configuration, code, data, unclear policy, missing access or a training need. Give the issue an owner and a repeatable reproduction record. A clarification that changes the expected behavior should update the requirement as well as the test.

After a fix, rerun the failed case and the other cases affected by the change. For example, expanding an approver’s entity scope should trigger checks of both newly allowed records and records that must remain restricted. Keep the original failure and the retest as separate executions.

OWASP’s guide to automating authorization tests describes a matrix of features, roles and, where needed, data, which can feed repeatable integration tests. Use automation for stable permission checks where your platform supports it; preserve the business owner’s review of the actual working process.

What should the launch decision contain?

Microsoft’s testing strategy guidance calls for test scope, entry and exit criteria, ownership and outcome tracking, with business stakeholders participating in acceptance. For this review of roles and approvals, agree the decision criteria before execution.

Use this proposed checklist:

• Critical processes have completed cases for permitted actions, prohibited actions and relevant data boundaries
• Actual launch roles and approval rules match the reviewed configuration, or differences have explicit impact assessments
• Required entity, language and delegation variations are covered
• Open defects show business impact, owner, workaround if approved, and a decision
• Authorization or duty conflict gaps have been assessed by the responsible control owner
• Fixes have been retested, including affected neighboring scenarios
• The business owner accepts, defers or accepts with specific documented exceptions

A high overall pass rate can conceal a failed critical control. Review coverage by process and risk, and show blocked or unexecuted cases explicitly. An exception needs a named decision maker, its scope, any approved temporary control, and a review date. Use the organization’s agreed launch gates; this worksheet is not a compliance certification.

Connect the role model to the acceptance decision

The Blue LED Global connects two parts of this work: our governance and access controls service covers role design, duty separation and control validation; our testing, training and support service covers UAT coordination, defects, retesting and Arabic and English user enablement. The scope and responsibilities are agreed for each engagement.

For the planning review, bring one priority process, its approval policy, actual role assignments, entity boundaries and sample records. Name the person who can resolve policy questions and the users who will test the work. The acceptance decision should point back to that same process, configuration and evidence.

Sources and review date

The worksheet and hypothetical example are editorial recommendations. Microsoft references describe Dynamics 365; OWASP references address application authorization. They do not establish identical features, licensing or controls in every ERP product.

• Microsoft Learn: Types of tests
• Microsoft Learn: Role-based security
• Microsoft Learn: Set up segregation of duties
• Microsoft Learn: Test your Dynamics 365 solution before deployment
• OWASP: Authorization Cheat Sheet
• OWASP: Authorization Testing Automation Cheat Sheet

Sources checked: 8 October 2026.