# Eddy User Handbook Full plain-text dump of the public User Handbook. Source: https://eddy.works/docs/user-handbook Generated from live docs — always current with the deployed content. --- # Introduction URL: https://eddy.works/docs/user-handbook Welcome to Eddy — get started, run an Organization, and build Maps. The User Handbook explains how work moves through Eddy: Organizations contain workspaces; builders create Maps; people run them as Sessions; sheets hold the resulting data. New to Eddy? Start with [Getting Started](/docs/user-handbook/getting-started). Want the model first? Read [Core Concepts](/docs/user-handbook/core-concepts). For LLM tools, see the curated index at [`/docs/user-handbook/llms.txt`](/docs/user-handbook/llms.txt) or the full plain-text dump at [`/docs/user-handbook/llms-full.txt`](/docs/user-handbook/llms-full.txt). In this section [#in-this-section] Eddy's flywheel — Map, Execute, Store and Analyze — and how the pieces fit together. Sign up, open the dashboard, and create your first workspace and Map. Membership, permissions, and what it means to run an Organization on Eddy. Design Maps in the builder — stages, roles, blocks, and publishing. Participate in Sessions and monitor live work in Operator. Find, filter, and export the structured data collected from Sessions. Common questions about Organizations, Maps and Sessions. --- # Core Concepts URL: https://eddy.works/docs/user-handbook/core-concepts Eddy's four-stage flywheel — Map, Execute, Store and Analyze — and how they fit together. Eddy is built around a continuous loop: design a process, run it with people, keep clean records, then see how those runs performed so you can improve the design. See also [How Eddy Works](/#how-it-works) on the marketing site. Four ideas sit under the flywheel: * **Building the game board** — a **Map** defines the stages, rules, Map Roles, and blocks. It is the process people will run. * **Playing the game** — each live run is a **Session**. One Map can support many Sessions, each with its own participants and route through the stages. * **Outputs** — the data each Session leaves behind: answers and files in **sheets**, plus **Session metadata** (timestamps, stage durations, handoff waits) for Analyze. * **Improve** — use what you learn to revise the Map, then go around again. The next Sessions run on a better board. The **outcome** is what those four produce together: people know what happens next, who owns it, and when the handoff is due. That expectation management — transparency, accountability, clarity, and cohesion — is how a group of people can work as an organization without chasing the same questions through email. Each turn of the loop leaves a cleaner record and a chance to improve, so the process keeps reflecting and delivering value to the people who depend on it. 1. Map — design the process [#1-map--design-the-process] Authors lay out stages, transitions, Map Roles, and blocks into an executable graph. You design once; people run it many times. A Map answers: * **What steps** need to happen (stages) * **In what order** (transitions) * **Who does what** (Map Roles) * **What information** to collect or show (blocks) An onboarding Map makes that concrete: Submit Details → Manager Review → HR Processing → IT Setup → Complete. Those are the stages and their order; Map Roles name who acts at each stage (new hire, manager, HR, IT); blocks collect the details each person needs before the handoff. 2. Execute — run the Session [#2-execute--run-the-session] A **Session** is one live run of a Map. Participants land on their stages, complete their steps, and hand off to the next person. The Map holds the rules; people take their turns. During a Session, participants: * See where they are on the process map * Fill in forms and make decisions on their stages * Get notified when it is their turn * Hand off automatically when a stage completes Builders design the Map. Participants do the work. Operators watch live Sessions when something stalls. 3. Store — keep the record [#3-store--keep-the-record] As people work, Eddy captures answers, decisions, files, and handoff timing as structured data. * Each Session contributes rows to a **sheet** * Input and choice blocks bound to a sheet become columns * You can search, filter, and export After fifty onboarding Sessions you have fifty clean rows — not fifty email threads. 4. Analyze — see how Sessions performed [#4-analyze--see-how-sessions-performed] This stage is about **how Sessions ran**, not only what participants entered into blocks. Beside the answers in sheets, Eddy records **Session metadata**: timestamps, stage durations, handoff waits, and which path was taken. That operational trace is what lets you see where work stalls and which stages run long. **What ships today** * The **[Operator view](/docs/user-handbook/running-sessions/operator)** — a live operational picture of running Sessions: who is at which stage now, average time to completion per stage, where work waits longest Analyze is the least developed stage. Operator is the first shipped slice: it shows how live Sessions move through a Map. Process Intelligence features for sheets, including stronger run-over-run comparison, are under active development. How the four stages fit together [#how-the-four-stages-fit-together] 1. **Map** — design "Time Off Request": Request → Manager Review → HR Record, with roles and blocks 2. **Execute** — an employee starts a Session, the manager reviews, HR records the outcome 3. **Store** — answers and files land as a sheet row; handoff times are kept as Session metadata 4. **Analyze** — Operator shows where Sessions wait. Use that trace to revise the Map Then change the Map and run it again. Where to go next [#where-to-go-next] * Design a Map under [Building](/docs/user-handbook/building) * Take part in or manage a run under [Running Sessions](/docs/user-handbook/running-sessions) * Work with the resulting rows under [Data & Intelligence](/docs/user-handbook/data-and-intelligence) --- # Getting Started URL: https://eddy.works/docs/user-handbook/getting-started Sign up, open the dashboard, and create your first workspace and Map. Landing Page [#landing-page] The first screen is Eddy's sign-in page. Eddy Landing Page Click **"Login or Sign Up to Continue"** to sign in. Authentication [#authentication] After clicking **"Login or Sign Up to Continue"**, Eddy opens the authentication page. Auth0 Login Page Choose one of two sign-in methods: 1. **Continue with Google** — sign in with a Google account 2. **Email address** — enter your email and click **Continue** to receive a passwordless sign-in link If you don't have an account yet, click the **"Sign up"** link to create one. Home Dashboard [#home-dashboard] After logging in, you'll land on your home dashboard. Home Dashboard The dashboard shows: * **Welcome card** — dismissible links to the tools you use first * **Recent Visits** — workspaces and Maps you've recently viewed (appears once you have activity) * **Navigation bar** — Sessions, profile, notifications, help, and logout To get started, open the list of your Organizations from the sidebar. Organizations list You will see your available Organizations and the workspaces within them. Click directly into the workspace that was created for you at signup. For Organization dashboards, membership, and permissions, see [Organizations](/docs/user-handbook/organizations). Workspace Dashboard [#workspace-dashboard] Each workspace has its own dashboard. For now, it will be empty, but once you have active maps, it will show live status at a glance. Workspace Overview The workspace dashboard includes: * **Session health** — active, stale, and completed-today counts * **Most active** — Maps with the most running Sessions * **Needs attention** — Maps with stale Sessions * **Members** — who belongs to this workspace * **Recent activity** — latest Session and Map events Inviting a Member [#inviting-a-member] To invite someone, click **Members** in the side navigation. Members Page Click the **"Invite Member"** button in the top bar to open the invitation form. Invite Member Dialog To invite a new member: 1. Enter their **email address** in the Email field 2. Optionally add a **comment** to include with the invitation 3. Click **Invite** to send the invitation The invited person receives an email with a link to join. Track pending invitations under **Invitations**. For membership and removal, see [Membership](/docs/user-handbook/organizations/membership). Creating a Map [#creating-a-map] From an empty workspace, click **Create map** in the center of the dashboard. You can also use the **+** button in the top bar or navigate to **Maps** in the sidebar. New map Dialog Choose how to create your Map: * **Blank map** - Build from scratch * **Templates** - Use a pre-built template * **Copy Existing** - Duplicate a Map you have editing access to * **Upload File** - Import an existing Map file Select **"Blank Map"** to reveal the Map details form. Map Details Form Fill in: * **Name** - Give your Map a descriptive name * **Description** - Explain what this Map does * **Create default Sheet** - Recommended option that creates a linked data sheet Click **Save** to create your Map. You'll be redirected to the Map Builder. > **Next steps:** See [Your First Map](/docs/user-handbook/building/your-first-map) for the builder walkthrough. --- # Introduction URL: https://eddy.works/docs/user-handbook/organizations What an Organization is on Eddy, how it relates to your personal account and who can administer it. An **Organization** is the top-level container and contracting party on Eddy. It holds workspaces, Members, Maps and Sessions, as well as the subscription when billing is live. There is no Map outside an Organization. Every Map lives in a **workspace** inside an Organization. You cannot design or run Maps from a personal account alone. Your **Eddy account** is separate. You sign in as a person. That account can create Organizations and join ones you are invited to. The Organization does not own your account. Creating a Map always means creating it inside one of those Organizations' workspaces. | | Eddy account | Organization | | ----------------- | -------------------------------------------------- | ------------------------------------------------------------- | | What it is | Your identity on Eddy | Shared container for a team, school, company or project | | Who controls it | You | Organization owners (and admins within the limits owners set) | | What it holds | Profile, sign-in, memberships across Organizations | Workspaces, Members, Maps, Sessions, Organization settings | | Can it hold Maps? | No | Yes — Maps live in workspaces under the Organization | On signup you get a first Organization and workspace so you have somewhere to start. Solo users still work inside that structure — it is not optional scaffolding. A future template may be shared like a GitHub fork: you copy it into your own workspace and adapt the copy without changing the original. The copy still cannot run outside an Organization workspace. In this section [#in-this-section] Invite Members, work with Guests and remove people without deleting their Eddy account. Organization roles vs Session / Map Role permissions — who administers vs who acts in a Session. What it means to run an Organization on Eddy, with links to the Trust Center. --- # Membership URL: https://eddy.works/docs/user-handbook/organizations/membership Invite Members, work with Guests, and remove people from an Organization without deleting their Eddy account. Members [#members] Members are Eddy users who hold an Organization role (owner, admin, or member). They appear on the Organization **Members** screen and can open workspaces they have access to. Inviting a Member [#inviting-a-member] From the Organization or workspace side navigation, open **Members**: 1. Click **Invite Member** 2. Enter their email address 3. Optionally add a comment for the invite email 4. Send the invitation Track pending invites on the **Invitations** tab. When they accept, they join with the role you set (within what your own role allows). For a first-run walkthrough with screenshots, see [Getting Started → Inviting a Member](/docs/user-handbook/getting-started#inviting-a-member). Removing a Member [#removing-a-member] Owners and admins (where permitted) can remove a Member from the Organization. That: * Ends their Organization and workspace access * Ends Session access that depended on that membership It does **not** delete their Eddy account. They can still sign in, keep other Organizations, and keep any participation that was not tied to this Organization's membership. Guests and external participants [#guests-and-external-participants] Many Maps involve people outside the Organization — applicants, clients, partners, students. Those people usually join through a **start link** as Guests (external participants), not as Members. * They need an Eddy account to participate in a Session * They are not listed as Organization Members * They get access to the Session stages assigned to their Map Role for that Session Configure self-service vs fixed Member assignment when you create the start link. See [Roles → Self-service start links](/docs/user-handbook/building/roles#self-service-start-links). Contacts [#contacts] When an external person participates in a Session, Eddy creates a **Contact** record for them in the Organization. A Contact is not a Member. The record does not grant access to the Organization or its workspaces. Related [#related] * [Permissions](/docs/user-handbook/organizations/permissions) and [Policies](/docs/user-handbook/organizations/policies) --- # Permissions URL: https://eddy.works/docs/user-handbook/organizations/permissions How Organization roles and Session / Map Role permissions work together on Eddy. Eddy uses two permission layers. They answer different questions. | Layer | Question it answers | Where you set it | | ---------------------------------- | ----------------------------------------------------------- | --------------------------------------------- | | **Organization permissions** | Who can administer this Organization and its workspaces? | Organization / workspace Members and settings | | **Session / Map Role permissions** | Who can see, edit or progress a stage in a running Session? | Map builder — roles on stages | Being an Organization Member does not by itself let someone edit every Session. Being assigned a Map Role in a Session does not make them an Organization admin. Organization permissions [#organization-permissions] Organization roles control access to the Organization and its workspaces: | Role | Typical powers | | ---------- | ----------------------------------------------------------------------------------------------------- | | **Owner** | Membership, settings, billing when available, Organization lifecycle. Can add or remove other owners. | | **Admin** | Manage Members and workspaces within owner-set limits. | | **Member** | Use workspaces and Maps according to what the Organization and Map assignments allow. | Owners act for the Organization on billing and high-impact settings. Eddy may rely on instructions from someone who reasonably appears authorized. See [Terms of Use §6.5](/docs/trust/terms-of-use#6-5). Session and Map Role permissions [#session-and-map-role-permissions] Maps define **Map Roles** (for example Submitter, Reviewer, Approver). Stages are assigned those roles. When a Session starts, people are cast into those roles. Each role on a stage can have: | Flag | Effect | | ---------------- | ----------------------------------------------- | | **Can write** | Edit data on that stage | | **Can progress** | Complete the stage and move the process forward | A role can also be marked as **session admin** — view any stage, rewind or reopen, reassign people, archive. Session admin is Map-scoped oversight, not Organization ownership. Full detail: [Roles](/docs/user-handbook/building/roles) and [Sessions](/docs/user-handbook/running-sessions/sessions). How the layers combine [#how-the-layers-combine] Example: Alice is an Organization **Member**. Bob is a **Guest** on a start link. 1. Alice opens the workspace because of Organization membership. 2. A Session starts. Alice is assigned Map Role **Reviewer**; Bob is assigned **Applicant**. 3. Bob can fill the applicant stages. He cannot open Organization settings or invite Members. 4. Alice can review her stages. She cannot change Organization billing. She can only session-admin if her Map Role allows it. Remove Alice from the Organization and her membership-based access ends. Bob was never a Member; his Session access follows the Guest / Map Role rules for that Session. Related [#related] * [Membership](/docs/user-handbook/organizations/membership) and [Roles](/docs/user-handbook/building/roles) --- # Policies URL: https://eddy.works/docs/user-handbook/organizations/policies What it means to run an Organization on Eddy — duties that apply whether you pay or not, with links to the Trust Center. This page explains, in plain language, what it means to run an Organization on Eddy. The binding text lives in the [Trust Center](/docs/trust). If anything here disagrees with the Trust Center, the Trust Center wins. These duties apply whether the Organization is on a free or paid plan. Paying changes product features and commercial terms; it does not move controller responsibility onto Eddy Works for the data your Maps collect. Who decides what to collect [#who-decides-what-to-collect] Your Organization designs Maps and runs Sessions. You choose what to ask, who participates, and why. For that Session data, **your Organization is the controller** and **Eddy Works is the processor**. Eddy Works is a controller in its own right for account data and platform operations (sign-in, telemetry, and similar). That split is described in the [Privacy Policy](/docs/trust/privacy-terms) and the [Data Processing Addendum](/docs/trust/data-processing-agreement). Notices and consents [#notices-and-consents] Before people take part in your Sessions, you are responsible for having a lawful basis and for giving them the notices and consents the law requires for your use of their data on Eddy. In practice that means: 1. **Eddy platform terms** — every Eddy user accepts these when they create an account. 2. **Organization notice** — your Organization's notice to first-time participants (jurisdiction, purpose, how responses are used). Eddy does not yet present Organization notices in-product. Until it does, the Organization must provide its notice through its own channel before sharing a Session link with a first-time participant. On request, you may need to confirm to Eddy Works in writing that you have those consents and notifications. See [Terms of Use §8](/docs/trust/terms-of-use#8). Sensitive and regulated data [#sensitive-and-regulated-data] The [Acceptable Use Policy](/docs/trust/acceptable-use-policy) tiers what you may put through Eddy: * **Tier 1** — categories that are **not permitted today** (for example certain health or payment data). When Eddy is ready to support them, they will require a separate written agreement. * **Tier 2** — categories such as workplace health and safety, EDI surveys, employment or education records. Permitted when **you** have a lawful basis, safeguards, notifications to the people involved, and you meet your controller obligations. * **Always prohibited** — illegal content and other absolute bans in the AUP. Eddy does not certify that your sector use is lawful. You remain responsible for licenses, permissions, and notices. Members, Guests and conduct [#members-guests-and-conduct] You are responsible for how Members and Guests use the Service under your Organization, including compliance with the Terms and AUP. A breach by a Member or Guest can be treated as a breach by the Organization. See [Terms of Use](/docs/trust/terms-of-use) and [Membership](/docs/user-handbook/organizations/membership). Data subject requests [#data-subject-requests] If someone asks Eddy Works for access or erasure that relates to data your Organization controls, Eddy Works forwards that request to you so you can instruct as controller. Eddy Works handles requests about data it controls (for example account profile data) itself. Detail: [Data Processing Addendum](/docs/trust/data-processing-agreement) and [Privacy Policy](/docs/trust/privacy-terms). When policies change [#when-policies-change] Eddy Works may update the Terms and related policies. For material changes we try to give at least 30 days' notice (email, in-app, or on the website). Changes take effect on the date in the notice. Continued use after that date is acceptance. If you do not accept the changes, you may terminate before the effective date. We give at least 30 days' notice before increasing fees, or 90 days for a material increase. The new price applies from the next billing period. Changes required by law or for security may take effect immediately, with notice as soon as practicable. See [Terms of Use §3](/docs/trust/terms-of-use#3) and [§9.7](/docs/trust/terms-of-use#9-7). Where to read the full text [#where-to-read-the-full-text] | Topic | Trust Center | | --------------------------- | ----------------------------------------------------------------- | | Contract with Eddy Works | [Terms of Use](/docs/trust/terms-of-use) | | Defined terms | [Definitions](/docs/trust/definitions) | | What you may process | [Acceptable Use Policy](/docs/trust/acceptable-use-policy) | | Eddy as controller | [Privacy Policy](/docs/trust/privacy-terms) | | Eddy as processor | [Data Processing Addendum](/docs/trust/data-processing-agreement) | | Categories of data | [Data categories and subjects](/docs/trust/data-categories) | | Security, subprocessors, AI | [Trust Center](/docs/trust) | Related [#related] * [Introduction](/docs/user-handbook/organizations) * [Membership](/docs/user-handbook/organizations/membership) * [Permissions](/docs/user-handbook/organizations/permissions) --- # Introduction URL: https://eddy.works/docs/user-handbook/building How to design Maps in the Eddy builder — stages, roles, blocks, and publishing. This section is for **builders** — people who design Maps in Eddy. It covers the builder canvas, stages, Map Roles, blocks, and publishing. Maps live in Organization workspaces. This section covers their design. For membership and policy duties, see [Organizations](/docs/user-handbook/organizations). For published Maps and the data they produce, see [Running Sessions](/docs/user-handbook/running-sessions) and [Data & Intelligence](/docs/user-handbook/data-and-intelligence). In this section [#in-this-section] Step-by-step first Map — blocks, stages, publish, and start links. The Map Builder layout and main controls. Stage settings, completion policies, transitions, and timing. Map Roles, stage permissions, session admin, and start-link casting. Block types and how to configure them on a stage. --- # Your First Map URL: https://eddy.works/docs/user-handbook/building/your-first-map A step-by-step tutorial for building a two-stage Map with input blocks and content blocks. Now that you've created a Map, build your first stage by adding an input block. This tutorial picks up from where Getting Started left off, with your Map open in the builder. The Map Builder [#the-map-builder] After creating a Map, you'll land in the Map Builder with a single stage called "First stage". Map Builder Start The builder shows: * **Roles panel** (left) - Your Map has a default "Guest" role * **Stage canvas** (center) - The "First stage" node with a warning indicator * **Canvas controls** (bottom) - Tools for navigating and organizing the canvas Selecting a Stage [#selecting-a-stage] Click on **"First stage"** to open the stage editor panel. Stage Selected The stage panel shows: * **Stage title** with edit, Set Start, Set End, and delete options * **Section** called "basic" with a warning that it has no blocks * **"+ Add Block or Section"** button to add content Adding a Block [#adding-a-block] Click **"+ Add Block or Section"** to open the component picker. Add Block Dialog The component picker shows available block types: * **Input Blocks** - Text Field, Textarea, Number, Email, Phone, Date, URL, Attachment * **Choice Blocks** - Single Select, Multi-Select, Poll, Checkbox, Checklist, Todo * **Content & Media** - Content, Iframe, Video, Resource, Image Gallery * **Specialized** - Discussion, Review * **Sections** - Basic Section, Sheet Section Click **"Text Field"** to add a single-line text input to your stage. Configuring the Block [#configuring-the-block] After adding a Text Field, the block configuration panel opens. Block Configuration The configuration panel includes: * **Label** (required) - The title shown to users * **Hide label in session** - Option to hide the label from participants * **Placeholder** - Hint text shown before users enter a response * **Description** - Rich text instructions to help users understand the field Fill in the **Label** (e.g., "Your Name") and add a **Description** to guide users. Block Configured Sheet and Column Settings [#sheet-and-column-settings] Scroll down in the configuration panel to see the data binding settings. Sheet Column Settings These settings control where the collected data is stored: * **Output Sheet** - The sheet where responses will be saved (defaults to your Map's sheet) * **Select or Create Output Column** - The column that will store this field's data * **Required** - Whether users must complete this field before proceeding The column name is auto-suggested based on your label. Saving Your Block [#saving-your-block] Click **Save** to save your block configuration. Block Saved Your block is now saved and appears in the stage panel showing: * The block type (Text Field) * The sheet and column binding * The label and description You've added your first input block. Continue adding blocks to build out your Map stage. Adding a Second Stage [#adding-a-second-stage] Add another stage to make a multi-step Map. You can create new stages by dragging from an existing stage's connection point. To add a new stage: 1. Hover over the **green circle** at the bottom of "First stage" (the source handle) 2. Click and drag downward to create a new connection 3. Release to create a new stage called "New stage 2" New Stage Created Your Map now has two connected stages. The new stage opens automatically in the stage panel, showing: * **Stage title** "New stage 2" with edit and delete options * **Warning** that the stage has no outgoing transitions and isn't marked as end * **Empty section** waiting for blocks Adding a Content Block [#adding-a-content-block] Add a Content block for the completion message. Click **"+ Add Block or Section"** to open the component picker. Add Content Block Scroll down to **Content & Media** and click **"Content"** to add a rich text content block. Editing Content [#editing-content] After adding the Content block, the rich text editor opens. Content Editor The content editor includes: * **Toolbar** with formatting options (bold, italic, underline, strikethrough) * **Alignment** buttons for left, center, right, and justify * **Headings** dropdown for text hierarchy * **Lists** for bullets and numbered items * **Media** options for images, tables, and more * **Text area** with placeholder text "Your content goes here!" Writing Your Content [#writing-your-content] Type your completion message in the editor. Content Entered For example: "Thank you for completing this Map. Your submission has been received and will be reviewed shortly." Click **Save Changes** (the checkmark icon) to save your content. Map with Two Stages [#map-with-two-stages] After saving, your Map now has two complete stages. Map with two stages You've built a two-stage Map with: * **First stage** - A form collecting user input with a Text Field * **New stage 2** - A completion message using a Content block From here, you can: * Add more stages and blocks * Configure transitions between stages * Set up roles and permissions * Publish your Map to start collecting responses Fixing Validation Errors [#fixing-validation-errors] You may notice a warning indicator in the top toolbar showing validation errors. Click on the **error count** (the red triangle with a number) to open the Map Validation dialog. Map Validation Errors The validation dialog shows: * **Error count** - Total number of issues to fix (2 Errors) * **Error list** - Each validation issue with expandable details The two errors shown are: 1. **"Map needs an end stage"** - Every Map must have at least one stage marked as the endpoint 2. **"Stage 'New stage 2' has no outgoing transitions but is not marked as an end stage"** - A stage without outgoing connections must be designated as an end stage Click **Close** to dismiss the validation dialog. Setting an End Stage [#setting-an-end-stage] To fix the validation errors, click on **"New stage 2"** to open the stage panel. Stage Panel with Set End The stage panel header shows: * **Stage title** "New stage 2" with an edit button * **Set Start** - Marks this stage as a Map starting point * **Set End** - Marks this stage as a Map endpoint * **Delete** button to remove the stage The warning banner explains why this stage needs attention. Click **"Set End"** to mark this stage as an endpoint. End Stage Set After clicking Set End: * The **"Set End"** button changes to **"Unset End"** (shown with a filled red circle) * The warning banner disappears from the stage panel * The warning triangle disappears from the stage node * A **red end indicator** appears on the connection line * The validation errors are resolved The Map is valid and ready to publish. Previewing Your Map [#previewing-your-map] You can preview your Map at any time—**even while it's still in Draft mode**. You don't need to publish your Map to test it. This lets you verify your blocks, content, and flow before making it available to participants. There are two ways to access the preview. Map canvas **Option 1: Eye icon on stage nodes** Each stage node has an **eye icon** (👁) in the top-left corner. Click this icon to preview that specific stage directly. **Option 2: Start menu** Click the **Start** button in the top toolbar to open the start menu. Start Menu The Start menu provides three options: * **Preview** - Opens a preview session starting from the first stage * **Start Links** - Generate shareable links for participants to start sessions * **Manual Start** - Manually start a session for specific participants Click **Preview** to open the Map preview in a new tab. The Preview Experience [#the-preview-experience] Preview Session The preview shows exactly what participants will see: * **Header** - Shows "PREVIEW" badge with Map name and date * **Admin button** - Toggle the admin panel for Map / Session navigation * **Stage title** - Current stage name with "Active" status badge * **Role badge** - Shows the current role (e.g., "Guest") * **Form content** - The configured blocks and fields * **Progress indicator** - Shows "1/2" (stage 1 of 2) * **Navigation** - "Back" and "Complete and Next" buttons * **Close button** - Exit the preview and return to the builder Use preview mode to test your Map flow and verify that all content displays correctly before publishing. Publishing Your Map [#publishing-your-map] When your Map is ready for participants, you need to publish it. In the top toolbar, toggle the **Draft/Published** switch from "Draft" to "Published". Published Map Once published: * The toggle shows **"Published"** with a green indicator * The Map becomes available for sessions * You can still edit the Map while published Creating Start Links [#creating-start-links] Start links allow users to begin sessions without being workspace members. Click **Start** in the top toolbar, then select **Start Links**. Start Links Dialog The **Manage Start Links** dialog explains that self-service links let users start sessions without workspace membership and allow you to pre-assign roles. Since you have no links yet, select Create New Link. Create Start Link Dialog Single Session vs Multiple Sessions [#single-session-vs-multiple-sessions] When creating a link, you can set it to be **Multi-use** or **Single-use** per user: * **Multi-use** - Users can start multiple sessions with the same link. Useful for repeatable processes. * **Single-use** - Each person can only start one session with this link. Ideal for applications, surveys, and tests where you want one submission per user. Role Assignments [#role-assignments] Next, you must assign one or more users to each of the roles in your Map. For every role, choose: * **A specific workspace member** - Pre-assign a known user to this role * **Self-Service User** - Whoever clicks the start link will be assigned to this role For most public-facing Maps, select **Self-Service User**. Whoever uses the start link will be assigned to that Map Role for the Session. Assign **Self-Service User** to a Map Role on the start stage. Otherwise, the person who opens the link cannot begin. Once you've assigned users to all roles, you will be able to select "Create Link". Active Start Links [#active-start-links] Start Link Confirmation The confirmation message shows the new start link and lets you copy it. Start Link List Back on the Manage Start Links view, you'll see your newly-created start link, as well as some high-level information about it. You can copy the link from here, as well as revisit the details. The list shows: * **Creation date** and **usage count** * **"Multi-use"** vs **"Single-use"** badge * **Copy** and **Details** buttons Open **Details** to review role assignments or disable the link. You can now share the start link URL with participants. When they click the link, they'll be able to start a session and will be assigned to the Guest role automatically. The Start Link Landing Page [#the-start-link-landing-page] When participants click a start link, they see a landing page with information about the Map. Start Link Landing Page The landing page shows: * **Workspace name** - "My First Workspace" in the header * **Invitation message** - "You have been invited to start a session" * **Map title** - "My First Map" * **Author** - Who created the Map * **Description** - "A simple onboarding Map" * **Role information** - Expandable section showing assigned roles * **Start Session** button - Begins the Map session Click **"Show role information"** to see which role you'll be assigned. Start Link Roles Expanded The expanded role section shows: * **Guest** role with a "You will be assigned to this role" badge * **Role description** - "Default role for Map participants" * **Your email** - Confirms your identity for the session Click **Start Session** to begin the Map. You'll be taken directly to the first stage. > **Next steps:** To learn about the session experience from a participant's perspective, see the [Sessions](/docs/user-handbook/running-sessions/sessions) section. > > **Tip:** Once participants start using your Map, you can monitor their progress in the [Operator](/docs/user-handbook/running-sessions/operator) view. Switch from Builder to Operator using the toggle in the top bar to see where sessions are and identify any bottlenecks. --- # Maps URL: https://eddy.works/docs/user-handbook/building/maps Design and build Maps using the visual Map Builder. The Map Builder [#the-map-builder] The Map Builder is the visual editor for designing a Map. Use it to add stages, connect them, assign Map Roles, and decide what each stage collects or shows. Map Builder Key areas of the builder: * **Top toolbar** - Switch between Builder and Operator views, toggle Draft/Published status, and start Sessions * **Roles panel** (left) - Manage the Map Roles that participate in your Map * **Stage canvas** (center) - Visual graph showing stages and their connections * **Canvas controls** (bottom) - Pan, select, re-center, auto-layout, and settings New Maps start with a single "First stage" assigned to a default "Guest" role. From here you can: * Click a stage to edit its content * Add new stages and transitions * Define roles and assign them to stages * Configure stage settings and validation rules Top toolbar [#top-toolbar] The top toolbar controls the Map as a whole: * **Builder | Operator** — switch between designing the Map and monitoring live Sessions * **Draft | Published** — control whether the Map is available to participants * **Validation indicator** — open the list of issues that prevent publishing * **Start** — preview the Map, create start links or start a Session manually The Builder and Operator show the same Map from different perspectives. Builder changes the design. [Operator](/docs/user-handbook/running-sessions/operator) shows how Sessions move through it. Roles panel [#roles-panel] Map Roles describe the functions people perform, such as Submitter, Reviewer or Approver. Select a stage to decide which roles can see, edit or complete it. When a Session starts, real people are assigned to those roles. See [Roles](/docs/user-handbook/building/roles) for permissions, start-link assignments, and handovers. Stage canvas [#stage-canvas] The canvas shows the Map as a connected graph. Each stage is one step. Transitions define which stage follows and can include rules that send Sessions down different paths. Select a stage to edit its blocks and settings. Use the canvas controls to pan, re-center or arrange the graph. See [Stages](/docs/user-handbook/building/stages) and [Blocks & Sections](/docs/user-handbook/building/blocks-and-sections) for the available controls. Validation and publishing [#validation-and-publishing] Eddy validates the Map before publishing. The validation indicator lists missing end stages, incomplete role assignments, and other issues that would stop a Session from running. Resolve every validation error, then change the Map from **Draft** to **Published**. Publishing makes the current design available to participants. Starting work [#starting-work] Open **Start** in the top toolbar: | Option | What it does | | ---------------- | -------------------------------------------------------------------------- | | **Preview** | Opens the participant experience without publishing the Map | | **Start Links** | Creates links that assign people to Map Roles and let them begin a Session | | **Manual Start** | Starts a Session for people you select | If this is your first Map, follow [Your First Map](/docs/user-handbook/building/your-first-map) for the full build, validation, preview, and start-link sequence. > **Tip:** Once your Map is running, use the [Operator](/docs/user-handbook/running-sessions/operator) view to monitor Sessions and see where work is happening. --- # Stages URL: https://eddy.works/docs/user-handbook/building/stages Configure stage settings including stage modes, completion policies, start policies, activation timing, and transitions. Stages are the building blocks of a Map — each one represents a step that participants complete. You connect stages with transitions to define the path through your Map. Every stage has settings that control who participates, how data is captured, and when the stage is considered complete. You can access stage settings by clicking a stage on the builder canvas and opening the settings panel. Completion Policies [#completion-policies] Completion policies control **when a stage is considered done** when multiple people are assigned to it. By default, the first person to complete the stage completes it for everyone. Completion policies let you require more participants to finish before the stage progresses. You can set a completion policy in the stage settings panel. Open the **Completion Policy** settings and choose a mode: | Mode | Behavior | When to use | | ----------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | **Any** (default) | The first assignee to complete the stage finishes it for everyone. | Support queues, triage, or any stage where one person's completion is sufficient. | | **All** | Every assignee must independently mark their part as done. | Review panels, approval committees, or any stage where everyone's input is needed. | | **Threshold** | A percentage of assignees must complete (e.g., 50%). | Voting, consensus, or redundancy — where you need enough responses but not necessarily all. | How participants experience it [#how-participants-experience-it] When a stage has an **All** or **Threshold** policy, participants see a progress banner at the top of the stage showing how many people have completed so far (e.g., "2 of 5 complete"). * When you finish your part, click **Mark as Done**. Your data is saved, but the stage stays open for others. * After marking done, you'll see a "Done — waiting for others" indicator. The progress banner updates in real time as others complete. * You can still edit your responses after marking done, until the stage itself completes. * Once enough people have completed (all, or the threshold percentage), the stage automatically progresses to the next stage. Things to know [#things-to-know] * **Read-only roles don't count.** If a role is assigned to a stage with **Can progress** turned off, those assignees are excluded from the completion count. Only roles that can progress contribute to the policy. * **Threshold uses a percentage, not a count.** This means the policy adapts to however many people are assigned. With a 50% threshold and 6 assignees, 3 must complete. With 10 assignees, 5 must complete. * **Removing an assignee can trigger completion.** If an admin removes a participant who hasn't completed, the reduced denominator may satisfy the policy — the stage will automatically progress. Start Policies [#start-policies] Start policies control **when a stage activates** when it has multiple incoming paths. This is relevant at merge points — stages where two or more parallel branches converge. You can set a start policy in the stage settings panel: | Mode | Behavior | When to use | | ----------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Any predecessor** (default) | The stage activates as soon as any one predecessor completes. | Simple branching, or when only one path will be taken. | | **All predecessors** | The stage waits until every predecessor has completed. | Parallel review gates — e.g., both the legal review and technical review must finish before the final decision stage activates. | How participants experience it [#how-participants-experience-it-1] When you complete a stage that feeds into an "all predecessors" merge, and other branches haven't finished yet: * You'll see a **Complete and Wait** button instead of the usual "Complete and Next." * A confirmation dialog explains that the next stage will activate once all parallel branches are done. * After completing, the session dialog closes — there's nothing to navigate to yet. * When the last branch completes, the merge stage activates, and all assignees are notified. If you happen to be on the **last** branch to finish, you'll see the normal "Complete and Next" button — your completion unblocks the merge and the next stage is ready immediately. Things to know [#things-to-know-1] * **Start policies only matter at merge points.** If a stage has only one incoming transition, the policy has no effect. The builder will show a note if you set a policy on a stage with no merge. * **A stage with a start policy also shows a merge icon** on the builder graph, so you can see at a glance which stages are gated. * **Conditional transitions and start policies are independent.** If a predecessor completes but its transition rule doesn't pass, the predecessor is still counted as "arrived" for the start policy. Transition rules control which path is taken; start policies control whether the target is ready. Activation Timing [#activation-timing] By default, stages activate immediately when a preceding stage is completed. Activation timing lets you delay a stage — keeping it locked until a specified date and time. You can set activation timing from the stage settings panel or by clicking the **clock icon** on a stage node in the builder. Choose between: | Mode | Behavior | | ----------------------- | -------------------------------------------------------------- | | **Immediate** (default) | The stage activates as soon as a preceding stage completes. | | **On a specific date** | The stage waits until a fixed date and time before activating. | How participants experience it [#how-participants-experience-it-2] When a participant completes a stage that leads to a time-locked stage, they'll see a **Complete and Wait** button with a note about when the next stage will become available. * A confirmation dialog shows the scheduled activation time. * After completing, the session dialog closes — the next stage isn't available yet. * The time-locked stage appears on the session graph with a dashed border, a clock badge, and the scheduled date and time. * When the scheduled time arrives, the stage activates automatically and assignees are notified. Things to know [#things-to-know-2] * **Activation timing is set on the stage, not the transition.** A stage has one activation time regardless of how many paths lead to it. * **If the scheduled time has already passed**, the stage activates immediately — there's no unnecessary delay. * **Activation has up to one minute of precision.** Eddy checks for due stages every minute, so activation may occur up to a minute after the scheduled time. * **Start stages cannot have time locks.** The first stage in a Map always activates immediately when the session begins. Transitions [#transitions] Transitions are the connections between stages — they define the paths participants can take through the Map. You create transitions in the builder by dragging from one stage to another. Conditional transitions [#conditional-transitions] By default, a transition is unconditional — it always fires when the source stage is completed. You can add a **rule** to a transition to make it conditional. Click on a transition arrow in the builder to open the edge editor, where you can set a condition. Conditions reference sheet columns and compare their values: * "If **Status** equals **Approved**, go to the Approved stage" * "If **Score** is greater than **80**, go to the Advanced track" * "If **Category** is not empty, go to the Review stage" You can combine multiple conditions with **and** / **or** logic for more complex rules. Branching and merging [#branching-and-merging] * **Branching** — A stage with multiple outgoing transitions creates a fork. If the transitions have conditions, only the paths whose rules are satisfied will fire. If multiple rules pass, multiple next stages activate simultaneously. * **Merging** — A stage with multiple incoming transitions is a merge point. Use a [start policy](#start-policies) to control whether the stage waits for all predecessors or activates on the first arrival. Things to know [#things-to-know-3] * **If no transition rules pass, the Map stops at that stage.** Make sure your conditions cover all expected cases, or include a fallback transition with no condition. * **Transition rules are evaluated against the current session data.** The values in the sheet at the moment of completion determine which paths are taken. * **Transition rules are independent of start policies.** If a predecessor completes but its transition rule doesn't pass, the predecessor is still counted as "arrived" for the target's start policy. Rules control paths; policies control readiness. Per-Participant Stages [#per-participant-stages] Per-participant stages are an experimental feature and may change. They are not yet available to all workspaces. By default, stages are **shared** — all assigned participants see and work with the same data. Per-participant stages flip this: each participant gets their own private copy of the inputs, and each person's responses are saved as a separate row in a dedicated sheet. This is useful when you need independent contributions before group work — brainstorms, individual submissions, proposals that will be discussed or voted on later. When to use this [#when-to-use-this] The classic pattern is **independent input followed by group deliberation**: 1. **Stage 1 (Per-participant):** Each participant submits their own proposal, idea, or response — independently, without seeing what others have written 2. **Stage 2 (Shared):** The group reviews all submissions together using a sheet section, then discusses via a discussion block 3. **Stage 3 (Shared):** The group votes on the proposals using a poll with [data-sourced options](/docs/user-handbook/building/blocks-and-sections#data-sourced-options) Per-participant stages handle Step 1. Each participant produces one row in the stage's sheet, and downstream stages can display and act on that collected data. Setting up a per-participant stage [#setting-up-a-per-participant-stage] 1. Click a stage on the builder canvas to select it 2. Open the **stage settings** panel 3. Under **Stage Mode**, switch from **Shared** to **Per-participant** 4. Select or create a **dedicated sheet** for the stage — this is where each participant's row will be stored 5. Add blocks to the stage as usual — they will automatically bind to the dedicated sheet When you switch to per-participant mode, the completion policy is automatically set to **All** (all participants must complete before the stage progresses). You can adjust this in the [completion policy](#completion-policies) settings. What participants experience [#what-participants-experience] Participants on a per-participant stage see the same interface as any other stage — input blocks, content blocks, and a progress button. The difference is invisible to them: they only see and edit their own data, not anyone else's. Once all participants have completed, the stage progresses and the next stage can access everyone's responses — for example, through a sheet section that displays all rows, or a poll whose options are sourced from the collected data. Things to know [#things-to-know-4] * **Dedicated sheet required.** Each per-participant stage needs its own sheet. It cannot use the Map's default sheet or share a sheet with another per-participant stage. * **Polls and discussions aren't available.** These are group collaboration blocks — they belong on shared stages where participants interact with each other's contributions, not on per-participant stages where everyone works independently. * **Switching modes archives blocks.** If you change a stage from shared to per-participant (or vice versa), existing blocks on that stage will be archived, since they are bound to a different sheet. * **Data persists.** Once a participant submits their data on a per-participant stage, it is saved as a row in the dedicated sheet and persists for the rest of the session. --- # Roles URL: https://eddy.works/docs/user-handbook/building/roles Define who participates in your Maps, what they can do at each stage, and how people are assigned to roles when Sessions start. Map Roles define **who participates** in a Map and **what they can do**. Instead of assigning specific people to stages, you create roles — like "Submitter," "Reviewer," or "Approver" — and assign those roles to stages. When a Session starts, you assign real people to the roles. This separation makes Maps reusable. The same approval Map works whether Alice or Bob is the Approver this time. The Map design stays the same; only the casting changes. Creating Roles [#creating-roles] Every Map starts with a default "Guest" role. You can create additional roles in the **Roles panel** on the left side of the builder. To create a new role: 1. Click the **+** button in the Roles panel 2. Give the role a **name** — choose something that describes the participant's function (e.g., "Reviewer," "Manager," "Client") 3. Add a **description** — this is shown to participants so they understand their responsibilities 4. Choose a **color** — each role gets a color that appears throughout the session interface, making it easy to see which role is responsible for each stage Roles are Map-level — they apply across all stages and Sessions of that Map. Assigning Roles to Stages [#assigning-roles-to-stages] Once you've created roles, you need to assign them to stages. Eddy uses those assignments to determine which roles participate at each step. To assign a role to a stage: 1. Select a stage on the builder canvas 2. In the stage settings, add the roles that should participate at this stage A stage can have multiple roles assigned. For example, a "Review" stage might have both a "Reviewer" role (who provides feedback) and a "Submitter" role (who can see the review but not edit). Stage permissions [#stage-permissions] Each role assignment on a stage comes with two permission flags: | Permission | Default | What it controls | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Can write** | On | Whether the role can edit data on this stage. Turn this off to give a role read-only access — they can view the stage but not modify any blocks. | | **Can progress** | On | Whether the role can complete the stage and move the Map forward. Turn this off for roles that should observe or contribute data but not control when the stage finishes. | These permissions combine to support common patterns: | Pattern | Can write | Can progress | Example | | ----------------------------- | --------- | ------------ | --------------------------------------------------------------- | | **Full participant** | On | On | The submitter filling in a form and completing the stage | | **Editor without completion** | On | Off | A contributor who adds data but can't advance the Map | | **Observer** | Off | Off | A stakeholder with visibility but no edit or completion rights | | **Approver (review only)** | Off | On | A reviewer who reads the submitted data and decides to progress | Session admin [#session-admin] Any role can be configured as a **session admin** by enabling the session admin flag in the role settings. Session admins have elevated access within sessions: * **View any stage** — even stages they aren't assigned to * **Stage admin actions** — rewind, reopen completed stages, force-complete stages, and nudge assignees * **Session management** — assign roles, archive sessions, reopen completed sessions This is useful for facilitators, coordinators, or team leads who need to oversee and intervene in running sessions without being directly assigned to every stage. See [Managing Sessions](/docs/user-handbook/running-sessions/sessions#managing-sessions) for details on the available admin actions. Assigning People to Roles [#assigning-people-to-roles] When a session starts, real people need to be assigned to the Map's roles. This happens in two ways: Manual assignment [#manual-assignment] When starting a session from the builder or via the Operator view, you assign workspace members to each role. For example, "Alice is the Submitter, Bob is the Reviewer, Carol is the Approver." Each role can have one or more people assigned. Multiple people in the same role means they all get access to that role's stages — useful for review panels or collaborative stages. Self-service start links [#self-service-start-links] Start links let people begin sessions without workspace membership. When creating a start link, you configure role assignments: * **Self-service user** — whoever clicks the link is automatically assigned to this role. Use this for the role that the external participant will fill (e.g., "Applicant," "Client"). * **Specific member** — pre-assign a workspace member to a role. Use this for internal roles that should always go to the same person (e.g., "HR Coordinator"). The self-service user must be assigned to a role that includes the Map's starting stage — otherwise they won't be able to begin. Mid-session assignment changes [#mid-session-assignment-changes] Session admins can change role assignments during a running session via the **Assign Roles** option in the session menu. This is useful when: * A participant is unavailable and someone else needs to take over * A new team member needs to join a session in progress * A role was accidentally left unassigned at session start Adding someone to a role gives them access to any currently active stages assigned to that role. Multi-Role Maps [#multi-role-maps] Roles matter most when a Map involves multiple people with different responsibilities. Eddy handles handovers between Map Roles. How handovers work [#how-handovers-work] When a participant completes a stage and the next stage is assigned to a different role, Eddy: 1. Marks the current stage as complete 2. Activates the next stage 3. Creates assignments for the people in the next role 4. Notifies them that it's their turn The completing participant sees a **handover** indicator — the Map has been passed to someone else. If they're also assigned to the next stage (because they hold multiple roles), they're navigated there directly. Blocked handovers [#blocked-handovers] If a Session reaches a stage assigned to a role with nobody in it, the stage activates but no one can work on it. This is a **blocked handover**. When this happens: * The stage shows a blocked state on the session graph * Session admins can resolve it by assigning someone to the missing role via **Assign Roles** * The Session resumes as soon as the role is filled To avoid blocked handovers, make sure every role has at least one person assigned before starting a session. The start link configuration helps enforce this by requiring assignments for all roles. Things to Know [#things-to-know] * **Roles are reusable across sessions.** The same role definitions apply every time the Map runs. Only the people assigned to those roles change between sessions. * **One person can hold multiple roles.** If Alice is both the "Submitter" and the "Reviewer," she'll be assigned to stages for both roles. The Map still routes correctly — she'll see stages from both perspectives. * **Deleting a role archives related data.** If you delete a role in the builder, its stage assignments and any session assignments derived from it are archived. This preserves the history of completed sessions while removing the role from future ones. * **Role colors appear everywhere.** The color you choose shows up on the session graph (node borders and paths), role badges and the roles panel — helping participants quickly identify which role is responsible for what. * **Completion policies interact with roles.** When a stage has an "All" [completion policy](/docs/user-handbook/building/stages#completion-policies), every assignee with **Can progress** enabled must complete before the stage advances. Roles with **Can progress** off are excluded from the count. --- # Blocks & Sections URL: https://eddy.works/docs/user-handbook/building/blocks-and-sections A reference guide to all block types, their configuration options, and how they behave in Sessions. Blocks are the building blocks of your Map stages. Each block type serves a specific purpose—from collecting data with input blocks to displaying content to participants. Block Types [#block-types] **Input Blocks** (capture user data): * **Text Field** - Single-line text field for short text or numbers * **Textarea** - 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): * **Single 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 Maps **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 [#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 block 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 [#data-sourced-options] Data-sourced options are an experimental feature and may change. They are not yet available to all workspaces. 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 [#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 [#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 [#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 [#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 Map 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 [#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 add discussion and review on a stage * Sections organize the visual layout of the stage * Required blocks must be completed before progressing Content Block [#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. It combines rich formatting with **column mentions** that resolve to live Session values at runtime. Creating content [#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 [#formatting-options] The content editor supports: * **Headings** — three levels for structuring longer content * **Text formatting** — bold, italic, underline, strikethrough, highlight (multiple colors), and text color * **Text alignment** — left, center, 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 [#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:** * **Personalized 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 [#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 [#things-to-know-1] * **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 [#discussion-block] The discussion block is a threaded conversation embedded in a Map 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 Map. 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 [#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 [#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 [#things-to-know-2] * **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.** 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 [#poll-block] The poll block runs a structured vote within a Map 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, prioritizing options, or gauging consensus before moving forward. How it works [#how-it-works-1] 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 [#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 [#things-to-know-3] * **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](#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 [#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 Maps, handovers, and any stage where someone needs to see what was provided earlier before making their own decision. How it works [#how-it-works-2] 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 Map. 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 [#when-to-use-this-1] * **Approval Maps** — 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 [#things-to-know-4] * **Mirrors one block.** Each review block references exactly one source block. To review multiple blocks, add multiple review blocks. * **Read-only always.** Participants can never edit data through a review block. If corrections are needed, the Map 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 [#sheet-sections] A sheet section embeds a filtered, tabular view of sheet data within a Map 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 [#when-to-use-this-2] | Use case | Permissions | Example | | ------------------------- | ----------------- | ---------------------------------------------------------------- | | **Review dashboard** | View only | Display all proposals submitted on a previous stage | | **Data collection** | View + Add | Participants build a list of items (contacts, tasks, line items) | | **Append-only log** | View + Add | Participants add entries but can't modify previous ones | | **Edit existing records** | View + Edit | Reviewers update records submitted by others | | **Full access** | View + Edit + Add | Participants can view, create, and modify records freely | Setting up a sheet section [#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] Data scopes let you filter which records appear in the sheet section. You set two scopes independently: | User scope | Session scope | What participants see | | ---------------- | ------------------- | ------------------------------------------------------- | | **All users** | **All sessions** | Every record in the sheet | | **All users** | **Current session** | Records from this session only | | **Current user** | **All sessions** | Only the participant's own records, across all sessions | | **Current user** | **Current session** | Only the participant's own records from this session | 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 [#what-participants-see-1] 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 [#things-to-know-5] * **Dedicated sheet when adding records.** If "add" is enabled, the sheet section needs its own sheet — it cannot use the Map'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. --- # Introduction URL: https://eddy.works/docs/user-handbook/running-sessions Run Sessions on Eddy — participate, facilitate, and monitor live work. This section is for people **in** running Sessions — participants completing stages and operators watching progress across Sessions. A Session is one live run of a Map. Design the Map under [Building](/docs/user-handbook/building). For Organization membership and the resulting rows, see [Organizations](/docs/user-handbook/organizations) and [Data & Intelligence](/docs/user-handbook/data-and-intelligence). In this section [#in-this-section] Start a Session, complete stages, session admin and support threads. Live map of Sessions, bottlenecks, and facilitation tools. --- # Sessions URL: https://eddy.works/docs/user-handbook/running-sessions/sessions Start a Session, complete stages, and use the session interface. A Session is one live run of a Map. Participants open stages, fill blocks, and hand off until the Session completes. Starting a Session [#starting-a-session] When you click a start link, you'll see a landing page with details about the Map. Click **Start Session** to begin. The Session Interface [#the-session-interface] Once you start a Session, you'll see the stage dialog with your first task. Session First Stage Dialog The session interface includes: * **Header bar** - Shows the Map name and current date * **Admin button** - Access administrative features (if you have admin permissions) * **Stage title** - "First stage" with an "Active" badge indicating it's your current stage * **Role badge** - Shows your assigned role (e.g., "Guest") * **Form content** - The blocks configured for this stage * **Progress bar** - Shows how far you are through the Map (e.g., "1/2") * **Navigation buttons** - "Back" to go to the previous stage, "Complete and Next" to progress The Session Map [#the-session-map] Close the dialog by clicking the **X** button to see the session map. Session Map View The session map shows: * **Stages** - All stages displayed as connected nodes * **Your progress** - Active stages are highlighted, completed stages show a checkmark * **Role panel** - Shows your assigned roles and descriptions * **Zoom controls** - Zoom in/out and fit view to canvas Click on any stage node to open its dialog and view or complete its content. Completing a Stage [#completing-a-stage] To complete a stage: 1. **Open the stage** - Click on the stage node in the map Session Stage Dialog Open 2. **Fill in the required blocks** - Enter information in any input blocks Session Name Filled 3. **Click "Complete and Next"** - This marks the stage as complete and moves you to the next stage Progressing Through Stages [#progressing-through-stages] After completing the first stage, you'll automatically move to the next stage. Session Second Stage On a two-stage Map, the final stage often shows: * **Content block** - Displays the thank you message we configured * **Progress** - Updated to "2/2" indicating this is the final stage * **Complete Session button** - Since this is the end stage, the button changes from "Complete and Next" to "Complete Session" Support Threads [#support-threads] Each Session has a built-in support thread — a conversation between participants and session admins. Use it when you're stuck, have a question about the Map, or need to flag something to the people managing the process. Requesting help [#requesting-help] Click the **Support** button (headset icon) in the session header to open the support dialog. Type your message and send it. The thread is created with your first message — there's no setup needed. Workspace admins and session admins are notified when you send a message. They can read your message and respond directly in the same thread. The conversation updates in real time — you'll see replies appear as they're sent. A **red dot** appears on the Support button when there are unread replies, so you won't miss a response. Responding to support requests (admins) [#responding-to-support-requests-admins] Session admins see the same support dialog and can respond to participant messages directly. When you open the dialog, any unread messages are automatically marked as read. Once the issue is resolved, click the **Resolve** button to mark the thread as resolved. A green "Resolved" badge appears on the thread. Resolved threads can still receive new messages if the conversation needs to continue. Support threads are also surfaced in the [Operator](/docs/user-handbook/running-sessions/operator) view's Support panel, where admins can see all threads across Sessions for a Map — both resolved and unresolved — and click through to the relevant Session. Completing the Session [#completing-the-session] When you reach the final stage and click **Complete Session**, a confirmation dialog appears. Session Complete Confirmation The confirmation explains that completing this stage will: * Mark the entire Session as done * Alert all assignees that the Session is complete Click **Confirm** to complete the Session. Session Completed [#session-completed] Once confirmed, you'll see the completed Session view. Session Completed The completed Session shows: * **Celebration banner** - "Session completed on \[date] at \[time]" * **Green checkmarks** - All stages show completion checkmarks * **Completed path** - Completed paths are marked on the graph Your Session data is saved. People with access to the workspace's Sheets can open the resulting rows there. > **Next steps:** View collected rows in [Sheets](/docs/user-handbook/data-and-intelligence/sheets), or monitor running Sessions in [Operator](/docs/user-handbook/running-sessions/operator). Managing Sessions [#managing-sessions] Session admins have access to additional actions for managing running Sessions — correcting mistakes, unblocking stuck Sessions, and keeping work moving. Who is a session admin? [#who-is-a-session-admin] You are a session admin if any of the following apply: * You are a **workspace owner, admin, or builder** * You hold a Map Role that has **session admin** enabled (configured in the builder's role settings) Session admins can open and view any stage in the Session, even stages they aren't assigned to. A yellow "Viewing as admin" banner appears when viewing a stage you're not assigned to. Viewing access doesn't grant write or completion permissions — you can inspect, but only assigned participants can fill in data and progress. Stage actions [#stage-actions] When viewing a stage as a session admin, an **Admin** button appears in the stage dialog header. It opens a menu with the following actions: **Rewind** — Move the Session back to the previous stage. This deactivates the current stage and reactivates the predecessor, allowing participants to rework it. Use this when a stage was completed prematurely or with incorrect data. Rewind is available when the current stage is active. **Reopen Stage** — Reactivate a completed stage so it can be worked on again. Unlike rewind, this doesn't deactivate any subsequent stages — it simply reopens the completed stage for further editing. Use this when data on a completed stage needs correction but later stages should remain unaffected. Reopen is available when the current stage is completed. **Mark Complete** — Force-complete an active stage as an admin, triggering progression to the next stage. Use this to unblock a Session when a participant is unavailable or a stage is stuck. This bypasses the normal completion flow — the admin's action is treated as the completing event. **Nudge** — Send a reminder notification to all participants assigned to the current stage. Use this when a stage has been active for too long and assignees may need a prompt. A dialog lets you add an optional message to the nudge. Nudge is available when the stage is active and has assignees. Session actions [#session-actions] The Session options menu (accessible from the top bar) provides Session-level actions: **Assign Roles** — Open the role assignment dialog to manage who holds each Map Role for this Session. You can add or remove participants from roles, which determines who gets assigned to upcoming stages. **Reopen Session** — Reopen a Session that has already been completed. This clears the completion status and lets participants resume where they left off. Available when the Session is completed. **Archive** — Archive the Session. Archived Sessions are hidden from the default Session list but their data is preserved. When to use each action [#when-to-use-each-action] | Situation | Action | | -------------------------------------------------------------------- | --------------------------------------- | | A participant completed a stage with wrong data and needs to redo it | **Rewind** to the previous stage | | A completed stage needs a small correction but later work is fine | **Reopen Stage** on the completed stage | | A participant is unavailable and the Session is stuck | **Mark Complete** to force progression | | Participants seem to have forgotten about an active stage | **Nudge** to send a reminder | | A new team member needs to join mid-session | **Assign Roles** to add them to a role | | A Session was completed too early and needs more work | **Reopen Session** | | A Session was started by mistake or is no longer needed | **Archive** the Session | --- # Operator URL: https://eddy.works/docs/user-handbook/running-sessions/operator Monitor running Sessions on a Map — stage dwell, bottlenecks, and support. The Operator view shows a published Map with live Session data: which Sessions sit at which stage, how long they have been there, and what needs attention. Use Builder to change the Map; use Operator to watch it run. Switching Between Builder and Operator [#switching-between-builder-and-operator] When viewing a Map, you'll see a **Builder | Operator** toggle in the top bar. Builder Operator Toggle * Click **Builder** to design and edit the Map * Click **Operator** to monitor running Sessions and view live data When you switch between views, your camera position (zoom and pan) is preserved, so you stay oriented on the same part of the Map. The Operations Graph [#the-operations-graph] The Operator view displays the same Map graph as the Builder, but in read-only mode with runtime annotations. Operations Graph Key elements of the operations graph: * **Session count badges** — Each stage node shows how many Sessions are currently at that stage * **Heatmap coloring** — Stages are colored based on dwell time (how long Sessions spend there), from cool to warm to hot * **Bottleneck indicators** — Stages with unusual accumulation or long dwell times display visual warnings * **Conditional transition markers** — Edges with rules show a flask icon indicating conditional routing The graph helps you answer "where is work?" at a glance. Your eye is drawn to the hot spots — stages where Sessions are piling up or taking too long. You cannot edit the graph in Operator view. To change the Map, switch back to the Builder. The Side Panel [#the-side-panel] The side panel provides detailed views of this Map's live Session data. A toolbar at the top lets you switch between views. Summary View [#summary-view] The Summary view is the default landing — it answers "how are Sessions on this Map doing?" Summary Panel The Summary view includes: * **Map metrics** — Active, stale, and completed Session counts for this Map, plus average cycle time. * **Progression funnel** — How many Sessions are at each stage * **Bottleneck highlights** — The slowest stages ranked by dwell time Sessions View [#sessions-view] The Sessions view shows all Sessions for this Map in a filterable list. Sessions Panel The Sessions view includes: * **Session list** — Sortable by status, dwell time or assignee * **Support indicators** — Sessions with support thread activity show a badge * **Quick access** — Click any Session to open it Participants View [#participants-view] The Participants view shows workload distribution. Use the **People | Roles** toggle to switch between two modes. Participants Panel **People mode** shows individual participants: * **Participant list** — Each person with their active Session count * **Current stages** — Which stages each person is working on * **Search** — Filter participants by name **Roles mode** shows Map Roles: * **Role list** — Each role with its active Session count * **Activity by role** — Which roles carry the most work Data View [#data-view] The Data view shows what data this Map captures and what has been collected. Data Panel The Data view has two modes: * **Schema mode** — Column mappings, data types, and which stage captures what * **Sheet data mode** — Actual rows from the Map's Sessions Support View [#support-view] The Support view surfaces help requests from participants. Support Panel The Support view shows: * **All support threads** — Both resolved and unresolved threads * **Thread status** — Which threads need attention * **Quick access** — Click to open the Session where you can read the full thread and respond Stage Detail Overlay [#stage-detail-overlay] Click any stage node in the graph to see detailed information about that stage. Stage Detail Overlay The stage detail overlay includes: * **Stage header** — Stage name, completion policy, and assigned roles * **Current state** — Active Session count, average time at stage, and active support threads on the stage * **Assignee breakdown** — Sessions grouped by assignee to identify bottlenecks * **Historical performance** — Average dwell time and throughput compared to current Click on an assignee to add them to the scope, filtering the view to show only their Sessions. Click away from the stage to return to your previous panel view. Single Session Mode [#single-session-mode] To focus on one Session's journey through the Map, select a Session from the Sessions panel or a stage detail list. The graph enters single Session mode. Single Session Mode In single Session mode: * **Completed stages** are highlighted with checkmarks * **The current stage** shows the Session's position * **Untaken branches** are dimmed * **Duration annotations** show how long the Session spent at each stage * **Assignee avatars** show who worked on each stage The side panel shows the single Session report with execution timeline, participant activity, and audit log. Session Replay [#session-replay] When viewing a single Session, click **Replay** to step through the Session's history event by event. Replay mode shows how the Session unfolded over time. Session Replay The replay controls appear at the bottom of the graph: * **Play/Pause** — Automatically advance through events * **Step forward/backward** — Move one event at a time * **Jump to start** — Return to the beginning of the Session * **Scrubber bar** — Click anywhere on the timeline to jump to that point * **Time display** — Shows elapsed time and total Session duration * **Exit** — Click the X to leave replay mode During replay, the graph updates to show the Session's state at each point in time: * **Stage status** — Stages change from pending to active to completed as the replay progresses * **Assignee avatars** — Show who was assigned at each stage * **Data entry flashes** — Brief highlights appear on stages when participants entered data The side panel shows the **event log** — a chronological list of everything that happened during the Session, including stage activations, assignments, completions, and data entries. Click any event in the log to jump to that moment. > **See also:** Designing Maps in [Maps](/docs/user-handbook/building/maps), or the participant experience in [Sessions](/docs/user-handbook/running-sessions/sessions). --- # Introduction URL: https://eddy.works/docs/user-handbook/data-and-intelligence Sheets and structured data collected from Maps and Sessions. This section covers the **data** your Maps produce — structured rows in sheets you can search, filter, and export. For what Analyze supports now and what is under active development, see [Core Concepts](/docs/user-handbook/core-concepts). Design Maps under [Building](/docs/user-handbook/building). Run and monitor Sessions under [Running Sessions](/docs/user-handbook/running-sessions). In this section [#in-this-section] List sheets, open records, and work with Session data. --- # Sheets URL: https://eddy.works/docs/user-handbook/data-and-intelligence/sheets View and manage Session data in sheets. Sheets store structured rows from Sessions. Answers from input and choice blocks land in columns. One completed Session produces one main row; per-participant stages can add rows to their own sheets. The Sheets Page [#the-sheets-page] Navigate to **Sheets** from the sidebar to see all sheets in your workspace. Sheets List Page The sheets page shows: * **Total Sheets** - Number of sheets in your workspace * **Without Maps** — Sheets not linked to any Map * **Sheet cards** - Each card displays: * Sheet name * Number of records and columns * Linked Maps * Creator and creation date * **Open Sheet** button to view the data Viewing a Sheet [#viewing-a-sheet] Click **Open Sheet** to view the sheet's data in a table format. Sheet Detail Page The sheet view displays: * **Breadcrumb navigation** - Shows your location (Sheets / Sheet name) * **Search** - Filter records by searching * **Data table** - All records displayed in rows with columns for: * **Actions** — Quick actions for each row (edit, open record, go to Map/Session, archive) * **Block columns** - Columns for each bound block on your Map (e.g., "Your Name") * **Metadata columns** - Created At, Updated At, Record ID, Session ID, Author Name, Author Email You can drag column headers to reorder them as needed. Sheet Options [#sheet-options] Click the **three-dot menu** in the top-right corner to access sheet options. Sheet Options Menu Available options: * **Rename Sheet** - Change the sheet's name * **Add Column** - Create a new column for additional data * **Share Sheet** - Share the sheet with others * **Export CSV** - Download the sheet data as a CSV file * **Show Archived Rows** - View rows that have been archived * **Archive Sheet** - Archive the entire sheet (shown in red as a destructive action) Related [#related] * [Operator](/docs/user-handbook/running-sessions/operator) — monitoring live Sessions * [Building](/docs/user-handbook/building) — controlling what gets captured --- # FAQ URL: https://eddy.works/docs/user-handbook/faq Answers to common questions about accounts, Maps, Sessions, data and Map configuration. Organizations and accounts [#organizations-and-accounts] **What is the difference between my Eddy account and an Organization?** Your account is your personal identity on Eddy. An Organization contains workspaces, Members, Maps and Sessions. Maps only exist inside an Organization workspace. See [Organizations](/docs/user-handbook/organizations). **Who is responsible when our team collects personal data in a Session?** Your Organization is the controller for data your Maps collect. Eddy Works processes that data for you. Plain-language summary: [Policies](/docs/user-handbook/organizations/policies). Full text: [Trust Center](/docs/trust). **How do Organization roles differ from roles on a Map?** Organization roles control the workspace. Map Roles control who can act in a Session. See [Permissions](/docs/user-handbook/organizations/permissions). **Do Guests need an Eddy account?** Yes. A Guest signs in or creates an account before taking part in a Session. They do not need to become an Organization Member. See [Membership](/docs/user-handbook/organizations/membership). Building Maps [#building-maps] **Where do I learn the Map Builder?** Start with [Building](/docs/user-handbook/building) — first Map tutorial, then stages, roles, and blocks. **What is the difference between a Map and a Session?** A Map defines the stages, rules, Map Roles and blocks. A Session is one live run of that Map with its own participants and data. See [Core Concepts](/docs/user-handbook/core-concepts). **Can I preview a Map before publishing it?** Yes. Open **Start** in the builder and select **Preview**, or use the eye icon on a stage. Preview works while the Map is still a draft. See [Your First Map](/docs/user-handbook/building/your-first-map#previewing-your-map). Running Sessions [#running-sessions] **Why is my Session stuck?** A common cause is a stage assigned to a Map Role with nobody in it. A session admin can use **Assign Roles** to fill the role. Depending on the situation, they can also nudge an assignee or mark the stage complete. See [Blocked handovers](/docs/user-handbook/building/roles#blocked-handovers) and [Managing Sessions](/docs/user-handbook/running-sessions/sessions#managing-sessions). **What is the difference between Rewind and Reopen Stage?** **Rewind** moves the Session back and deactivates the current stage. **Reopen Stage** opens a completed stage for correction without deactivating later stages. See [Stage actions](/docs/user-handbook/running-sessions/sessions#stage-actions). **How do I see where Sessions are waiting?** Open [Operator](/docs/user-handbook/running-sessions/operator). It shows how many Sessions sit at each stage and how long they have been there. Data [#data] **Where do answers go after a Session?** Answers from input and choice blocks are stored in sheet columns. A completed Session produces a main row, while per-participant stages can add rows to their own sheets. See [Sheets](/docs/user-handbook/data-and-intelligence/sheets). Configuration troubleshooting [#configuration-troubleshooting] Use this section when the builder reports validation errors, a Session will not progress, or a block or sheet setup does not behave as expected. Open the red triangle in the builder toolbar for the full error list. See [Validation and publishing](/docs/user-handbook/building/maps#validation-and-publishing). Publishing and stage structure [#publishing-and-stage-structure] **Why can't I publish my Map?** Every validation **error** must be resolved before you can publish. Warnings do not block publishing. Click the error count in the toolbar, fix each listed issue, then change the Map from **Draft** to **Published**. See [Maps](/docs/user-handbook/building/maps#validation-and-publishing). **Why does validation say the Map needs a start or end stage?** A Map with more than one stage needs one stage marked as the start. Every Map needs at least one end stage. Open the stage settings and use **Set as start** or **Set as end**. A stage with no outgoing transitions must be an end stage. See [Your First Map](/docs/user-handbook/building/your-first-map#publishing-your-map). **Why does a stage say it has no sections or no blocks?** Every stage needs at least one section and every section that collects or edits data needs at least one block. Add a section from the stage, then add blocks into it. Empty sheet sections used for view-only tables are allowed when add and edit are both off. **Why does a stage say it has no roles assigned?** Select the stage and assign at least one Map Role in the stage settings. Without a role, nobody can open that stage in a Session. See [Roles](/docs/user-handbook/building/roles#assigning-roles-to-stages). **Why does a stage say no role can progress?** At least one role on a non-end stage must have **Can progress** on. If every role is observer-only, nobody can complete the stage. Turn **Can progress** on for the role that should advance the Map. See [Stage permissions](/docs/user-handbook/building/roles#stage-permissions). Roles, start links and handovers [#roles-start-links-and-handovers] **Someone opened a start link and cannot begin. Why?** The self-service user must be assigned to a Map Role that includes the Map's starting stage. On the start link, set **Self-service user** to that start-stage role. See [Self-service start links](/docs/user-handbook/building/roles#self-service-start-links). **The next stage activated but nobody can work on it. Why?** That is a **blocked handover**: the stage's Map Role has nobody assigned. A session admin should open **Assign Roles** and fill the role. Require assignments for all roles on start links to prevent this. See [Blocked handovers](/docs/user-handbook/building/roles#blocked-handovers). **Why can a participant see a stage but not edit or complete it?** Check the role's stage permissions. **Can write** controls editing; **Can progress** controls completion. An observer has both off. An editor without completion can write but not advance. See [Stage permissions](/docs/user-handbook/building/roles#stage-permissions). **Why won't a required discussion or poll let the stage finish?** Discussions and polls need a **session admin** role on that stage. A session admin must complete the discussion (with an outcome) or close the poll before the stage can progress when the block is required. Enable **Session admin** on a Map Role assigned to the stage. See [Discussion Block](/docs/user-handbook/building/blocks-and-sections#discussion-block) and [Poll Block](/docs/user-handbook/building/blocks-and-sections#poll-block). Transitions and policies [#transitions-and-policies] **Why did the Session stop even though the stage was completed?** If every outgoing transition has a condition and none of the conditions pass, the Map stops. Cover all expected cases or add a fallback transition with no condition. See [Transitions](/docs/user-handbook/building/stages#transitions). **Why is the next stage waiting after I completed mine?** Either the target uses an **All predecessors** start policy and other branches are still open, or the stage has a **time lock** that has not fired yet. You will see **Complete and Wait** in those cases. See [Start Policies](/docs/user-handbook/building/stages#start-policies) and [Activation Timing](/docs/user-handbook/building/stages#activation-timing). **Why does validation warn about my start policy?** Start policies only matter at merge points. A policy with no incoming transitions has no effect. A policy with only one predecessor behaves like **Any predecessor**. An **All predecessors** policy with conditional incoming transitions can wait forever if a condition never passes. See [Start Policies](/docs/user-handbook/building/stages#start-policies). **Why is the stage still open after I marked myself done?** The stage uses an **All** or **Threshold** completion policy. Your part is saved; the stage waits until enough assignees with **Can progress** finish. Read-only roles do not count. See [Completion Policies](/docs/user-handbook/building/stages#completion-policies). **I set a time lock. Why did the stage activate early or late?** If the scheduled time has already passed when the predecessor completes, the stage activates immediately. Activation checks run about once a minute, so the stage may unlock up to a minute after the scheduled time. Start stages cannot use time locks. See [Activation Timing](/docs/user-handbook/building/stages#activation-timing). Sheets, blocks, and bindings [#sheets-blocks-and-bindings] **Why does a block say it has no sheet or column binding?** Input and choice blocks must bind to a sheet column. Open the block configuration, choose a sheet and column (or create a new column), then save. See [Configuring Blocks](/docs/user-handbook/building/blocks-and-sections#configuring-blocks). **Why can't my sheet section use the Map's default sheet?** If **Users can add new records** is on, the section needs its own sheet. Adding rows on the Map default sheet would conflict with the Session's primary row. Use a dedicated sheet, or turn add off and keep the section view- or edit-only. See [Sheet Sections](/docs/user-handbook/building/blocks-and-sections#sheet-sections). **Why can't a regular block use the same sheet as a sheet section?** If a sheet section can **add** records on a sheet, other stages must not bind ordinary input blocks to that same sheet. New section rows would conflict with the Session's primary row. Put form fields inside the sheet section, or use a different sheet for stage-level blocks. **Why is my sheet section table empty or missing columns?** Configure **viewable columns** on the sheet section. An empty viewable-columns list produces an empty table. Columns used by form fields should appear in the viewable list; add missing ones with the column picker. See [Sheet Sections](/docs/user-handbook/building/blocks-and-sections#sheet-sections). **Why don't data-sourced options appear, or why can't I use them in transition rules?** Source data must be filled on a **previous** stage. Options are snapshotted when the consuming stage begins. Transition rules on data-sourced columns cannot reference specific option values — use conditions like "is not empty" instead. See [Data-Sourced Options](/docs/user-handbook/building/blocks-and-sections#data-sourced-options). Per-participant stages [#per-participant-stages] **Why won't validation accept my per-participant stage?** Each per-participant stage needs its own dedicated sheet (not the Map default sheet and not shared with another per-participant stage). It also needs a completion policy of **All** or **Threshold**, not **Any**. Polls and discussions are not allowed on these stages. See [Per-Participant Stages](/docs/user-handbook/building/stages#per-participant-stages). **Why did switching to per-participant archive my blocks?** Changing a stage between **Shared** and **Per-participant** rebinds data to a different sheet. Existing blocks are archived so they do not keep the old binding. Re-add the blocks after the switch. See [Per-Participant Stages](/docs/user-handbook/building/stages#per-participant-stages). **Why can't a shared stage use a per-participant sheet?** Per-participant sheets belong to their stage's private rows. Shared stages must use the Map default sheet or another shared sheet. Bind shared-stage blocks to a non-per-participant sheet.