Blocks & Sections

Blocks are the building blocks of your workflow stages. Each block type serves a specific purpose—from collecting data with form fields to displaying content to participants.

Block Types

Coming soon: Documentation for each block type including configuration options and session behavior.

Input Blocks (capture user data):

• Input - Single-line text field for short text or numbers
• Text Area - Multi-line text field for longer responses
• Number - Numeric input field
• Email - Text field with email validation
• Phone - Phone number input with country code selection
• Date - Date picker (can include time selection)
• URL - Text field with URL validation
• Attachment - File upload for one or more files

Choice Blocks (predefined options):

• Select - Dropdown menu for single selection
• Multi-Select - Dropdown for multiple selections
• Checkbox - Single standalone checkbox
• Checklist - Multiple items with checkboxes
• Todo - Task list (similar to Checklist)
• Poll - Voting on options with live tally

Content & Media Blocks (display information):

• Content - Rich text with formatting, images, and dynamic data
• Video - Embedded video player (YouTube, Vimeo, etc.)
• Resource - Downloadable file list
• Media Gallery - Image/media carousel
• Iframe - Embedded external web page

Specialized Blocks (unique functionality):

• Discussion - Threaded conversation with comments and replies
• Review - Display data from another block for approval workflows

Sections (organize your stage):

• Section - Group blocks together with a header
• Sheet Section - Embed a filtered view of sheet data within a stage

Configuring Blocks

Each block has configuration options that control:

• Label - The title shown to participants
• Description - Helper text explaining what to enter
• Required - Whether the field must be completed
• Validation - Rules for acceptable input
• Visibility - Conditions for when the block appears
• Sheet Column - Where the data is stored (for input/choice blocks)

Data-Sourced Options

Choice blocks normally have a fixed set of options defined in the builder. Data-sourced options let a choice block pull its options from data produced earlier in the session — for example, a poll whose choices come from proposals submitted by participants on a previous stage.

When to use this

The classic pattern is propose-then-vote: participants submit ideas on one stage, then the group votes on those ideas on a later stage. The poll options are whatever participants actually proposed — they don't exist at build time.

The same pattern works for any choice block. A checklist could be built from tasks identified in an earlier brainstorm. A select menu could offer choices sourced from a prior data-collection stage.

Setting up data-sourced options

1. Open the block configuration for a choice block (Poll, Select, Multi-Select, Checklist, or Todo)
2. Toggle Options from data on
3. Select the source sheet — the sheet where the source data is stored
4. Select the source column — the column whose values will become the block's options

When "Options from data" is on, the static options editor is replaced by the sheet and column pickers. Toggle it off to switch back to manually defined options.

Make sure the source data is filled in on a previous stage. Data-sourced options require the source column to be populated before participants reach the consuming stage.

What participants see

When participants reach a stage with a data-sourced block, the options are loaded automatically from the source column. From that point, the block looks and works exactly like one with manually defined options — participants won't see any difference in the interface.

Options are captured once when the stage begins. They won't change if the source data is edited afterward, and all participants on that stage see the same set of options.

Things to know

• Source data must come from a previous stage. The source column needs to be populated before the consuming stage begins. Data produced and consumed on the same stage is not supported.
• Options are a snapshot. They are captured when the stage is entered and remain fixed for the rest of the session.
• Looping preserves options. If the workflow loops back to a stage with data-sourced options, the original options are kept. Votes or selections already made against those options remain valid.
• Rules work differently. Because options don't exist at build time, transition rules on data-sourced columns can't reference specific option values. Use option-agnostic conditions like "is not empty" or "has a value" instead.

Blocks in Sessions

When participants interact with blocks during a session:

• Input and choice blocks collect and validate responses
• Content & media blocks display configured information
• Specialized blocks provide advanced functionality (discussions, reviews)
• Sections organize the visual layout of the stage
• Required fields must be completed before progressing

Detailed documentation for each block type coming soon!

Content Block

The content block is a rich text display block for presenting formatted information to participants — instructions, context, explanations, or dynamic summaries that reference data from the current session.

Unlike input or choice blocks, the content block doesn't capture data. It's purely for display. What makes it powerful is the combination of rich formatting and dynamic data references that resolve to live session values at runtime.

Creating content

Click on a content block in the builder to open the content editor. The editor opens in a full-width modal with a formatting toolbar at the top.

The editor works like a standard rich text editor — type your content, select text to format it, and use the toolbar for more options. Your work is auto-saved to local storage as you type, so you won't lose drafts if the browser closes unexpectedly. Use the recover button in the toolbar to restore a previous draft.

