26 articles about Forms, in reading order.
Parsware Platform
Make a field required once and every form asks for it. Make it read-only on one form and it's shown but not edited there. Give it a default control and format, and every form and view shows it the same way.
Parsware Platform
When two people edit the same record and both press Save, the second save is refused instead of silently overwriting the first. Here is what each of them sees, and how to carry on.
Parsware Platform
A form is tabs, rows and sections, with a header that stays put whichever tab is open. Lay one out in the Form Designer, give a table a second form for a different team, and let people switch between them on the record.
Parsware Platform
A note is fixed text on a form, like a heading, an instruction or a warning, written in Markdown and shown beside the fields it's about. Here is how to add one, what it can contain, and why it can't be used to slip markup into a form.
Parsware Platform
A field's type decides what it stores. Its control decides how people fill it in. Turn a yes-or-no field into a switch with its own words, show a date in the Persian calendar, and put a control you built yourself on a form.
Parsware Platform
A timeline puts every call, email, meeting and note about a customer in one column on their form, newest first. Filter it by kind, start a new one already filled in, and set it up in the Form Designer from any table that points at the record.
Parsware Platform
Every table keeps four stamps for you, Created On, Created By, Modified On and Modified By, plus an Owner. Put them in a view or on a form and people see names and dates, not ids, with nothing to set up.
Parsware Platform
In Parsware, saving a table is applying it. The database table and its columns exist before the screen comes back, a form and a view come with it, and a change that would cut stored data short is refused.
Parsware Platform
Every Parsware record has an owner, a person or a team, and the owner decides who can see it once access rules are set up. Hand a record on from its Owner field on the form, pick User or Team, and save.
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
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
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.
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
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 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 plugin step is registered against a table, a write, a stage and an order, and the stage decides the most. We put a second step behind the order-stock sample's own, watched a refusal before the write undo the stock the first step had taken, then moved the same refusal after the write and watched the order line stay.
Parsware Platform
The answer to "is there enough stock?" isn't on the order line. It's on the product. We saved three order lines against a product with 10 in stock and watched a plugin step read the product, take the stock and log the movement, or refuse the line, then read the script that does it.
Parsware Platform
Not every server rule refuses. This one approves. A claim of 50 or less is marked approved as it's saved, by a plugin step that sets a value on the record before it's written. We saved a taxi fare and a hotel bill, watched only one come back approved, then watched the sample's own lock stop the approved one being edited up.
Parsware Platform
When a process step reaches a person, they read what it opens and then decide. A coform is what they decide on: a few fields and the buttons that end the step. We built one in the parallel sign-off sample, put it on a task, and routed each button its own way. The field types now read as words.
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 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 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
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.
