Page scripting in business central

Dynamics 365 : The Ultimate Guide to Page Scripting in Business Central (for UAT & Beyond)

Page Scripting in Microsoft Dynamics 365 Business Central lets you record real user actions in the UI and replay them automatically, turning repetitive, error-prone User Acceptance Testing (UAT) into a repeatable, scalable process. When combined with advanced techniques (Power Fx, validations, conditional steps) and headless execution (via tools like bc-replay), Page Scripting becomes a practical foundation for regression testing, faster deployments, and higher confidence go-lives.

Key takeaways

  1. Page Scripting is ideal for UI-level process validation during UAT—especially after updates, extensions, and configuration changes.
  2. You can start with no-code recording, then level up with Power Fx for dynamic data and validations for robustness.
  3. The biggest wins come from a repeatable UAT library of modular scripts you can rerun for every sprint, release, or hotfix.
  4. A mature testing strategy uses Page Scripting + AL test codeunits (UI workflow validation + backend logic validation).
  5. You should treat scripts as data-changing automation: run primarily in sandbox/UAT environments with controlled test data.

Table Of Contents

  1. Introduction: Why Automated UAT is a Game-Changer for Business Central
  2. What is the Page Scripting Tool in Business Central?
  3. Your First Script: A Step-by-Step Guide to Recording and Playback
  4. Advanced Techniques: Unleashing the True Power of Page Scripting
  5. A Strategic Approach: Integrating Page Scripting into Your UAT Process
  6. Taking it to the Next Level: CI/CD and Headless Test Automation
  7. The ROI of Page Scripting: More Than Just a Testing Tool
  8. Conclusion: Start Automating Your Business Processes Today
  9. Frequently Asked Questions (FAQ)

Introduction: Why Automated UAT is a Game-Changer for Business Central

If you’ve ever run UAT for a Business Central implementation, you already know the pattern:

  • A key user tests a scenario.
  • It “mostly works.”
  • Someone tests it again a week later after a config change, extension update, or minor code tweak—and now it breaks.
  • The team scrambles to reproduce the issue, compare steps, and figure out whether it’s a data problem, a permissions issue, or a regression.

Traditional, manual User Acceptance Testing (UAT) is often:

  • Time-consuming (the same flows repeated over and over)
  • Inconsistent (different users test differently)
  • Error-prone (humans miss steps and don’t record exact clicks/inputs)
  • Costly (slower projects, more rework, more go-live risk)

That’s where Page Scripting in Business Central changes the game.

Page Scripting is Microsoft’s in-client capability to record what a user does in the Business Central UI and replay it automatically. Done well, it gives you:

  • Repeatable, testable “user journey” automation
  • Faster regression testing for every sprint/release
  • A more reliable UAT process (and fewer “it worked on my machine” debates)

In this guide, we walk you through everything from the basics (record and play) to advanced techniques (Power Fx, validations, conditional logic, modular scripts) and finally how teams take scripts into CI/CD-style testing.

What is the Page Scripting Tool in
Microsoft Dynamics 365 Business Central?

AI in Business Central and the best business central addons for canadian smbs

Page Scripting in Business Central is a tool that records user actions performed in the web client (such as creating records, entering values, and posting transactions) and replays those steps automatically to validate end-to-end business processes—especially for UAT and regression testing.

At a high level, Page Scripting works like this:

  1. You open the Page Scripting pane inside Business Central.
  2. You start recording.
  3. You complete a workflow in the UI (for example: create a customer).
  4. You stop recording and save the script (often as a YAML file).
  5. You can replay that script to confirm the workflow still behaves correctly.

Who Should Use Page Scripting?

Page Scripting is useful across roles—not just developers.

  • Functional Consultants: Automate common UAT flows and validate business processes in a way users recognize.
  • IT Managers / Project Managers: Reduce go-live risk, shorten test cycles, and introduce repeatability into UAT.
  • Power Users / Key Business Users: Record “how we really work” in the UI and turn it into a repeatable test.
  • Developers / DevOps: Use UI scripts as a regression suite—especially when paired with command-line replay tools and pipelines.

