Lesson 6 - Add Your First High-Leverage Workflow

This is the lesson where the HarborFlow tool stops being “an internal CRUD app” and starts becoming real operational software.

Maya does not need ten workflows. She needs one workflow that removes obvious coordination overhead from the exception process.

Keep editing the same blueprint.toml. This lesson adds a workflow section and wires it into the existing request detail page.

Pick One Workflow That Matters

A good first workflow is one that:

• happens often
• creates confusion when done manually
• is easy to explain
• has a visible effect in the product

For HarborFlow, a strong first workflow is:

• when an exception request is approved, move it forward and notify the right internal owner

Keep The Workflow Narrow

Do not automate the whole company in one lesson.

Start with one event and one useful outcome:

• approval changes status
• a notification is sent
• a follow-up field is updated

That is enough to make the product feel meaningfully better than spreadsheets and Slack.

HarborFlow Example

Maya might define a workflow like:

• trigger: manual approval action on the request detail page
• step 1: update status from reviewing to approved
• step 2: send a notification to ops

That gives the app:

• visible workflow progression
• a clearer approval path
• less manual follow-up

Here is a concrete first version:

[notifications]
default = "console"

[[notifications.adapters]]
name = "console"
type = "console"

[workflow.ApproveExceptionRequest]
description = "Approve an exception request and notify operations."

[workflow.ApproveExceptionRequest.trigger]
manual = true

[[workflow.ApproveExceptionRequest.steps]]
type = "query"
entity = "ExceptionRequest"
action = "update"
[workflow.ApproveExceptionRequest.steps.where]
id = "{{ variables.data.record.id }}"
[workflow.ApproveExceptionRequest.steps.data]
status = "approved"

[[workflow.ApproveExceptionRequest.steps]]
type = "notify"
adapter = "console"
body = "Exception request approved: {{ variables.data.record.title }}"

Then expose it from the detail page with an action bar:

[page."/requests/:id".actionBar]
statusField = "status"

[[page."/requests/:id".actionBar.actions]]
label = "Approve Request"
workflow = "ApproveExceptionRequest"
style = "primary"

Using the console adapter is enough for a first pass because you can verify the workflow wiring locally before you switch to Slack or email.

Why This Matters

This is often the moment when stakeholders stop seeing the tool as a prototype.

At HarborFlow, the difference is simple:

• before: someone approves in Slack and hopes the right person notices
• after: the request status changes in the system and the next owner is notified

That is operational leverage.

Lesson Output

By the end of this lesson, you should have:

• one workflow tied to a real business transition
• one automation step with visible value
• a stronger case for rolling the tool out to the broader team

Use Workflows & Notifications for more step types and adapter options.

What Changes In blueprint.toml

In this lesson, you are adding automation-related sections:

• add a [notifications] block and at least one adapter
• add a [workflow.ApproveExceptionRequest] definition
• add workflow steps to update data and send a notification
• add an action bar to the detail page so users can trigger the workflow

This is the first lesson where a user action leads to a workflow-backed state change instead of only CRUD behavior.

Zebric Concepts In This Lesson

• Workflows: manual triggers and multi-step automation
• Notifications: console, Slack, or email adapters for alerts
• Pages: action bars expose workflows in the UI
• Entities: workflow steps update entity state as part of the business process

Next Lesson

Continue to Lesson 7 - Polish With Real Feedback.