26 articles about Solutions, in reading order.
Parsware Platform
How Parsware names your work, packages it and moves it between environments. Create a publisher and its prefix, build a solution in development, export it, import it into test as a managed solution, and uninstall it cleanly.
Parsware Platform
Deleting a table in Parsware removes its definition and its data from the environment, so the platform first checks what still depends on it. A lookup that points at the table, or an app that shows it, blocks the delete and is listed by name.
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.
Parsware Platform
The same solution in two environments should call two different payment services, a sandbox in one and the real thing in the other, without anybody editing a script. That's what an environment variable is for. We installed one solution in two environments, gave each its own value, and saved the same order in both.
Parsware Platform
A process moves between environments the way everything else does: in its solution, with its table, its form, its app and its roles. Import publishes it, and uninstall takes it out again. Trying that with a run still waiting, we fixed what happens to the run: it's now stopped, and its history says why.
Parsware Platform
The whole path a change takes in Parsware: build it in Development, raise the solution's version, export one file, and import that same file into Test and then Production, where the new version replaces the old one. Plus the habits that keep the three environments in step.
Parsware Platform
Every Parsware environment keeps its records in its own database schema. A table name can mean different things in two environments, a record in Test can never show up in Production, and a query aimed at the wrong environment fails instead of returning somebody else's rows.
Parsware Platform
Creating a Parsware environment takes a name and a tier. The address is made from the name, the tier can't be changed later, and deleting the environment removes its schema, its solutions and everything that was built in it.
Parsware Platform
A solution only carries what's in it. When something it needs was built somewhere else, the import into Test is refused. Dependencies shows what's missing, Add existing puts it in, and Remove from solution takes things out without deleting them.
Parsware Platform
A managed solution doesn't overwrite the tables it touches. It adds a layer on top, so uninstalling it takes away exactly what it added: a table it brought, a column it put on Account, and nothing you built yourself.
Parsware Platform
Two publishers' solutions can sit side by side in one environment, and one can build on the other. Parsware checks the order both ways: an import that needs a table the environment doesn't have is refused, and so is an uninstall that would take away a table another solution still uses.
Parsware Platform
A solution can carry rows as well as tables. Each table's Seed data view decides which rows travel, and says what they are: configuration the solution needs, which every import brings, or demonstration data, which comes only when you ask for it, and never into Production.
Parsware Platform
One solution, a different setting in every environment. The declaration of an environment variable travels with the solution; the value stays where it was set. We followed two variables from Development through two upgrades of Test and into Production, and watched what each import changed and what it left alone.
Parsware Platform
Every business application ends up talking to something else: an accounting package calls in, a payment provider gets called out to, files go somewhere other people can fetch them. This is the map of how Parsware does each of those, and of the series that walks through them one at a time.
Parsware Platform
Every table, view, form, query, report and process you build in Parsware is a plain JSON document underneath, and every kind has a published schema. So a document can be written in an editor, by a script or by an AI assistant, checked before it's sent, and the platform checks it again the same way the designer's own are. We wrote a saved query by hand.
Parsware Platform
A web resource is a file stored in a solution and served by the platform: a stylesheet, a script, an image, a page. We built the printable visitor badge as four of them, a page with its stylesheet, script and logo, and opened it at its address.
Parsware Platform
A custom app or control is part of its solution, code and all. We exported Visitors from Development with its visitor board, its badge field and its web resources, imported it into Test, and watched an altered copy of the same file get refused.
Parsware Platform
Who may open an app, what they may do with a table, and which of its records they see are three separate questions in Parsware, answered by users, roles, teams and policies. This is the map: what each piece is, where it lives, and which question it answers.
Parsware Platform
Every Parsware designer draws a plain text file: a process, a screen, a report, a table. The file has a published schema, the platform checks it the same way whoever wrote it, and so it can be read, compared, generated and reviewed like any other code. Why that matters, shown on the capital planning approval process.
Parsware Platform
The website you're reading sells Parsware, and the business behind it runs on Parsware: our leads, plans, subscriptions, trials and support tickets are tables in three ordinary solutions, and the site reaches them only through named Custom APIs. Here is what that looks like, and what it means when you start a trial.
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
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
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.
