53 articles written in October 2026.
Parsware Platform
On a portal, the people who look after a customer's account are the customer's, not yours. One of them starts a company, invites colleagues, decides who else may manage it, and removes people who leave, all from a page you drew. We watched an invitation go out, a colleague join and see the company's cases at once, and an Owner hand over the keys.
Parsware Platform
One case, followed from both sides: a customer raises it on the portal, the support team answers it inside the platform, the customer replies with a photo, and the status says whose turn it is at every step. The customer and the team never share a screen, and each one sees only what is theirs to see.
Parsware Platform
A list of records on a portal page, without drawing the list: the platform's own grid, with the columns a view decides and the rows a Custom API returns. We put one on the service desk, picked its table, view and API in the designer, then added a column and watched it arrive empty until the API was told to return it.
Parsware Platform
A visitor on a portal can raise a case. Can they correct it later, and send the document your team asks for? On the service desk they can now: change the subject and the urgency, add a note and attach a file, all in one save through one Custom API. The contract decides which fields a visitor may touch, and the file follows the same rule as the record.
Parsware Platform
On a portal, every visitor reaches the same table through the same Custom APIs, and each must see only their own company's rows. One rule on the table does it, for reads and writes alike, without a filter in any script. We put two companies' cases side by side, asked for the other company's case by its id, looked at the rule, and switched it off to see what it was holding back.
Parsware Platform
A portal visitor can protect their own account with an authenticator app, from a page you drew. We turned it on for one visitor: scanned the code, saved the recovery codes, signed out, came back with a code from the app and then with a recovery code, and saw the account from the Admin Control Center.
Parsware Platform
A portal that signs visitors in has a sign-in page of the platform's own. You can draw yours instead, in the same app as the rest of the portal, and the password still goes only to the platform. We switched the members portal back to the standard page, then looked at how its drawn one is made: four settings on the portal, nine shared cards, and one function call.
Parsware Platform
A portal that signs its visitors in gives each of them an account of their own: created on the portal, confirmed by email, with a name, a photo and a password they can reset. We published the members sample, signed up as a new visitor, tried to sign in too early, confirmed the address, changed the photo and the name, forgot the password, and found the account in the Admin Control Center.
Parsware Platform
A public form that creates a record, from somebody with no account, protected from scripts by a moment's proof of work rather than a puzzle. We published the contact form sample, sent a message with a document from a private window, found it in the Messages app, and turned the one tick off to see the other side.
Parsware Platform
A public site is several pages, one bar and a menu that follow you between them, and here a carousel and a second language too. We published the Orchard Lane sample, moved between its pages in English and Persian, and opened it in the designer to see the bar that knows which page it's on and the carousel that tells the page when to move on.
Parsware Platform
A public page drawn in the Studio: a hero with a picture under the accent colour, a band of three cards that wraps on a narrower screen, a pricing band whose cards line up, and a top bar drawn once and placed on every page. We opened the landing page sample in the designer and looked at how each part is made to work at every width.
Parsware Platform
Any Studio app can be published at a web address of its own. One panel says which app, which address, who can open it, and which screens a stranger may see before signing in; one tick puts it on the internet, and the same tick takes it off. We published the landing page sample and opened it on a desktop and a phone.
Parsware Platform
A portal is a Studio app published at an address of its own, for people outside your organisation: customers, partners, the public. It reads only through Custom APIs, its visitors are portal users rather than platform users, and a rule on the table decides whose rows each one sees. We published the service desk sample, signed up as a customer, started a company, raised a case, and saw it from the inside.
Parsware Platform
When a trial runs out, nothing is deleted and nobody is locked out. Everyone can still sign in, read and export; only changes stop, and the data is kept for 60 days. We let Tailspin Toys' trial end while its administrator was working, watched a save refused and the units still readable, then subscribed and carried on where it stopped.
Parsware Platform
Every list in the Admin Control Center has the same tools: a search box, a Sort button that orders by several columns, and a Filter that asks AND/OR questions. We used all three on the Solutions list, and fixed a list that sorted Unmanaged before Managed and asked for a number to filter by.
Parsware Platform
Apps and integrations keep their files in object storage: exports, uploads, documents too big for a record. Storage in the Admin Control Center shows every bucket, what is in it and how much room it takes, and clears out files nothing points at. We looked inside Northwind's finance bucket, uploaded an invoice into one of its folders, and previewed a sweep.
Parsware Platform
Each customer is a tenant: its own people, environments and data. The people who run a deployment can switch a tenant's sign-in off and on again from Tenants. We deactivated Tailspin Toys while its administrator was signed in, watched the sign-in refused, and switched it back on to find everything where it was.
Parsware Platform
One place to read every recorded change in an environment: who made it, to which record, and what each field was before and after. We read Development's log, narrowed it to one table, then to one account's history, then to what processes changed on their own.
Parsware Platform
There is no forgotten-password email for the people who use the Shell and the Admin Control Center: an administrator sets a new password and hands it over. We reset Alex Morgan's while Alex was signed in, and watched what Alex saw: the open tab signed out, the old password refused, the new one working.
Parsware Platform
A new phone doesn't need an administrator. Alex Morgan signed in with a recovery code, moved two-step sign-in to the new phone from Sign-in security, and got ten new codes. For the person with no codes left, an administrator resets the authenticator and the next sign-in sets one up again.
Parsware Platform
Every account that signs in to the Shell or the Admin Control Center needs an authenticator app as well as a password. We followed Alex Morgan's first sign-in: the setup screen, a code refused because it was out of date, ten recovery codes, and the next sign-in asking for a code.
Parsware Platform
The unit policies need an organisation to measure against. We built one in the Organisation app (Head Office with a North and a South region), put three people in it, and gave Jordan read access on My unit and below. From Head Office, Jordan sees the accounts both regions create, and nothing owned outside the chart.
Parsware Platform
A list that hides rows is only safe if every other way in hides them too. We signed in as Robin, who may read claims only in his own units, and tried the search box, a claim's address and the record API directly. Each gave the same answer as the list.
Parsware Platform
A role says what someone may do with a table; the policy beside each permission says which of its records that reaches. We narrowed Jordan's read on accounts from every record to Mine and my teams', handed an account to the team, and Jordan's list went from a hundred accounts to four.
Parsware Platform
A team is a group of people that records can belong to, and it can hold a role. We put Alex and Jordan in Field Sales North, gave the team the Field Sales role, and watched Jordan's open session gain New on its next refresh, with no sign-out.
Parsware Platform
One app, two roles. We copied Field Sales into a read-only role, gave it to Jordan, and opened the same Accounts list as Alex and as Jordan: the same records, with and without the commands to change them.
Parsware Platform
A new user is an email, a name and a password you hand over yourself. We added Alex Morgan, had a short password refused, gave Alex the Field Sales role, and watched their first sign-in open on the one app that role is shared with.
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
Packing and uploading a control for every change is slow. In a development environment, register its running dev server instead: save a change, refresh the form, and it's there. We fixed the badge field's dash this way, then packed 1.1.0 when it was right.
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
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 control does nothing until a form uses it. In the form designer, select the field, choose the control under Custom Control, and save. We put the badge field on the Visitor form, where reception now types b-2210 and the form saves B-2210.
Parsware Platform
A field sometimes needs an editor the platform doesn't ship. A custom control is one React component that stands in for it: it shows the field's value, reports every edit, and leaves saving to the form. We built a badge-number field for the front desk outside the repository, packed it into one file and installed it.
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.
Parsware Platform
When a screen needs something tables, forms and views can't say, you write it in React. A custom app is built on your own machine with two downloads from the help site, packed into one file, uploaded once, and opened from the Shell like any other app. We built a visitor board for reception.
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 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
At the end of the month, finance wants the expense claims as a CSV file it can fetch. A Custom API builds the file from the claims table and puts it in object storage, where it stays until somebody collects it. We called it from finance's own system and found the file in the Storage screen.
Parsware Platform
A registered application doesn't send its secret with every call. It trades it, once an hour, for an access token, and sends that. Here is the one request that gets one, what is inside it, how to use it, and what each refusal means.
Parsware Platform
Before another system can call Parsware it needs an identity of its own: an app registration, with a client id, a secret, the scopes it may use and the role it holds. We registered a front-desk dashboard that reads visitors and nothing else, and looked at what each of those choices decides.
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.
Parsware Platform
A Custom API doesn't have to answer JSON. Declare HTML and its script writes a page: here, a receipt for one booking that another system can drop into a confirmation email or open in a browser. And because the page is built from what a guest typed, every value goes through htmlEncode on its way in.
Parsware Platform
A Custom API gives another system one address to call that keeps its shape while your tables change. We built one from nothing: the contract, the script behind it, the OpenAPI description it generates, a call from outside, and a second version answering beside the first.
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
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
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
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 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
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.
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.
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
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
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.