Key Use Cases Beyond UAT

Page Scripting isn’t only for UAT. Teams often use it for:

  • Automating repetitive data entry in controlled environments (like training or sandbox prep)
  • Creating consistent training and demo scripts (record once, replay for every demo)
  • Reproducing bugs with exact steps for support tickets and developer handoff

Understanding the Scope: What It Can and Cannot Automate

A helpful mental model is: Page Scripting is strongest when the behavior you’re testing is standard Business Central UI driven by AL pages and actions.

It typically struggles with (or cannot automate reliably):

  • Control add-ins (custom UI components)
  • Embedded Power BI experiences
  • External browser elements outside the BC client
  • Power Apps experiences that aren’t native BC pages

Transparency note: Capabilities can evolve by version. Always confirm current limitations in official Microsoft documentation and release notes.

Your First Script: A Step-by-Step Guide to Recording and Playback

Page scripting in business central step by step

This section is intentionally “hands-on,” because this is where most competitor content ends. We’ll go further afterward.

Prerequisites: Getting Access to Page Scripting

Before you record your first script, confirm:

  • You have access to the Business Central web client
  • You’re working in a sandbox/UAT environment (recommended)
  • You have the right permissions:
    • PAGESCRIPTING - REC (record)
    • PAGESCRIPTING - PLAY (playback)

In many organizations, these permission sets are assigned to a specific testing role, not all users.

How to open Page Scripting:

  1. In Business Central, select the Settings icon (gear).
  2. Look for Page Scripting and open the pane.

Part 1: Recording Your First Script

We’ll record a simple, meaningful workflow: create a new customer.

Step 1: Start A New Recording

In the Page Scripting pane, select Start new (or equivalent “Record” action).

Step 2: Perform A Simple Action

Page scripting in business central step by step : Customer Pane
  • Navigate to Customers
  • Select New
  • Fill in a few fields:
    • Name
    • Address details
    • Posting group fields (as appropriate for your environment)
  • Save the record

Step 3: Observe the recorded steps

As you click and type, you’ll see steps appear in the scripting pane—think of it as a timeline of UI actions.

Step 4: Stop and save the recording

  • Select Stop
  • Save/export the script. In many setups, this results in a YAML file download.

Part 2: Playing Back Your Script

Step 1: Load/open the saved script

  • Open the Page Scripting pane
  • Load the YAML (or open it if the UI supports direct selection)

Step 2: Click Play

  • Select Play and observe the UI automation reproduce your steps.

Step 3: Understand success/failure indicators

Typical outcomes:

  • Green / Passed steps: the UI matched expected behavior
  • Failed steps: a field, page, or action didn’t behave as recorded

Crucial note (data safety): Playing back a script usually modifies data exactly as if a real user performed those actions. That means:

  • Scripts can create records, post documents, and trigger workflows.
  • Treat Page Scripting like powerful automation—run in sandbox/UAT unless you intentionally want production changes.

Editing and Sharing Your Scripts

Two practical realities of UAT automation:

  1. You’ll edit scripts often (field changes, new validations, new steps)
  2. You’ll share scripts across testers and environments

Common approaches:

  • Edit in the UI (delete/reorder steps where supported)
  • Share the YAML file in a version-controlled repository
  • Use a shareable link feature if available in your environment (verify current capability/version)

Advanced Techniques: Unleashing the True Power of Page Scripting In Business Central

This is where Page Scripting moves from “nice demo” to “real UAT automation.”

Dynamic Data with Power Fx: The “Hidden Feature” You Need to Use

A major reason UI automation fails is hard-coded values. The moment you replay a script in a different environment—or after data changes—you hit duplicates, missing records, or different numbering.

Power Fx helps you make scripts “Dynamic”!

What is Power Fx here?
Power Fx is Microsoft’s low-code expression language (used across the Power Platform). In Page Scripting, it can be used to compute values at runtime—so scripts can generate unique values and adapt to the current test run.

Generating Random Numbers

Use randomness to avoid duplicates in fields like external document numbers, descriptions, or test identifiers.

