38 articles about For Power Apps, in reading order.
For Power Apps
The reading list for Parsware for Power Apps, the managed solution that adds pixel-perfect reports and drawn screens to Power Apps. Every planned article in order, linked as each one is published.
For Power Apps
Parsware for Power Apps is a managed Dataverse solution that adds two things to model-driven apps. Reports laid out to the pixel and bound to your tables, and screens you draw and place on a form. It runs entirely inside your tenant, and your data never leaves it.
For Power Apps
Parsware for Power Apps arrives as three managed solutions. The runtime goes into every environment and goes in first, the designer only into development, and the samples wherever you want to try things. This is the whole install, in the maker portal or with the Power Platform CLI.
For Power Apps
A Parsware for Power Apps licence is one line of text, signed for your tenant and the environments it covers. You paste it into a form in the Parsware app, and the form tells you what the key covers before you save it. Nothing is sent to us to check it.
For Power Apps
Parsware for Power Apps installs two model-driven apps. Parsware Studio is where makers draw reports and screens, and it only exists in development. Parsware is what every environment gets, and it starts almost empty on purpose, because the reports and screens your users open belong in your own apps.
For Power Apps
The Parsware Samples solution brings two small tables, eight finished reports, two Studio apps and an app that opens them. The tables arrive empty, because a solution carries components and not rows, so one page fills them with 200 rows each. Here is what's in it and how to fill it.
For Power Apps
A Parsware report is a page you draw and bind to a Dataverse table. This walks through the whole loop once in Parsware Studio. Create the design, name the table it reads, point a repeating row at it and bind two columns, and you end with 200 real rows on eight printed pages.
For Power Apps
A Parsware report can read a Dataverse view instead of the whole table. The view decides which rows, in what order and with which columns, and it's something your makers already know how to build. Here's a report of urgent cases, filtered and sorted by a view.
For Power Apps
A view returns rows and can't add them up. For totals, counts and averages by group, a Parsware report reads a FetchXML aggregate, so Dataverse does the arithmetic and the report prints the answer. Here's a table of expense totals by currency and status, from one pasted query.
For Power Apps
Dataverse stores a lookup as an id and a choice as a number, and neither belongs on a printed page. A Parsware report prints the related record's name and the choice's label instead, with no extra work. Here's a list of cases with the contact each one belongs to and its priority.
For Power Apps
A Parsware report can sit on a model-driven form, beside the record's own fields, and show only that record. One setting on the report's dataset does the narrowing, and one component on the form does the showing. Here's a case sheet on the Case form.
For Power Apps
One Parsware component on a form can show a different report for each record. It reads the report's name from a column, and falls back to a default when the column is empty. Here the Case form shows an urgent-case notice for one case and the ordinary case sheet for the rest.
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.
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.
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.
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.
For Power Apps
A model-driven form is a column of fields. Sometimes a record needs something else beside them, such as guidance, a checklist, or a panel with its own buttons. With Parsware you draw that part as a Studio screen and put it on the form, where it sits with the record's fields and moves between screens without the form reloading.
For Power Apps
Some values are easier to pick than to type. A drawn field is a Studio screen placed on one column of a model-driven form. It shows the column's value and writes it, and the form saves it like any other change. Here's a contact-channel field with three buttons in place of a text box.
For Power Apps
A drawn field can work with more than the column it sits on. Bind up to three more columns to the same Parsware Runtime component, and the screen reads them all and writes any of them by name. Here, choosing a contact channel also fills in the case's next step.
For Power Apps
A drawn screen can load real Dataverse rows when it opens, count them, chart them and list them. Here, a panel on the Case form shows how many cases there are at each priority and the five newest ones, read live as the signed-in user.
For Power Apps
A screen on a form doesn't have to fit everything in its section. It can open a card in a modal over the whole page, or slide one in from either side as a drawer, and close it again. Each card is drawn once, beside the screen, and opened by name.
For Power Apps
One line in a button's Pressed opens a different published design over the form, a report in Power Apps' own dialog or a Studio app in its side pane, with the record you're on passed along. Here is openDesign, and how it differs from navigate and showModal.
For Power Apps
Everything a drawn screen does is written in BS, in a code editor inside Parsware Studio. The editor knows your Dataverse environment, so it offers your tables, then their columns, as you type, and it underlines a mistake before you save. Here is how to use it.
For Power Apps
Power Apps replaces a broken code component with six words, "Error loading control", whatever went wrong. The Parsware Runtime control says what is wrong instead, in its own space on the form, and the form designer shows it before you save. Here is every message, and what to do about each one.
For Power Apps
Describe a screen in a sentence and the Parsware designer draws it, on your own Dataverse table, with the scripts that make it work. Here is a case triage screen with a count, a search box and a button on every row, generated in about twenty seconds, then changed by hand.
For Power Apps
Every Parsware report and screen is drawn in one designer, which runs as a page inside the Parsware Studio app. This is a tour of it, from the list you open a design from to the toolbar, the layers, the components, the canvas and the properties panel, and what changes between a report and a screen.
For Power Apps
Wherever the Parsware designer needs something from your Dataverse environment, a table, a view, a saved query or a column, it offers a list read from that environment rather than a box to type in. Here is every one of those pickers, what each lists, and the few places you still type a name.
For Power Apps
A top bar, a menu or a footer that appears on every screen should be drawn once. In the Parsware designer that is a component, a main drawing with copies placed on each screen, and changing the main one changes every copy. Here is how components work in a Power Apps design, using the Starter app that ships with the samples.
For Power Apps
A Parsware report can be written in Persian or Arabic. Type the words and each text box turns right to left on its own; lay the page out from the right, and the preview prints it the way a Persian or Arabic reader expects. Here is a report turned into Persian in a few minutes, and what follows the reader's language on a screen.
For Power Apps
Describe a report in a sentence and the Parsware designer draws it, bound to your own Dataverse table. It runs on an AI Builder prompt in your tenant, with no key and no outside service. Here is a case list with a page count, column headings and a total, generated in about twenty seconds, then corrected by hand.
For Power Apps
A top bar drawn in one design can be placed in every other design in the environment, and changing it once changes every copy. Publishing now puts each design's drawing in your solution too, so a set of shared parts travels with it and Load from solutions makes them designs again on the other side, with the links between them intact.
For Power Apps
A published Parsware design is an ordinary component of your own solution, so it moves from development to production the way everything else in Power Apps does. Export the solution as managed and import it. Production needs the Parsware runtime and nothing else. Here is a report taken from one environment to another, every step pictured.
For Power Apps
A new release of Parsware for Power Apps is the same managed solutions at a higher version, imported over the ones you have. Nothing is uninstalled, and your designs, your licence and your data stay where they are. Here is what to import, in which order, and how to check it landed.
For Power Apps
Parsware for Power Apps runs inside your Dataverse environment. Your records are read in the browser as the signed-in user, and your designs are stored in Dataverse. The licence check makes no call. One request can leave, near a paid licence's expiry, and it carries the licence and nothing else. Here is what we measured.
For Power Apps
When a paid Parsware licence passes its date, nothing stops. Reports and screens keep working for your users, the designer keeps working for your makers, and makers see a notice that renewal is due. A trial is different, because a trial is meant to end. Here are both, pictured with expired keys.
For Power Apps
Power BI paginated reports and Parsware reports both produce a document laid out to the page, and both can read Dataverse. They are built for different jobs. Here is where each one fits, what each costs to read, and when you would use both.
For Power Apps
A canvas app and a Parsware Studio screen are both screens you design yourself, and both can sit on a model-driven form. They behave very differently once they're there. Here is what each one is good at, and how to choose.
For Power Apps
Parsware Platform and Power Apps are both platforms for building business applications out of tables, forms, views, processes and reports. They differ in where they run, how they're priced and what they connect to. Here is an honest comparison for teams choosing one, and when the right answer is to keep Power Apps.
