Lesson 5 - Add Permissions and Guardrails

This lesson is where the HarborFlow tool becomes safe enough to use beyond Maya’s own laptop.

The first version probably runs with broad access. That is fine for prototyping, but not for internal rollout. Now the tool needs basic guardrails.

Keep editing the same blueprint.toml. In this lesson, you will add auth settings and tighten access around the pages and entity you already created.

The Goal

By the end of this lesson, the learner should know:

• who can submit requests
• who can review requests
• who can approve unusual cases
• which pages should require authentication

Start Simple

You do not need a perfect enterprise permissions model.

For HarborFlow, a good first cut is:

• account managers can create requests
• ops managers can review and update requests
• directors can approve high-priority exceptions
• the app requires sign-in for internal use

Add Page-Level Authentication

Require authentication on the working pages so the tool is not effectively public:

[page."/"]
title = "Customer Exception Requests"
layout = "list"
auth = "required"

This is the fastest way to move from demo to internal application.

If you have not enabled authentication yet, add a minimal auth setup before requiring sign-in on your pages:

[auth]
providers = ["email"]
trustedOrigins = ["http://localhost:3000"]

[page."/sign-in"]
title = "Sign In"
layout = "auth"

Without that setup, auth = "required" will describe the right intent but not give the learner a complete sign-in path.

Add Entity Access Rules

Then tighten entity access so the right people can create, read, or update records.

The important decision is not just “who can log in?” It is “who can change workflow state?”

For HarborFlow, Maya wants:

• broad internal visibility
• narrower update rights
• explicit approval ownership for exceptional requests

One reasonable first cut is:

[entity.ExceptionRequest.access]
read = true
create = true
update = { or = [{ "$currentUser.role" = "ops_manager" }, { "$currentUser.role" = "director" }] }
delete = { "$currentUser.role" = "director" }

That is still simple, but it already creates a meaningful distinction between people who can submit work and people who can change workflow state.

If your process needs tighter controls, start asking questions like:

• should submitters only see requests they created?
• should reviewers be able to edit every field or only status and notes?
• should directors be the only people allowed to approve high-priority requests?

HarborFlow Guardrail Questions

Use questions like these:

• should submitters be able to edit requests after review starts?
• should every employee be able to see every request?
• who can move a request from reviewing to approved?
• do rejected requests need a visible reason?

These questions make the blueprint more credible because they match the real concerns of internal rollout.

Keep The First Version Defensible

The right outcome for this lesson is not “perfect permissions.” It is:

• the app is no longer accidentally open
• the review flow has clear ownership
• the team can use the tool without obvious security objections

Lesson Output

By the end of this lesson, you should have:

• authenticated pages
• basic entity access rules
• a clearer understanding of who owns each step in the workflow

Use Security & Authentication for the exact access-control patterns Zebric supports.

What Changes In blueprint.toml

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

• add an [auth] block if the app does not have one yet
• add an auth page such as /sign-in
• change working pages from public or optional auth to auth = "required"
• add [entity.ExceptionRequest.access] rules for CRUD behavior

This is the lesson where the blueprint stops being a local demo and starts becoming an internal application.

Zebric Concepts In This Lesson

• Authentication: page-level sign-in requirements and auth pages
• Access Control: entity-level read, create, update, and delete rules
• Pages: auth requirements now shape who can reach the workflow UI
• Entities: access rules define who can change workflow state

Next Lesson

Continue to Lesson 6 - Add Your First High-Leverage Workflow.