> ## Documentation Index > Fetch the complete documentation index at: https://help.pipelime.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workflow troubleshooting > A block that is missing, a workflow that will not activate, a lead that has not moved: what each one actually means. export const UiPath = ({children}) => { const parts = String(children).split(/\s*(?:→|>)\s*/).filter(Boolean); return {parts.map((part, index) => {index > 0 && →} {part} )} ; }; export const Screenshot = ({id, alt, caption, frame = 'browser', url, marks = [], lang = 'en', workspace = 'northwind-outbound'}) => { const src = `/images/screenshots/${lang}/${id}.png`; const chrome = url ? `app.pipelime.ai/${workspace}${url}` : 'app.pipelime.ai'; return

; }; Three things send someone to this page: a block that will not show up in the block list, a workflow that refuses to activate, and a lead that looks stuck partway through one. Each has a specific, checkable cause.

Where

Outreach→Workflows

Your role needs

Read access to Workflows read-workflows. Admin, Member and Viewer have it by default.

To create or change

create-workflows to add one, update-workflows to change one, on top of the permission above.

If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.

## A block will not show up in the Blocks panel Open a workflow, or start a new one from Outreach → Workflows. The **Blocks** panel floats over the left edge of the canvas, always on screen, never behind a tab. Rule out the cheap causes first: the panel has a search box, and every category header collapses when you click it, so a block can be one stale keystroke or one closed heading away. Past that, the panel only ever shows a block in one of two states: usable, or dimmed with a small badge naming what it needs. A block that is neither is not on the list at all, and telling the cases apart matters, because only one of them is something you can fix yourself. *Not connected.* The block is right there, dimmed, with a badge on its name (1), for example **Notify on Slack** or **Send to CRM**, both waiting on a connection this workspace has not made yet. Connect that integration, then reopen the workflow and the block lights up like any other, ready to drag onto the canvas. Not every block needs one: **Send Webhook** (2) sits in the very same list and is never dimmed, because a one-off URL needs no connection at all. *Not built yet.* The block is nowhere on the list, dimmed or otherwise. A few blocks exist in the catalog with the wiring still missing, and the panel drops them rather than letting you place something that would only be rejected later. **Facebook Message Received** is one of these. There is nothing waiting on a connection and nothing to switch on. *Not supported by the engine yet.* Also invisible, for a second reason: the engine publishes its own list of block types it can currently run, and the panel only ever offers what is on that list, specifically so you cannot build a workflow the engine would then refuse. **Email Opened** and **Link Clicked** are two of the blocks held back this way. Nothing on your side unlocks them, and nothing on your side has to: the panel asks the engine for that list each time it loads, so a block turns up as soon as the engine can run it. ## The workflow refuses to activate The toolbar carries a validation pill that reads **Valid** while the graph is clean and counts the errors and warnings when it is not. Click it to open the validation panel, in the bottom-right corner of the canvas, which lists each one and jumps to the block it belongs to. Errors and warnings are not the same thing. While one error is unresolved, the **Activate** button is greyed out and its tooltip reads "Fix errors before activating". Warnings never block anything. If **Activate** and **Save** are both greyed out while the pill says **Valid**, this is not the graph. Changing a workflow needs the `update-workflows` permission, and without it both controls render inert with a tooltip that says so. A few of the errors you are most likely to hit: * A graph with blocks in it but every trigger deleted: "Add at least one Trigger or Start node so the workflow has an entry point." * A send or AI block left with nothing to generate or say: "Add a message — this block has nothing to send." * A loop with no way to stop: "This loop never exits — add a Loop block with a max count (or a wait) so it can end." * LinkedIn steps placed out of order. Two rules are enforced as errors. **LinkedIn: Message** and **LinkedIn: Engage with post** need proof upstream that the invite was accepted, which means either a **LinkedIn Invite Accepted** trigger, or a **Wait for Reply** step whose "Wait for" is set to "LinkedIn invite accepted" and which itself sits after a **LinkedIn: Connect**. Separately, **LinkedIn: Connect** wants a **LinkedIn: View Profile** ahead of it. Warnings are softer: a block sitting on the canvas connected to nothing, a branch on a decision block with nowhere to go, a loop that circles back on itself, an email send in a workspace with no email account connected yet. None of these stop activation on their own, and all of them are easy to miss. There is a second check underneath all of this. Pressing **Activate** re-validates the graph on the server, independently of whatever the browser already found. They mostly test the same rules, and two known gaps let the browser call a graph clean that the server then refuses: * A completely empty canvas. The browser only asks for a trigger once there is at least one block on the canvas, so an empty workflow reads as valid; the server rejects it outright. * A trigger with nothing wired to its output. The browser does not flag a trigger that leads nowhere; the server requires every trigger to have an outgoing connection. When the server refuses inside the builder, the validation panel does not reopen with the reason. You get a generic "Could not save workflow" message instead. Treat that message, arriving straight after a **Valid** pill, as one of the two cases above rather than a fluke. ## A lead is not moving through a workflow Open the lead's own page, which needs the `read-leads` permission, separate from the one that opens Workflows, and look for the **Automations** card. Every workflow the lead is enrolled in, or was, is listed here. The first live enrollment opens on arrival; the rest, and everything already finished, sit collapsed behind a History toggle. Open one and its journey shows every step already taken, the step it is on right now, and what can come next. Every enrollment sits in one of six statuses: * **Active**: running right now. * **Waiting**: paused at a timer, an event, or something else that has to happen first. * **Completed**: reached the end of the graph. * **Exited**: left the workflow on its own, part way through, down a branch built for exactly that. * **Failed**: a step could not be made to work, and the run gave up. * **Cancelled**: someone stopped it by hand. **Waiting** is the status behind almost every lead that looks stuck, and most of the time nothing is actually wrong. A **Waiting** run's journey tells you when it expects to resume, or that it is waiting for the lead to respond. It does not tell you which of the reasons below is holding it: the engine records that reason on the step, and the API strips it before the screen ever sees it. For the three blocks that send email (**Send Email**, **Send Follow-up**, **Send Reply**) it is usually one of two. Each of them resolves an email account before it writes anything, and when the account it would use is not free, it waits and checks again rather than failing outright: * Nothing is free at the moment, because every account it may use is paused, in error, outside its sending window, at its daily limit, or too soon after its last send. It waits and re-checks on a randomized interval rather than a fixed clock, so the pattern does not read as automated. * The account is deliberately resting today, or the lead's own country is on a national holiday. It holds until the next morning instead. A reply is exempt from both: a lead who wrote in gets an answer regardless of the day. Neither wait goes on forever. Each counts its own re-checks and stops at a ceiling. What surprises people is the status that leaves behind: the run ends **Completed**, not **Failed**. Nothing threw an error, the send simply never found a window, so the journey closes on its normal end marker. A **Completed** run whose journey shows no message actually going out is usually this. A **Failed** run means something else: a step's own logic threw an error, most often something transient like a provider hiccup. The engine retries that same step automatically, up to 3 times, waiting longer before each attempt, and stops the run for good once the retries are spent. **AI Generate Content** is one example: when the model comes back with nothing to write, the block raises a retryable error and rides exactly this schedule rather than failing on the first miss. Every attempt writes its own line in the journey, in red (1), with the error text from that attempt underneath it. Not every failure retries first. Some are fatal by design and stop the run on its very first attempt, with no backoff and no second line in the journey. A **Send Email** sending a template whose rendered body comes out empty is one of them. ## Related Read the validation panel itself and turn a finished workflow on. Every reason a send waits, and how long the engine keeps trying before it gives up. What one lead's run through a workflow actually is, and how to read its journey. The same "why isn't this sending" question, one level up, for an AI agent's own channel.