Formatting options

The content editor supports:

• Headings — three levels for structuring longer content
• Text formatting — bold, italic, underline, strikethrough, highlight (multiple colours), and text colour
• Text alignment — left, centre, right, and justify
• Lists — bullet lists and numbered lists, with Tab/Shift+Tab for indentation
• Links — clickable URLs
• Images — embed images directly in the content
• Tables — full tables with rows and columns, useful for presenting structured reference information
• Blockquotes — for callouts or emphasis
• Collapsible sections — expandable/collapsible areas for supplementary information that participants can reveal if needed

Dynamic data with column mentions

The content block's most distinctive feature is column mentions — live references to data collected earlier in the session.

Type % in the editor to trigger the column suggestion menu. Select a column, and a mention tag is inserted into your content. In the builder, the tag shows the column name (e.g., %Full Name). At runtime, it resolves to the actual value from the current session.

Example uses:

• Personalised instructions — "Thanks, %Name. Your request for %Amount has been submitted for review."
• Dynamic summaries — "The committee will now review the proposal: %Proposal Title"
• Confirmation messages — "Your selected date is %Start Date. Please confirm below."

Column mentions pull values from the session's sheet data. The column must be populated on a previous stage — if no value exists yet, the mention displays the column name as a placeholder.

User mentions

Type @ to mention workspace members by name. This is useful for referencing specific people in instructions — for example, "If you have questions, contact @Alice Chen."

Things to know

• Display only. The content block shows information to participants but doesn't capture any input. It has no sheet column binding.
• Column mentions resolve per-session. Each session shows its own data. A content block with %Name shows "Alice" in one session and "Bob" in another.
• Content is set at build time. The rich text content is configured once in the builder and shown identically to all participants (except for the dynamic column mention values). Participants can't edit the content block.
• Tables scroll horizontally. If a table is wider than the stage dialog, it gets horizontal scrolling with fade indicators on the edges.

Discussion Block

The discussion block is a threaded conversation embedded in a workflow stage. It gives participants a space to talk through ideas, raise questions, or debate options — all within the context of the current stage.

Unlike a regular chat tool, discussions in Eddy are tied to a specific point in the workflow. They produce a recorded outcome that is stored in the sheet, making them useful when a stage needs group input before moving forward.

How it works

When participants reach a stage with a discussion block, they see a comment thread. Anyone assigned to the stage with write permission can post messages. Comments appear in real time — there's no need to refresh. You can @mention workspace members by name within your messages.

The discussion stays open until a session admin closes it. While open, all participants can continue posting.

Completing a discussion

Session admins see a Complete button on the discussion. Completing a discussion:

1. Opens a modal asking for an outcome statement — a summary of what was decided or concluded
2. Closes the thread so no further comments can be posted
3. Stores the outcome statement in the discussion's bound sheet column

The outcome appears in a highlighted box below the thread so participants can see what was decided. If the admin needs to reopen the discussion, they can click Reopen to allow further comments.

Things to know

• Requires a sheet column. Like input blocks, the discussion block is bound to a column. The column stores the outcome statement, not the comments themselves.
• Comments are real time. The thread updates live via WebSocket — participants see new messages without refreshing.
• Not available on per-participant stages. Discussion blocks are a coordination block type — they require group interaction and aren't compatible with per-participant (independent) stage mode.
• Required discussions must be completed. If the discussion is marked as required, a session admin must complete it (with an outcome) before the stage can be progressed.

Poll Block

The poll block runs a structured vote within a workflow stage. Participants choose from a predefined set of options, see a live tally of results, and a session admin closes the poll with a declared outcome.

Polls are useful when a stage needs a group decision — choosing between proposals, prioritising options, or gauging consensus before moving forward.

How it works

When participants reach a stage with a poll block, they see:

1. A live results bar chart showing how many votes each option has received
2. A vote form where they select one option and submit

Votes update in real time. Participants can see the tally shift as others vote. After voting, a participant can change their vote at any time while the poll is still open.

Closing a poll

Session admins see a Close Poll button. Closing a poll:

1. Opens a modal pre-filled with the leading option (the one with the most votes)
2. Asks the admin to confirm the winning option and write an outcome statement explaining the decision
3. Locks the poll so no further votes can be cast

The outcome and outcome statement are displayed to all participants. If the admin needs to revisit the decision, they can Reopen the poll to allow further voting.

Things to know

