Contents · The Flow Book

Start here

The Flow Book1. Your first run2. Let the outside answer3. Keep the original answer

Build the decision

4. Give the program an input5. Name the work6. Give values a shape

Build the workflow

7. Decide what failure means8. Put the decision in its own file9. Put the pieces together

Go further

10. Work on several things11. Leave room for an answer12. Take Flow into an application

Build an application

13. Investigate a real question14. Challenge: diagnose and extend
Language reference ↗

Give values a shape

Our workflow now has two facts to consider: an amount and whether the request is urgent. A record keeps related values together and gives each one a name.

Try it · Give the input a shape
main.flow
pub type Request { pub amount: Int, pub urgent: Bool }

pub flow main(request: Request) -> Bool = request.urgent || request.amount > 100
Expected resultfalse

Read a record at the boundary

Request has an integer amount and a boolean urgent. The input object mirrors those fields under the parameter name request. Read request.urgent as the urgent field of that value.

The expression request.urgent || request.amount > 100 needs review when either condition is true. Try a small urgent request and a large non-urgent one. The exercise asks you to include the boundary amount of 100 without losing urgency handling.

Make alternatives explicit

A record groups facts that exist together. A choice describes alternatives. Instead of returning arbitrary text, we can name the two possible decisions:

Try it · Name the possible outcomes
main.flow
pub type Decision { Proceed, Review }

pub flow main(amount: Int) -> Decision = if amount > 100 { Review } else { Proceed }
Expected result"Proceed"

Decision has the alternatives Proceed and Review. A caller can handle them with match. Adding a third alternative changes what callers must consider; a misspelled text string would not carry the same structure.

Use a record when a value needs several fields. Use a choice when a value is one of several forms. Both let the type describe something meaningful about the workflow, beyond the shape of a JSON object.

Exact rules: records, choices and visibility, pattern matching.