Core Concepts

Eddy helps teams turn complex, multi-person processes into clear, structured digital workflows. Before diving into the details, it helps to understand the three main areas of Eddy and how they work together.

The Three Pillars of Eddy

1. Workflows — Design Your Process

A workflow is a blueprint for how work should flow through your organization. Think of it as a map that shows:

• What steps need to happen (stages)
• In what order they happen (transitions)
• Who does what at each step (roles)
• What information needs to be collected (blocks)

For example, an employee onboarding workflow might have stages like "Submit Details" → "Manager Review" → "HR Processing" → "IT Setup" → "Complete".

You design workflows once, then run them many times.

2. Sessions — Do the Work

A session is a single run of a workflow. When someone starts a workflow, they create a session.

Think of the difference this way:

• The workflow is the recipe
• The session is actually cooking the meal

During a session, participants:

• See the full process map so they know where they are
• Complete their assigned stages by filling in forms
• Get notified when it's their turn to act
• Hand off to the next person automatically when they're done

For example, when Jane starts the onboarding workflow, that creates a session. She fills in her details, her manager reviews and approves, HR processes the paperwork, and IT sets up her accounts—all tracked in that one session.

3. Sheets — Capture the Data

A sheet is where all the information collected during sessions gets stored. Think of it as a spreadsheet that automatically fills in as people complete workflows.

Each session creates a row in the sheet. Each form field creates a column. The result is clean, structured data you can:

• Search and filter
• Export to other systems
• Use for reporting and analysis

For example, after 50 employees complete onboarding, you'd have 50 rows in your sheet—one per person—with all their details organized in columns.

Supporting Concepts

Roles

Roles define who participates in a workflow and what they can do. Instead of assigning specific people, you assign roles—then assign people to those roles when a session starts.

Common examples:

• Submitter — The person who initiates the request
• Approver — Someone who reviews and approves/rejects
• Reviewer — Someone who provides input but doesn't approve
• Administrator — Someone who can manage the process

This makes workflows reusable. The same "Purchase Request" workflow works whether John or Sarah is the approver this time.

Stages

Stages are the individual steps in a workflow. Each stage:

• Has a specific purpose (collect info, review, approve, etc.)
• Contains blocks for participants to interact with
• Is assigned to one or more roles
• Connects to other stages via transitions

Blocks

Blocks are the building blocks you place on stages. They're how participants interact with the workflow:

• Input blocks collect data (text fields, dates, file uploads)
• Choice blocks offer options (dropdowns, checkboxes, polls)
• Content blocks display information (text, images, videos)
• Specialized blocks enable collaboration (discussions, reviews)

See Blocks & Sections for the complete list.

Transitions

Transitions are the paths between stages. They can be:

• Simple — Always go to the next stage
• Conditional — Go to different stages based on data (e.g., "If amount > $5,000, go to Manager Approval")

This lets you build workflows that adapt based on what participants enter.

How It All Fits Together

Here's a simple example of how these concepts connect:

1. You design a workflow called "Time Off Request" with stages: Request → Manager Review → HR Record
2. You create roles: Employee, Manager, HR
3. You add blocks to each stage: date picker for dates, text area for reason, checkbox for approval
4. You set up transitions: Request → Manager Review (always), Manager Review → HR Record (if approved)
5. The workflow saves data to a sheet called "Time Off Requests"

When an employee uses this workflow:

1. They start a session and fill in their request (dates, reason)
2. Their manager gets notified and sees the request in their session view
3. The manager approves, which triggers the transition to HR
4. HR records the time off
5. The session completes, and all the data is saved as a row in the sheet

The same workflow handles every time off request, ensuring consistency while the sheet builds a complete record of all requests.