Declare a kind of case and author the flow that moves it

You have been asked to “put the hardship applications into Kiln”. Nobody has told you what that means, and you have an empty tenant.

By the end of this you will have a kind of case your organisation can raise, one running automatically when it is raised, and a record of what it did that you can show the person who asked.

About forty minutes. Nothing here is thrown away afterwards.

Before you start

Kiln has modes, and knowing which one you are in saves most of the confusion of the first hour. They are the buttons across the top of the window, beside your organisation’s name: WORK, BUILD, OPERATE.

Build is where you declare things. Work is where people do the work. Operate is where you watch what happened.

The left-hand menu changes with the mode. In Build it is grouped: Documents (Content, Styles, Layouts, Templates, Transformers), Automation (Flows, Datasets, Registers, Connections, Inboxes) and Definitions (Case types).

You will cross Build, Work and Operate, in that order, twice.

[screenshot: the mode switcher with BUILD selected, and the Build menu below it]

1. Declare what the case is (Build, Case types)

Start here rather than with the flow. A flow moves something, and until that something exists there is nothing to move.

Click BUILD at the top, then Case types in the left menu, under Definitions. You get a list with four columns: name, version, updated, created. It is empty on a new tenant.

Click New, at the top right of that list. The editor opens as a tab.

Give the case type three things.

A name, which is what people will call it. “Hardship application”.

A noun, which is the word for one of them. The product speaks it back to you everywhere it would otherwise say “case”, so pick the word your team already uses. If your team says “application”, say application.

Stages, which are the positions one can be in. Resist the urge to model everything: three or four is usually right, and you can add more once you have watched real ones move. A first pass that works is Received, Under assessment, Decided.

Then declare the fields a reviewer records. These are what somebody writes down while working one, not the data it arrives with.

Now publish it. The Publish button is at the top right of the editor, and it is the only one with a colour fill, because publishing is the act that matters on this screen.

Nothing can raise a case of a kind that only exists as a draft, which catches everybody once. And once it is published that button is replaced by Create Draft: a published version keeps serving live work, and what you edit next is a draft beside it. You will use that in step 3.

2. Raise one by hand (Work)

Click WORK at the top, then Cases in the left menu. Click Report a case, at the top right. Pick the kind you just published, and fill it in badly on purpose.

Your new case type also appears in the Work menu by name, above Cases, once it has something in it.

This step looks like a detour and it is the most valuable forty seconds in the guide. You are looking at the thing your flow will act on, in the form a reviewer will see it, before you have written anything that assumes its shape. Most of the mistakes people make in step 3 come from authoring against an imagined case.

[screenshot: a raised case, Work mode, showing stage and fields]

3. Author the flow (Build, Flows)

Now the automation.

Click BUILD, then Flows in the left menu, under Automation. Click New. The canvas opens, empty, with a toolbar across the top: Signature, Variables, Policies, SLAs, What this flow can reach, Run, Versions.

A flow starts with a trigger. Choose “Case opened” and narrow it to your kind. The narrowing matters: a trigger that fires on every case of every kind will run your flow against other people’s work, and you will find out weeks later.

Then add what should happen. For a first flow, two nodes is plenty:

• Grade the case’s severity, so it arrives already sorted rather than waiting for somebody to read it.
• Send a notification, so the right person knows it exists.

Keep it to that. A first flow that does two things and runs is worth more than one that does seven and is still in draft on Friday.

Publish the flow, with the same coloured Publish button at the top right.

The fiddly bit, said plainly

Your flow refers to the case’s fields by their key, not their label. The key is minted when you add the field and never changes, which is exactly what stops a rename breaking every flow that mentions it. It also means the name in your flow and the name on the screen are not always the same string.

You will find the key on the field in the case type. When a node cannot find a value, this is the first thing to check, and it is the single most common reason a first flow does nothing.

4. Raise another one and watch (Work, then Operate)

Raise a second case. This time the flow runs.

Click OPERATE at the top, then Runs. Click the run. You will see each step, what it was given and what it returned.

[screenshot: a run in Operate, steps expanded]

That last part is worth pausing on, because it is the thing that makes the rest of this trustworthy. The run is not a log line saying the flow succeeded. It is what each step actually received and actually produced, kept, so that when somebody asks why a case was graded the way it was in March, the answer is a record rather than a recollection.

5. Show somebody

You now have three things to point at: the kind of case, in the words your organisation uses. A case of that kind, raised and graded without anybody intervening. And the run that did it, step by step.

That is the whole loop, at its smallest. Everything else in Kiln is this loop with more in it.

Where to go next

Your flow needs data from another system. That is a Connection, and the flow gets it through an integration step rather than you copying it in.

Your flow needs your own reference list, such as approved suppliers, current vehicles or the sites you operate. That is a Register: a list your organisation maintains inside Kiln, which a flow can look up by the identifier you already use.

You want to change the flow now that it is live. Click Create Draft in the flow’s editor, which leaves the published version running while you work. Then read Prove a change before you publish it, which is the whole of what to do next. Do not edit a published flow and hope.