Business Central Page Scripting, What It Is and How You Can Use It

Illustration of a Business Central page with a record button and playback controls.

Your BC implementation was flawless, and all is happy in ERP land. Now, with ever increasing frequency, an update lands, an extension ships, or a setup changes, and someone has to click through “create a sales order, release it, post it, check the ledger” one more time to prove nothing broke. Next month we will ask them to do the same thing. How can we keep continuous updates (a good thing) from being disruptive while avoiding spending all our time on testing?

Page Scripting is Microsoft’s cure. It records what you do in the web client, plays it back on demand, and tells you which step passed and which one fell over. No AL, no test codeunits, no developer required to get started. Here is what it is, how to use it, where it fits in a real project, and where add-on tools take it further.

What Page Scripting Is

Page Scripting is a recorder built into the Business Central web client. You open pages, fill in fields, and run actions as you normally would, and the tool captures each step. Later you replay those steps, and BC repeats them exactly, flagging each step green (passed) or red (failed) as it goes.

A few things make it more than a macro recorder:

It understands BC, not just HTML. It captures your clicks and the actions the AL code performs in response, such as opening dialogs and pages. That also means it is not a general browser bot: it cannot drive control add-ins, embedded Power BI reports, or anything outside the web client.
It runs everywhere BC runs. Online production, online sandbox, on-premises, and Docker containers are all supported.
Recordings are plain YAML. You can save them, edit them in a text editor, put them in source control, and share them as files or links.

Microsoft positions it primarily for user acceptance testing (UAT): proving that your business processes still work after a change. That is the headline use, but as you will see below, it is far from the only one.

Diagram of the Page Scripting cycle: record, validate, save or share, replay.

Getting Access

Two permission sets control the tool, and they are deliberately separate:

Permission set	What it allows
PAGESCRIPTING – REC	Record new scripts
PAGESCRIPTING – PLAY	Play back existing scripts

That split is useful. Your key users and consultants can get REC to build scripts, while testers or a broader group get PLAY only, so they can run the suite without editing it.

User card in Business Central showing the PAGESCRIPTING - REC and PAGESCRIPTING - PLAY permission sets. — The PAGESCRIPTING – REC and PAGESCRIPTING – PLAY permission sets on a user card.

Once you have permissions, open any page (the Role Center is a good habit), select the Settings gear in the upper-right corner, and choose Page Scripting. The Page Scripting pane opens on the right side of the screen, ready to record or open a saved script.

Business Central Settings menu with the Page Scripting option highlighted. — Page Scripting lives in the Settings menu.

Recording Your First Script

The basic recording is about as simple as it gets:

Go to the page where the script should start.
Select Start new (or the New recording button). The record button turns red.
Do the task. Each action shows up as a step in the pane.
Select Stop when you are done.

Sales Order page being recorded, with captured steps listed in the Page Scripting pane. — Each action becomes a step in the pane while you record.

While recording, you can pause and resume, delete a step, drag steps into a new order, or use Record from here on any step to insert new steps in the middle.

A recording that only clicks is a demo. A recording that checks things is a test. The right-click Page Scripting menu on any field is where the real power lives:

Validate. Assert that a field, a dialog message, a row count, or a selected-row count equals what you expect. Example: after posting, validate that the confirmation message appeared, or that the posted invoice amount matches.
Copy and Paste. Page Scripting has its own clipboard. Copy the new sales order number, then paste it into a filter later, or validate against it.
Session Info. Paste the current user ID into a filter, so “My” lists work no matter who runs the script.
Add conditional steps when. Run a block of steps only when a condition holds, such as “row count is 0.”
For each. Repeat a group of steps for every row in a list.
Wait. Add a pause (in milliseconds) after the last step if a process needs breathing room.

Right-click Page Scripting menu with Copy, Paste, Validate, and conditional step options. — Right-click any field while recording to copy, paste, validate, or add conditional steps.

Two more tools save a lot of grief:

Make this an optional page. If a confirmation dialog showed up while recording but might not appear during playback, mark it optional. The steps that follow only run if the page actually opens.
Properties and Power Fx. Every validation and condition is stored as a Power Fx expression you can edit. For example, "Customer " & Today() generates a unique-ish name, and Clipboard.'SO Processor Activities - ReadyToShip' + 1 checks that a cue incremented by one.

Step menu in the Page Scripting pane with the Make this an optional page option. — Mark pages that only appear sometimes as optional.

Step Properties panel showing a Power Fx expression in the Value field. — Validation values are Power Fx expressions you can edit.

For reusable scripts, add parameters (pane menu … > Properties > Parameters). Instead of hard-coding a customer number or a document date, the script prompts for it or takes a default. You can also use Include a script to chain smaller recordings into a suite, passing parameters between them.

Dialog prompting for a script parameter value before playback. — A required parameter prompts for a value when playback starts.

Playing Back and Sharing

You can play a script three ways: right after recording (as long as the pane stays open), from a saved YAML file via Open recording, or from a shared link.

