11 articles about Queries, in reading order.
Parsware Platform
A saved query in Parsware is a question your solution owns. Build one in the query designer from a table, the tables joined to it, the columns it returns and the conditions that narrow it, and every save is checked against the environment's real tables before anything can use it.
Parsware Platform
A saved query in Parsware is one question with one definition. A report fills its table from it, and a server script runs it by name, so correcting the question once corrects every answer that names it, in this environment and in the next one the solution goes to.
Parsware Platform
A Parsware query can answer "how many" and "how much" as well as "which". Group records by a column, count and sum them, keep only the groups that pass a test, and take the top five, all in the query designer, with the database doing the arithmetic.
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
A report prints what its saved query returns, so the query is where the work goes. A query that joins each invoice to its customer gives the Money owed report the customer's name and credit limit, and widening the query to overdue invoices changes the report without touching it.
Parsware Platform
A reporting tool outside Parsware wants your data: which tables it may read, what their columns are, pages of rows, and totals. The reporting endpoints answer exactly that, read-only, and only what the application's role may read. We pointed the front-desk dashboard at them, and ran a saved query by name.
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
Everything a custom app does in Parsware goes through one object: who's using it, where it was opened, the data their role can read, saved queries, Custom APIs, object storage and the log. We grew the visitor board with company totals from a saved query, readable visit purposes, and a button that keeps today's list as a file.
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
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
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.