Example usage idea:
Set a description like: “UAT Customer 4821” by concatenating text + random number.

Using Dates and Times

Dynamic dates make scripts far more reusable.

“Sales Invoice for ” & Text(Today(), “yyyy-mm-dd”)

You can use this pattern to:

  • timestamp test runs
  • keep audit-friendly references
  • quickly filter “today’s test data” in lists

Working with the Clipboard (Reusing Values Later)

One advanced technique is capturing a value (like a newly created Customer No.) and reusing it in later steps—for example:

  • create customer → capture customer no.
  • create sales order → select customer no. from clipboard value

Implementation details vary by version/tooling, but the goal is consistent: store a value produced in step A and reuse in step B.

Practical approach:

  • Add a step that copies a field value to a “clipboard”/variable store
  • Reference that value later in the script when selecting or validating

Verify note: Clipboard/variable mechanics can differ by version. Confirm the exact supported step types and syntax in official Page Scripting docs.

Building Robust Tests: Validation and Conditional Logic

business central consulting services

“Record and replay” is fragile without guardrails. Robust UAT automation behaves more like a test: it asserts outcomes and handles real-world variability.

Asserting Values (Validations)

Validations answer: “Did the system produce the result we expected?”

Examples of validation points:

  • After you set a posting group, validate it retained the correct value
  • After posting an invoice, validate the document status changed as expected
  • After approval, validate the approval status and posting permissions

Validation philosophy (UAT):

  • Validate business outcomes (status, totals, required fields)
  • Don’t over-validate UI cosmetics unless they matter

Conditional Steps (Only run if…)

Real environments aren’t always clean. Conditional steps let a script handle “if this exists, do X; otherwise do Y.”

Example scenario:

  • If a test customer doesn’t exist, create it.
  • If it exists, reuse it.

This is a major leap in reliability, especially across sandboxes that get refreshed or partially used.

Handling Asynchronicity (Wait steps)

Some actions are not instantaneous:

  • posting routines
  • background processes
  • workflow submissions/approvals
  • slow extensions or integrations

A “Wait” step (or equivalent) can prevent false failures where the UI hasn’t finished processing.

Rule of thumb: wait only when needed—and as short as practical—so tests stay fast.

Dealing with Optional Pages (Confirmation dialogs)

Confirmation dialogs may appear sometimes but not always:

  • “Do you want to open the posted document?”
  • “You are about to post… continue?”
  • “This record already exists…”

Optional-page handling makes scripts resilient:

  • If dialog appears, click OK/Yes
  • If dialog doesn’t appear, continue

Omni Insight :
“Most UAT automation failures aren’t ‘bugs’—they’re scripts that assumed the world would stay perfectly constant. Use validations + optional dialog handling + wait steps sparingly, and your pass rate jumps dramatically.”

A Strategic Approach: Integrating Page Scripting into Your UAT Process

Page Scripting works best when it’s not treated as a “cool tool,” but as part of a repeatable UAT strategy.

Page Scripting vs. AL-Based Test Codeunits: A Complementary Pair

You don’t have to choose one. Most high-performing teams use both.

Capability Page Scripting AL-Based Test Codeunits
Level UI-level (“what the user does”) Code-level (“what the system does”)
Best for UAT workflows, regression of processes Unit/integration tests, business logic validation
Skill required No-code → low-code AL development knowledge
Stability Can be sensitive to UI changes Generally stable if APIs/logic stable
Ideal owner Functional team + power users + QA Developers

Bottom line:

  • Use AL tests to ensure code integrity and logic correctness.
  • Use Page Scripting to ensure the user journey still works after changes.

Real-World UAT Scenario: Testing an ISV App like OmniFY Expense Reports

Imagine your organization is implementing a new expense management solution like OmniFY Expense Reports from Microsoft AppSource. Before going live, you need to ensure it works perfectly with your company’s setup: posting groups, dimensions, approvals, and finance policies.

Here’s how you could use Page Scripting to automate that UAT.

Sample Test Case: Submitting an Expense Report

