Skip to main content

Design a Coform

Goal​

Build the short form somebody fills in to finish a step of a process, and the buttons that end it.

Where coforms live​

A process has two halves, and the rail shows both. Open a process from Processes and you get:

  • Flow — the swimlane canvas, where you draw the steps and how they connect.
  • Coforms — this list.

They are the two halves of one thing: a coform belongs to its process, travels with it into other environments, and is not a component you can add to a solution on its own.

What a coform is​

When a person reaches a user task, they read whatever the step opens — a record, a list, a report — and then press Decide. The coform is what opens then: a few fields, and the buttons that end the task.

It is not a form over a table. It has no table, and it asks only what the decision needs.

Steps​

  1. Open a process and select Coforms in the left rail.
  2. Select New. The coform opens as a page, the same way a table's form does — a coform is two lists of rows, and there is no reading two lists of rows down the side of a screen.
  3. Give it a Display name — what the person reads at the top of the panel, and what the list shows.
  4. The Coform name fills itself in from that, under your publisher's prefix: par_approve. This is what a step points at, and it is the identity — two coforms in one process cannot share one. You can type your own; the prefix is fixed beside the box, so it cannot be typed wrong.
  5. Add the Fields the person fills in. Each has a field name (the key the answer is recorded under), a label, and a data type. These are the platform's own types, so a coform gets the same date pickers, calendars and choice lists a record form has.
    • Tick Required on a field that must be filled in before any button works.
  6. Add the Outcomes — the buttons. Each has an id (what a connection names), the button text, and a style: ordinary, primary or destructive.
    • Tick Needs a comment on an outcome that must be explained. It insists on the coform's first multiline field, and it applies to that button only — which is the point: a rejection needs a reason and an approval does not.
  7. Select Save. Close takes you back to the list, and asks first if you have unsaved changes.

To change one later, select it in the list — or select it and choose Edit.

Using it on a step​

Go to Flow, select a user task, and pick the coform from Coform. The list is this process's own, so there is nothing to type and nothing to spell wrong.

If the coform has more than one outcome, each one wants its own connection out of that step: select a connection and set Taken when. The Problems panel says so if you miss one.

Outcomes are the actions​

There is no separate Done button beside them. A coform with one outcome shows one button, named whatever you called it; a coform with three shows three.

That is deliberate: "what did they decide" is the most useful line in a process's history, and a bare Done throws it away.

Renaming and deleting​

The name is what a step points at, so renaming a coform leaves any step that showed it pointing at nothing — the Problems panel reports it, and you re-pick the coform on the step. Deleting one does the same. Neither silently rewrites your diagram.

  • Design a Process — the other half: lanes, steps, connections and code.
  • Complete a Task — what the person on the receiving end sees.