During playback you can step forward and back, rewind to the start, or use Run to here to jump to a specific step. One caution: stepping backward does not undo anything. If step 6 posted an invoice, going back to step 5 does not unpost it.

Page Scripting playback with passed steps marked green and one failed step marked red. — Passed steps get a green check. The failed validation is flagged in red.

When you are done, you have two ways to get the script out of BC:

Save downloads the recording as a YAML file. This is the one to keep in a shared folder or a Git repo.
Share > Copy Link creates a URL that contains the full recording and the playback results. Send it to a colleague, and they open BC straight into the script, with the green and red markers showing exactly where it broke.

Page Scripting Share menu with the Copy link option. — Copy link shares the recording and its playback results.

That second option is the underrated one. It turns “it doesn’t work” into a link that shows precisely what was done and which step failed.

Ways You Can Use It

UAT is the headline, but Page Scripting earns its keep in several places on a project:

Use	Who benefits	How it plays out
User acceptance testing	Key users, project teams	Record each core process once during UAT, then replay the full set before go-live sign-off.
Wave update regression	Customers, partners	Run the suite in a sandbox on the new version before the production update window.
Extension and PTE releases	Developers, consultants	Replay the affected processes after every deployment to catch side effects outside the code you touched.
Bug reproduction	Support, end users	Record the failing steps and send the share link instead of a paragraph of screenshots.
Training and onboarding	New users, trainers	Play a script slowly with the pane open so new staff members see each step in the real UI.
Demos and data setup	Presales, consultants	Script the repetitive setup (customers, items, orders) so a demo environment is ready in minutes.

Taking It into a Pipeline

For teams with a DevOps process, Microsoft ships a stand-alone player, bc-replay, as an npm package. It runs your saved YAML scripts against a BC web client from the command line, using Playwright under the hood, so the same scripts your key users recorded can run as automated tests after every build.

Flow from a key user recording a script, to a YAML file in a repo, to bc-replay running in a pipeline, to a test report.

The short version:

Install Node.js 16.14.0 or later and PowerShell 7 or later.
In a working folder, run npm i @microsoft/bc-replay --save.
Run your scripts with npx replay .\recordings\*.yml -StartAddress <your web client URL> -ResultDir <results folder>.
View results with npx playwright show-report <results folder>\playwright-report.

Authentication can be Windows (the default), AAD, or username and password, with credentials passed through environment variables. Multifactor authentication is not supported, so use a dedicated test account.

This is the part that should get consultants and developers excited. Key users own the scripts because they know the process. Developers own the pipeline. Nobody has to translate a business process into AL test code to get regression coverage.

Going Further: Add-On Solutions

Microsoft’s tool is a strong start, but it only tells you which step passed or failed. There is no video of what happened on screen, no run history, and no dashboard showing whether things are getting better or worse release over release. That is where add-on solutions built on top of Page Scripting come in.

Comparison of native Page Scripting and an add-on: only the add-on provides video, timing, run history, and multi-company runs.

BusinessCentralTesting.com is one example. It runs the same Page Scripting YAML files, so nothing you record is wasted, and adds:

Video of every run. Scrub to the exact moment a test failed and watch it happen, instead of trying to reproduce it.
Step-level logs with millisecond timing. See which action failed, why, and how long each step took.
Run history and trends. A record showing every change was tested before it reached users, which auditors and steering committees appreciate.
One-click runs across companies. Run the full suite, or only the scripts a change touches, against every connected company.
Script building as a service. If you would rather not build the suite yourself, they run discovery sessions on your processes and build parameterized scripts that follow how your team actually works.

The practical takeaway: learn Page Scripting first, because it is the foundation either way. When you need proof of every run, or a suite that someone else keeps working through each wave update, an add-on is worth a look.

Limitations and Gotchas

Page Scripting is genuinely useful, but scripts are only as good as the habits behind them. The most common ways they break, and how to avoid them:

Data drift. A script that picks “the first customer in the list” will fail the day someone adds a new customer. Create fresh records inside the script where you can, and filter lists so the value you want is first.
Starting in the wrong place. Playback starts from whatever page you are on. Always begin recording from a known spot, such as the Role Center.
Monster scripts. One 200-step script is miserable to maintain. Break it into small recordings (set up user, create customer, create order, post order) and chain them with includes.
Surprise dialogs. Confirmations that appear only sometimes will fail playback unless you mark the page optional.
Partial lists. Selected-row-count validation only works when the whole list is loaded.
Outside the web client. Control add-ins, embedded Power BI, and anything outside BC’s own UI are out of reach.
No undo. Playback does real work in the environment. Run test suites in a sandbox, not production.

Confirm playback in production dialog warning that the script may permanently alter data. — Business Central asks for confirmation before it plays a script in a production environment.

The BC Dr.’s Prescription

Start small. Pick the one process your business cannot live without, probably order to cash, and record it this week in a sandbox. Add three validations: the order released, the invoice posted, the amount matched. Save the YAML somewhere your team can find it.

Next time a wave update or extension release lands, replay it before anyone touches production. Once that first script saves you a Monday morning, you will want a suite, and once you have a suite, bc-replay is waiting to run it for you.