Answering the phone, functionally
Summary
By adding a method to the builder, the workflow can call itself using : Note the addition of a counter so the code can give up after a certain number of times asking the caller to press a key. Offer to talk to elves, or take a mesasge keyPress = waitForKeypress "Please press 1 to talk to one of our elves, or 2 to leave us a message" 1 keyPress | listQueuesAndWaitForResponse() | TakeMessage "Please leave your message after the beep" // Strictly here we should repeadly read the message using recursion, but for conciseness just hangup | _ Hangup Lammy whips out a quick test, writing a small harness that takes a call program, and a list of key presses, and runs the workflow, listing out progress and what is returns at each step: Lammy tries out the different scenarios to make sure everything is working as expected: takeCall (DateTime(2017,12,24)) |> runIt [ ] // Complete: Hangup "Im sorry, we are now shut for the rest of year, happy holidays !" Lammy happens to have an existing Asp.net core 2 C# site, so he adds the F# as a class library, and uses: He configures the Twilio number to send webhook calls to the action url, and hes away ! He plans to write this, and get rid of the mutable state by putting it in an Agent, but runs out of time due to his toy making workload (nothing to do with the Eggnog I can assure you). There are lots of ways Lammy could extend this approach: • He could use an Agent to host each individual call, and the receive with a timeout feature would be ideal for clearing up.