Script 1: Create a new expense report

  • Navigate to OmniFY Expense Reports
  • Create a new report for a test employee
  • Validate default fields (e.g., currency, dimension defaults, required fields)

Script 2: Add expense lines and attach a mock receipt

  • Add mileage line (distance, rate)
  • Add meals line (amount, tax handling if applicable)
  • Attach a mock receipt (or simulate the attachment step if your environment limits automation around attachments/control add-ins)

Script 3: Submit for approval

  • Submit the report into workflow
  • Validate status changes (e.g., Draft → Pending Approval)

Script 4 (Approver perspective): review and approve

  • Log in as approver (or run in an approver role context)
  • Open the report
  • Validate totals, dimensions, policy rules
  • Approve
  • Validate status changes (e.g., Pending Approval → Approved)

Why this is powerful:

  • It confirms OmniFY behaves correctly in your environment, not a generic demo tenant.
  • It can be rerun after:
  • Business Central updates
  • OmniFY updates configuration changes (dimensions, approvals, posting setups)
  • It creates a living regression suite finance can trust.

Best Practices for a Successful UAT Automation Program

A practical checklist we use with clients:

  • Start from a known state
    • Use consistent test data or a scripted setup routine
  • Create self-contained tests
    • Avoid dependencies on “whatever is in the database today”
  • Embrace modularity
    • Small scripts that compose into end-to-end flows
  • Use dynamic logic
    • Power Fx for unique values, dates, and runtime adaptation
  • Handle async and optional dialogs
    • Wait steps + optional pages only where needed
  • Involve end-users
    • The best scripts reflect real workflows, not imagined ones

Taking it to the Next Level: CI/CD and Headless Test Automation

Once you have a stable library of Page Scripts, the natural next step is to run them automatically after deployments.

Introducing the bc-replay Toolset

For advanced teams, tooling like bc-replay (commonly distributed as an NPM package) can allow command-line execution of scripts—often called “headless” replay.

Conceptually, the workflow looks like:

  1. Build/deploy your extension to a sandbox
  2. Authenticate to the environment
  3. Run a suite of Page Scripts
  4. Produce pass/fail output for the pipeline

Important limitation to plan for:

Many organizations use MFA (multi-factor authentication). Headless automation can be constrained by MFA policies depending on how authentication is handled. Plan your approach with your security team and confirm tool support.

Documentation note: Include an external link to the official bc-replay package documentation and Microsoft guidance for authentication. (Insert your official URLs during publishing.)

Integrating Page Scripts into AL-Go for GitHub

If you use AL-Go for GitHub (or any GitHub Actions-based pipeline), the idea is straightforward:

  • Every time you deploy to a sandbox,
  • Run a small smoke suite of UI scripts (5–20 scripts),
  • Fail the pipeline if critical workflows break.

Benefits:

  • Catch regressions quickly (before UAT week, not during it)
  • Increase confidence in releases
  • Reduce “late surprises” right before go-live

The ROI of Page Scripting: More Than Just a Testing Tool

For decision-makers, Page Scripting is not “testing overhead.” It’s an operational advantage.

Cost Savings (reduced manual labor)

If a UAT cycle takes 40 hours manually and you run it 6 times a year, that’s 240 hours/year. Even a partial automation win (say 30–50%) can save meaningful time.

Increased Efficiency (faster deployment cycles)

Teams that can retest quickly:

  • ship smaller changes more often
  • reduce the fear of updates
  • avoid “big bang” deployments

Risk Mitigation (catch bugs early)

UAT automation is a risk-control mechanism:

  • fewer production incidents
  • fewer emergency hotfixes
  • less downtime and disruption

Improved Quality and Compliance

Repeatable tests create:

  • consistent audit trails (what was tested)
  • predictable outcomes
  • stronger controls in regulated environments

User Empowerment and Confidence

When users trust the system, adoption rises:

  • fewer workarounds
  • fewer “shadow spreadsheets”
  • better process discipline

Conclusion: Start Automating Your Business Processes Today