• One vote per participant. Each participant gets a single vote, but can change it while the poll is open.
• Options are defined in the builder. By default, you add options manually when configuring the block. For dynamic options sourced from session data, see Data-Sourced Options.
• Not available on per-participant stages. Like discussions, polls are a coordination block type — they require group interaction.
• Results are visible to everyone. The vote tally is public within the session. There is no anonymous voting mode.
• Admin controls the outcome. The poll doesn't auto-close when everyone has voted — a session admin explicitly closes it and declares the result.

Review Block

The review block displays data captured by another block on a previous stage. It renders the original block's content in read-only mode, allowing participants to see what was submitted without being able to modify it.

Review blocks are the mechanism for approval workflows, handovers, and any stage where someone needs to see what was provided earlier before making their own decision.

How it works

In the builder, configure a review block by selecting the block to review — a searchable picker shows all eligible blocks from previous stages in the workflow. The review block then mirrors that block's value at runtime.

When participants reach the review stage, they see:

• The original block rendered exactly as it appeared to the person who filled it in, but in read-only mode
• The name and avatar of the person who submitted the data
• The source stage where the data was originally captured

When to use this

• Approval workflows — a manager reviews a submitted request before approving or rejecting
• Multi-stage handovers — a second team picks up work started by a first team and needs to see what was done
• Summary stages — a final stage that collates key data points from earlier stages for a stakeholder to review

Things to know

• Mirrors one block. Each review block references exactly one source block. To review multiple fields, add multiple review blocks.
• Read-only always. Participants can never edit data through a review block. If corrections are needed, the workflow should loop back to the original stage.
• Most input and choice blocks are reviewable. Text, number, date, email, phone, URL, attachment, checkbox, select, multi-select, checklist, todo, and poll blocks can all be reviewed. Content blocks and discussions cannot be reviewed.
• Shows who submitted. The review block displays the original author's name and the stage name, giving reviewers full context.

Sheet Sections

A sheet section embeds a filtered, tabular view of sheet data within a workflow stage. It displays records as a table and can optionally let participants add new records or edit existing ones through a modal form.

Sheet sections are useful when a stage needs to display or collect structured, multi-record data — for example, a list of contacts, an inventory log, or a review of proposals submitted on an earlier stage.

When to use this

Setting up a sheet section

1. Add a Sheet Section to a stage via the "Add Block or Section" button
2. Open the section configuration by clicking the edit icon
3. Select or create a sheet — this is the sheet whose data the section will display
4. Set permissions — choose which actions participants can take:
   • Users can view records — always enabled
   • Users can edit existing records — lets participants click a row to open and modify it
   • Users can add new records — shows an "Add record" button
5. Add form fields (if edit or add is enabled) — these blocks define the form that appears in the add/edit modal. When you add a block and bind it to a column, that column is automatically added to the viewable columns list.
6. Configure viewable columns — choose which columns appear in the table, drag to reorder, and toggle visibility with the eye icon
7. Set data scopes — control which records are visible (see below)

Data scopes

Data scopes let you filter which records appear in the sheet section. You set two scopes independently:

The most common combination is All users + Current session — showing everything the team has contributed in this session. Use Current user scoping when each participant should only see their own entries.

What participants see

Participants see a table embedded in the stage, showing the records that match the configured scopes. Depending on permissions:

• View only — participants can see the table but not interact with it
• Edit enabled — clicking a row opens a modal with the form fields, where participants can update the record
• Add enabled — an "Add record" button appears below the table. Clicking it opens a modal where participants fill in the form fields and save to create a new row

Required fields in the modal must be completed before saving. If the stage has required fields, all visible rows must be complete before the participant can progress to the next stage.

Things to know

• Dedicated sheet when adding records. If "add" is enabled, the sheet section needs its own sheet — it cannot use the workflow's default sheet or share a sheet with regular blocks on other stages. This prevents data conflicts. Edit-only sections don't have this restriction.
• Form fields define the modal. The blocks you add to the sheet section appear in the add/edit modal, not inline on the stage. The table and the modal are separate views of the same data.
• Columns auto-sync with form fields. When you add a block and bind it to a column, that column is automatically included in the viewable columns list. You can still manually adjust which columns are shown and their order.
• Validation respects scopes. Required field validation only checks the rows visible to the current participant based on the data scopes. Participants aren't blocked by incomplete records they can't see or edit.
• Switching to view-only archives form fields. If you disable both edit and add after configuring form fields, those blocks will be archived since they're no longer needed.