--- title: Workflow Studio description: A complete Workflow Studio guide covering the canvas, builder flow, and every node available in Edgaze. source: https://www.edgaze.ai/docs/builder/workflow-studio section: builder --- # Workflow Studio Workflow Studio is where you design multi-step AI products on a visual canvas. If Prompt Studio is one prompt, Workflow Studio is connected logic: collect input, run models, merge data, branch when needed, and ship something customers can run repeatedly. ## On this page - What Workflow Studio is - The main areas of the screen - Building your first workflow - Node reference - Runs and testing - Publishing ## What Workflow Studio is A workflow is a chain of blocks. Each block does one job. Connections show how data moves toward the result. ```text Question asked -> Data collected -> AI or logic applied -> Result returned ``` ## The main areas of the screen **Top bar:** Home, templates, run, publish, and canvas controls. Navigation and actions, not block settings. **Block library:** Search and add supported blocks. Templates use the same blocks you add here. **Canvas:** Place blocks, connect them, and read the product logic at a glance. A strong canvas makes sense before anyone opens the inspector. **Inspector:** Opens when you select a block. Set prompts, models, input questions, formatting, vault-backed providers, and advanced options here. ## Building your first workflow Start with the outcome. Finish this sentence: **This workflow helps a customer go from _X_ to _Y_.** If the outcome is fuzzy, the graph usually is too. Decide what the customer provides. Good inputs are minimal, plain, and tied directly to that outcome. A simple first graph often looks like: ```text Input -> Merge -> LLM -> Output ``` Connect blocks in the order data should move. Every connection should make the next step easier to understand, not harder. Select each block and configure it in the inspector: model, prompt, input question, output shape, provider requirements. Run the workflow with realistic customer input. Customer view shows what buyers will actually experience. ## Complete node reference Each block below explains what it does, which ports it uses, and how to configure it in the inspector. ### Workflow Input The Workflow Input node is the entry point for customer-provided data. ```docsgraph workflow-input ``` **What It Does** It asks the user a question and turns the answer into data your workflow can use. If your workflow begins with customer input, this is usually the first node on the canvas. **Ports** - one output port: `Data` Workflow Input does not accept upstream input. It starts the flow. **Inspector Fields** The key input settings are: - `Question` - `Input Type` - `Description` If the selected input type is `Dropdown`, the Inspector also exposes dropdown options so you can define the choices the user will see. **Input Types** Workflow Input supports: - Text - Long Paragraph - Number - URL - Dropdown - File Upload (up to 5MB) - JSON Choose the type that matches the answer format you actually want. Do not ask for JSON if a short text or dropdown would be clearer. **Best Use Cases** Use Workflow Input for: - customer prompts - briefs - URLs - structured lists - file-based starting material - controlled choice inputs **Best Practices** - Make the question extremely clear. - Use the description for examples or constraints. - Prefer structured inputs when that reduces ambiguity. - Avoid asking for more than the workflow actually needs. ### Merge Merge combines several upstream values into one downstream payload. ```docsgraph merge ``` **What It Does** Merge is useful when several inputs or branches need to become one combined value before the next step runs. This is common in prompt-building workflows where multiple user answers need to feed a single LLM or generator. **Ports** - three input ports: `in 1`, `in 2`, `in 3` - one output port: `Data` At least one inbound connection is required for the node to be meaningful. **Inspector Fields** Merge has no Inspector fields. Its behavior is defined by what you connect into it. **What Comes Out** At runtime, Merge is treated as a combination step that produces one downstream value from the connected inputs. In practice, creators should think of it as a compact "combine these values before the next step" node. **Best Use Cases** Use Merge when: - multiple inputs should feed one prompt - several branches need to recombine - a creative workflow supports several cues or ingredients **Best Practices** - Keep the upstream inputs semantically related. - Avoid using Merge as a dumping ground for unrelated data. - If the graph becomes hard to read, split merging into stages. ### Workflow Output Workflow Output is the final return point of the workflow. ```docsgraph workflow-output ``` **What It Does** It defines what the user ultimately receives from the workflow. This is what makes the workflow feel finished. **Ports** - one input port: `Result` Workflow Output should usually sit at the end of a clear branch or at the end of the main flow. **Inspector Fields** The main output settings are: - `Output Name` - `Output Format` **Output Formats** Workflow Output supports: - JSON - Text - HTML Choose JSON when the result is structured. Choose Text when the result is plain language. Choose HTML when the output needs formatting. **Best Use Cases** Use Workflow Output for: - final answers - generated copy - parsed objects - structured result payloads - rendered markup **Best Practices** - Name the output based on what the customer gets. - Match the format to the downstream experience. - Do not leak internal debugging structure into the final result unless the product explicitly needs it. ### LLM Chat LLM Chat is the main text-generation and reasoning node. ```docsgraph llm-chat ``` **What It Does** It takes input, runs it through a selected language model, and returns a model response. This is the node you use for: - rewriting - summarising - extracting - classifying - analysing - prompt optimisation - general text generation **Ports** - one input port: `Input` - one output port: `Response` It accepts string or JSON-like upstream data and produces a response for downstream nodes. **Inspector Fields** The main LLM Chat fields are: - `Prompt (fallback)` - `Style / System (optional)` - `Model` - `Temperature` - `Max Tokens` It also includes inline toggles for: - `Stream` - `Safe Mode` And the node supports advanced execution settings such as timeout and retries. **How To Use Prompt And Input Together** If the input is connected, the model can work from the incoming data. If it is not connected, the fallback prompt becomes the main source of instruction. The cleanest pattern is: - use upstream nodes for raw data - use the prompt for transformation instructions - use system/style for tone and constraints **Model Choice** The model selector is where you trade off quality, cost, and speed. Creators should choose based on the job: - use stronger models for nuanced reasoning and polished writing - use lighter models for faster and cheaper utility tasks **Best Use Cases** Use LLM Chat when the workflow needs language understanding or generation. **Best Practices** - Keep each LLM node focused on one job. - Use explicit instructions. - Lower temperature for extraction and structured work. - Higher temperature is better for creative variation. - Keep max tokens aligned with the expected result length. ### LLM Image LLM Image is the image-generation node. ```docsgraph llm-image ``` **What It Does** It turns a prompt into an image result. This node works best after the workflow has already clarified what the image should be. **Ports** - one input port: `Prompt` - one output port: `Image URL` The cleanest setup is to feed it a polished prompt from an upstream text or optimisation step. **Inspector Fields** The main image fields are: - `Prompt (fallback)` - `Model` - `Aspect Ratio` - `Quality` It also supports execution settings like timeout and retries. **Model And Aspect Ratio** Model determines the provider and generation behavior. Aspect ratio determines the intended frame shape. In practice: - choose a model first - choose the right frame shape for the product - only use quality settings when the selected provider honors them **Best Use Cases** Use LLM Image for: - image generation products - creative template outputs - visual concept generation - art workflows **Best Practices** - Feed it a refined prompt instead of raw vague input. - Make aspect ratio intentional. - Treat image generation as a final-stage node, not the thinking stage. ### LLM Embeddings LLM Embeddings converts text into a vector representation. ```docsgraph llm-embeddings ``` **What It Does** It produces embeddings for text so the output can be used in similarity, retrieval, indexing, or memory-style workflows. This node is not for visible customer copy. It is for vector data. **Ports** - one input port: `Text` - one output port: `Embedding` It expects string input and returns an array-like vector output. **Inspector Fields** The main embeddings fields are: - `Text (fallback)` - `Model` It also supports timeout and retries. **Best Use Cases** Use LLM Embeddings for: - semantic search - memory systems - retrieval pipelines - similarity comparison **Best Practices** - Feed it clean, meaningful text. - Use it as infrastructure inside a larger workflow. - Do not confuse embeddings with visible text output. ### HTTP Request HTTP Request lets the workflow talk to an external endpoint. ```docsgraph http-request ``` **What It Does** It makes a network request and returns the response payload to the workflow. This is the node you use when the workflow needs outside data or needs to call an external service. **Ports** - one input port: `Request` - one output port: `Response` It can work from Inspector config, from upstream input, or from a connected object payload. **Inspector Fields** The main HTTP fields are: - `URL` - `Method` - `Allowed Hosts` - `Denied Hosts` - `Require idempotency` - `Idempotency key` It also supports: - `Follow Redirects` - timeout - retries **Security And Host Controls** HTTP Request is safe by default. The node includes allowlist and denylist controls to keep request behavior constrained. Use: - `Allowed Hosts` when you want to restrict the node to a known set of domains - `Denied Hosts` to explicitly block unsafe or disallowed targets **Side Effects And Idempotency** If the request writes data using POST, PUT, or PATCH, you should think carefully about retries and side effects. The idempotency controls exist so write-style requests can be retried more safely when appropriate. **Best Use Cases** Use HTTP Request for: - calling public APIs - fetching external data - sending structured payloads to another service - integrating workflow logic with external systems **Best Practices** - Prefer HTTPS public endpoints. - Restrict hosts when possible. - Treat writes carefully. - Be explicit about whether the request should be retry-safe. ### JSON Parse JSON Parse converts a JSON string into a structured object. ```docsgraph json-parse ``` **What It Does** It takes a string that contains JSON and parses it into a usable object for downstream steps. This is useful when an upstream node returns JSON-looking text that needs to become structured workflow data. **Ports** - one input port: `JSON String` - one output port: `Parsed Object` **Inspector Fields** JSON Parse does not expose node-specific Inspector fields. Its behavior is driven by the connected input. **Best Use Cases** Use JSON Parse when: - an LLM returns structured JSON text - an HTTP response includes JSON as a string - you need structured downstream access after a text step **Best Practices** - Only use it when the upstream content is valid JSON text. - Pair it with prompts that explicitly return machine-readable JSON. ### Condition Condition is the branching node in Workflow Studio. ```docsgraph condition ``` **What It Does** It evaluates incoming data and sends the workflow down either the true branch or the false branch. Unlike a plain static comparator, this node can use a human-language condition description alongside its operator logic, making it useful for creator-friendly branching. **Ports** - one input port: `Value` - one output port: `True Branch` - one output port: `False Branch` Only one branch continues execution after the condition resolves. **Inspector Fields** The main condition fields are: - `Condition (Human Language)` - `Condition Type` - `Compare Value` **Condition Types** Supported condition types include: - Truthy - Falsy - Equals - Not Equals - Greater Than - Less Than `Compare Value` is required for comparison-based operators such as equals and greater than. **How To Think About It** Use the operator for the hard evaluation shape and use the human-language condition to add creator-friendly intent. Example: - operator: `truthy` - human condition: `The answer clearly confirms the user wants to proceed` **Best Use Cases** Use Condition for: - true/false workflow branches - gatekeeping a downstream step - skipping a branch when input fails a rule **Best Practices** - Keep the branch meaning obvious on the canvas. - Use the simplest operator that fits the job. - Only use human-language conditions when they improve clarity. ### Delay Delay pauses the workflow before passing data onward. ```docsgraph delay ``` **What It Does** It waits for a specified duration and then continues execution. The node does not transform the data. It changes timing. **Ports** - one input port: `Input` - one output port: `Output` Whatever goes in is passed forward after the delay finishes. **Inspector Fields** The main delay field is: - `Duration (ms)` This value is measured in milliseconds. **Best Use Cases** Use Delay for: - pacing a workflow - spacing steps apart - waiting before a follow-up request **Best Practices** - Keep delays intentional. - Do not use Delay to hide unclear logic. - Document why the pause exists if it matters to the workflow outcome. ### Loop Loop iterates over an array and emits each item one by one. ```docsgraph loop ``` **What It Does** It takes an array input and exposes the current item and current index for each iteration. This is useful when the workflow must repeat the same downstream logic across a list. **Ports** - one input port: `Array` - one output port: `Current Item` - one output port: `Current Index` The upstream input must be an array. If it is not, the loop will not behave as intended. **Inspector Fields** The main loop field is: - `Max Iterations` This protects the workflow from runaway loops. **Best Use Cases** Use Loop for: - processing lists of items - repeating an enrichment step - applying the same logic across many entries **Best Practices** - Make sure the upstream node really outputs an array. - Set a sane max iteration limit. - Keep the loop body simple and predictable. ## Runs and testing A workflow is ready when it behaves well on real input, not on one lucky run. Use customer view when you can. It shows the product experience, not just the builder layout. Test short and long inputs. Confirm the model matches the job and required keys are connected. Publish after repeated, understandable success, not a single good output. ## Publishing Publish when the outcome, inputs, and output are all obvious. Choose a title that names the result. Write a one-sentence promise in plain language. Set pricing that matches the value and read [Publish and Price](/docs/billing/publish-and-price) if you sell per-run access. If buyers need their own provider keys, say so. If runs are fully hosted on Edgaze, say that too. ## Good habits - Start with the smallest graph that proves the idea. - Use templates for speed, then edit in Workflow Studio. - Keep input questions human and prompts specific. - Use merge nodes on purpose, not as a junk drawer. - Read the canvas left to right before you ship. If the graph needs a long explanation, simplify the product before you publish. ## What to read next - [Templates](/docs/builder/templates) - [API Vault](/docs/builder/api-vault) - [Prompt Studio](/docs/builder/prompt-studio) - [Billing guides](/docs/billing)