Page Scripting in Business Central is one of the most accessible ways to transform UAT from a manual, inconsistent activity into a repeatable, scalable process. You can start with simple record-and-replay scripts today, then build toward robust automation with dynamic Power Fx, validations, modular script libraries, and even CI/CD execution for continuous regression testing.

When done well, Page Scripting doesn’t just save time—it improves quality, reduces go-live risk, and helps your organization move faster with confidence.

FAQs

1. How long does a Business Central implementation take for a typical SMB in Canada?

For most Canadian SMBs, the Business Central implementation timeline ranges from 8 to 16 weeks. Simpler organizations moving from QuickBooks or Xero often complete implementation in 8–12 weeks, while more complex businesses with inventory, integrations, or multiple entities typically require 12–24 weeks.

The final timeline depends on data quality, customization needs, and how quickly decisions are made during the project.

2. Can we speed up our Business Central implementation without increasing risk?

Yes — but only if it’s done correctly. Implementation timelines can be shortened by:

  • Cleaning data before the project starts

  • Limiting customization in phase one

  • Assigning a dedicated internal decision-maker

  • Working with an experienced Microsoft partner

Rushing discovery or skipping testing almost always creates delays later, so speed should come from better planning, not shortcuts.

3. What causes Business Central implementations to get delayed most often?

The most common causes of delays are:

  • Poorly defined scope

  • Late changes or scope creep

  • Dirty or incomplete data

  • Slow internal approvals

  • Over-customization early in the project

In our experience, delays are rarely caused by Business Central itself — they’re caused by process and governance gaps, which an experienced partner helps prevent.

4. Do we need to stop operations during Business Central implementation?

No. A properly planned Business Central implementation runs in parallel with your existing system. Your current accounting or ERP system remains active until go-live, and most users continue working as usual.

For retail or operationally sensitive businesses, phased rollouts and blackout-period planning ensure zero or minimal disruption.

5. How much historical data should we migrate into Business Central?

Most successful implementations migrate:

  • Active customers and vendors

  • Open AR and AP

  • Current inventory balances

  • Opening general ledger balances

Migrating years of historical transactions usually adds time and cost without improving outcomes. Historical data can still be archived or accessed externally if required for audit or reference purposes.

6. Is customization required during Business Central implementation?

In most cases, no. Standard Business Central covers 80–90% of SMB requirements out of the box.

Customization or Power Platform automation should be added only when it delivers clear business value. Implementations that over-customize early tend to take longer, cost more, and are harder to maintain long term.

7. How does automation and Microsoft Copilot affect the implementation timeline?

Automation using Power Automate or planning for Microsoft Copilot can add time if done extensively during phase one. However, when planned correctly, automation is introduced strategically without delaying go-live.

The best approach is:

  • Implement core ERP first

  • Enable critical automations

  • Expand AI and automation post go-live

This keeps timelines predictable while still future-proofing your system.

8. What role does our internal team play in the implementation timeline?

Your internal team plays a major role in keeping the timeline on track. Successful implementations usually have:

  • One internal project owner with decision authority

  • Availability for workshops, testing, and approvals

  • Clear accountability across finance and operations

When internal decisions are delayed, implementation timelines almost always extend.

9. Why does choosing the right Business Central partner matter for timeline predictability?

Business Central is powerful, but partner experience determines execution speed and quality.

An experienced Microsoft partner:

  • Follows a proven implementation framework

  • Avoids unnecessary customization

  • Anticipates risks before they cause delays

  • Aligns Business Central with real business processes

This is why many SMBs choose partners like Omni Logic Solutions, a Microsoft Cloud Solution Partner with 15+ years of implementation experience across Canada and North America.

10. How do we get a realistic Business Central implementation timeline for our business?

The only way to get an accurate timeline is through a structured discovery and planning session that reviews:

  • Your current system and data

  • Number of users and entities

  • Required integrations and automation

  • Industry-specific needs

A short consultation with an experienced partner can quickly determine whether your implementation will take 8 weeks, 16 weeks, or longer — before the project even begins.

Next Steps : Talk to an Expert

Book a Free Consultation

    Get a Free Cosultation, Contact Us & We Will Reach Back Within 1 Business Day!

    Learn More