20 articles written in April 2026.
For Power Apps
The fastest way to a report of your own is often one that already works. The Parsware samples come with an editable copy of each drawn design, so you can rename one, change it and publish it into your own solution, while the original stays exactly as it shipped.
Parsware Platform
A server validation rule is a plugin step that refuses a save and says why. We added one from scratch, "a claim over 10,000 needs a purchase order", then watched the editor catch a misspelt function and the form show the step's message when we saved a claim that broke it.
Parsware Platform
A claim over 1,000 needs an approval note. The form can show that as you type, but only a plugin step makes it true, because it runs on the server whatever saved the claim. We imported a spreadsheet of claims past the form and watched two rows refused with the step's message, then looked at how one script holds the limit for both sides.
Parsware Platform
A form rule runs in the browser and changes the form as you type. In the Expense Approval sample, typing "rejected" into Status shows a Rejection reason and makes it required, and approving the claim hides it again and locks the amount. Here is the form, the three rules behind it, and the one script they share.
Parsware Platform
Parsware has several places to put a rule. Form rules make a form respond as you type. Plugin steps decide what may be saved, however it's saved. Custom APIs answer other systems, scheduled jobs run on a clock, and processes carry work between people. This guide says which one to reach for, with a real example of each.
For Power Apps
A query pasted into a report lives in that one report. A saved query lives once, has a name, and can be published into a solution beside the reports that use it, so it arrives in Test and Production with them. Here's the expense totals query from earlier, published and named by a report.
Parsware Platform
BS Lang runs in two places. A form rule runs in the browser, in TypeScript; a plugin step or a Custom API runs on the server, in C#. Those are two separate interpreters of one language, so we keep them the same with one shared set of test scripts that both must pass. This is a developer's look at how that works, and at the two cases where they still disagree.
Parsware Platform
A server-side script can write a file to storage and read it back, and it can put a file into one record's File field. They're two different places for two different kinds of file. We exported expense claims as a CSV into a bucket, then attached a receipt to one claim and found it on the claim's form.
Parsware Platform
sendEmail sends a message through a mail service the environment names, just like callService. It never stops the script. It tells you whether the email went, and the script decides what to do about it. In the sample, a paid order records Sent or Not sent with the reason. Here is the call, what the mail service receives, and why an email step shouldn't refuse a save.
Parsware Platform
callService lets a server-side script post to another system, like a payment provider. The script never holds the address, only a service name. Each environment sets where that name points, so Test can use a sandbox and Production the real thing, and an environment that sets nothing reaches nothing. We took payments in a sample order app, and saw an answer, a refusal and a missing setting.
Parsware Platform
When a plugin step and a Custom API need the same rule, write it once as a solution script and import it into both. We used the Shared Server Logic sample, where an approval limit decides both whether an order saves and what an API tells a partner, then changed the limit in one line and watched both follow. Here is how import and export work, and which scripts can import.
For Power Apps
In Parsware for Power Apps, Save keeps your work and Publish releases it. Readers only ever see what was published, so you can work on a live report without anyone watching it change. Here's a change to the case sheet, saved, checked on the form, then published.
Parsware Platform
A server-side script can read more than the record it's working on. getRecord fetches one record, queryRecords and countRecords match one field, and runQuery takes a whole query with and/or filters, joins and totals. We used them in a plugin step that refuses an invoice when a customer would go over their credit limit, and in a Custom API that joins two tables.
Parsware Platform
Every Parsware script is BS Lang, but a form rule, a plugin step, a Custom API and a step in a process can't call the same functions. What each one gets depends on where it runs and what it has in front of it, a form, a record being saved, a caller or a running process. Here is each list, why it differs, and what happens when you call a function from the wrong one.
Parsware Platform
Completion helps once you know roughly what to type. The eye button answers the question before that, what can this script call at all, with every function the script can use, its arguments and a line on what it does, in a list you can search. Here is where it is, what it lists, and the one-line version on a Studio binding that inserts what you pick.
For Power Apps
A report laid out to the pixel has to survive the printer. Parsware reports print one report page per sheet, with nothing split across two, no blank sheet at the end, and no browser furniture in the margins. Here's where Print is, what it does in each place a report appears, and what comes out.
Parsware Platform
Open a bracket after a function name and the BS editor shows what the call takes, with the argument you're on in bold and, for a function with several forms, each one to page through. Shift+Alt+F tidies the whole script, keeping your comments and your line breaks. Here is what each one does, and when formatting leaves a script alone.
Parsware Platform
The BS editor offers names as you type. At the start of a line it lists the functions the script's host provides, the functions it imported from a solution script, and its own variables. After a dot it lists the value's methods. Here it is in a form rule from the Expense Limit sample, with what it offers and what it leaves to you.
Parsware Platform
The BS editor checks a script while you write it. A mistake is underlined within half a second, hovering says what is wrong, and a problems list under the script counts every error, jumps to each one and copies them all as text. Here is what it catches, and what it can't.
Parsware Platform
BS Lang is the one scripting language in Parsware, used by form rules, buttons, plugin steps, Custom APIs, processes and Studio screens. If you know a little JavaScript you can read it already. Here are variables, lists, objects, functions, conditions and loops in one short script, and the few places it differs.
