Workflow Review — User Guide
Accessing the Review
The workflow review is located in the Deployment section of your thunk, under the Review tab.
Open your thunk and navigate to the Deployment section in the left navigation
Select the Review tab
Click New Design Review
The review runs in the background. You'll see a progress indicator showing which step is currently being reviewed. When complete, the report appears on the same page.
Each review is kept — previous reviews stay in the list on the left, and the most recent one is shown automatically. You can run a new review at any time to get an updated assessment after making changes to your workflow.
Running a review needs the Owner or Admin role on the thunk. Anyone who can open the Deployment section can read past reviews.
What the Review Does
The workflow review analyzes your workflow's configuration and step instructions to surface potential reliability issues. It checks properties, tools, step bindings, instruction quality, and environment configuration — providing feedback intended to help you build more reliable workflows.
The review is advisory. It highlights areas that may need attention, but not every finding requires action. Some findings are hard failures (a required connection is missing), while others are softer guidance (instruction style could be clearer). Use your judgment about which findings to act on.
When to run a review:
After initial workflow setup, before going to production
After significant changes to step instructions, property bindings, or connection configuration
When troubleshooting unexpected workflow behavior
As a periodic health check on production workflows
Acting on a Finding
Every finding in the report has a Fix it button beside it. For findings that are purely informational the button reads Why? instead, because there is nothing to fix. Either way it opens a panel that answers the three questions a finding raises:
What the review found — the finding in full.
Why it matters — what the check is looking for, and what goes wrong when it is not met. Not every finding is worth acting on; this is what lets you decide.
How to fix it — the specific change to make. Where the fix is purely mechanical, a button applies it for you. Otherwise this tells you exactly what to change yourself.
The panel also links straight to the property, step, or tool the finding is about, and to further reading on this help site.
Two fixes can be applied for you today:
Unused property — deletes a property that no step reads or writes. This cannot be undone from the panel, so it asks you to confirm. It is also unavailable when your workflow has changed since the review ran: run a new review first, so you are acting on current information.
Retry safety — turns off retry on error for a step whose work is visible outside the workflow, such as sending a message. This is reversible from the step's own settings.
Applying a fix changes your workflow but does not change the saved report. Run a new review when you want the report to reflect what you have fixed.
If you do not have the Owner or Admin role on the thunk you will still see the explanation and the advice — you just cannot apply a fix from here.
Understanding the Report
The report opens with an overall PASS or FAIL and a count of what was found. Below that, findings are grouped into three sections, most urgent first:
Critical — real problems that should be resolved before the workflow carries production work. Any critical finding fails the review.
Advisory — worth fixing, but not blocking.
Info — things to be aware of, such as a step that waits for a person. Nothing to act on.
Within each section, findings are grouped by the check that produced them, so several properties with the same problem read as one item rather than several. Critical is expanded by default; open the others when you want them.
You can download the whole report as a Word document from the top of the report, which includes the explanation and the suggested fix for every finding — useful for sharing with people who do not work in the product day to day.
The rest of this section explains what each check is looking for. The Fix it panel gives you the same explanation for whichever finding you are looking at.
Environment
Checks your thunk's operational environment configuration.
Resource environment — Production workflows should use a shared environment rather than a Personal environment. A Personal environment depends on one person's connections (OAuth tokens, API keys), which creates a single point of failure.
Admin coverage — Production workflows should have at least 2 people with admin or owner access. This ensures someone can manage the workflow if the primary admin is unavailable.
Status Transitions
Checks that your workflow steps' status transitions follow the correct order defined by the Status property's enum values. Each step transitions from an initial status to a final status, and these should form a consistent chain matching the Status property's value order.
If this check fails, the findings will indicate which steps have status transitions that don't follow the expected order. Status transition issues may require assistance from a member of the Thunk team to resolve, as they can involve constraints in the workflow orchestration system.
Properties
Each property you have defined in your workflow's data schema is checked in three ways:
Description Present — Every property should have a description so the AI agent understands its purpose. Properties without descriptions force the agent to guess from the name alone, which is unreliable.
Type Match — The property's description should be consistent with its configured data type. For example, a property described as "a link to the company website" should not be configured as a Text type when the dedicated URL type exists. If the description implies a list of values but the property is not configured as a list type, this will also be noted.
Used by a Step — Every property should be read or written by at least one step. A property no step uses is either left over from an earlier design and can be removed, or a step that should be using it is missing the binding.
Each finding names the property it is about and links to it in the planning view.
Tools
Reviews the tools available to your workflow's AI agent. Only user-defined tools are included — custom tools, MCP server tools, Generic API tools, and imported thunk tools. Platform-provided tools are excluded since their implementation cannot be modified.
Two checks are performed on each tool:
Strict Schema — Tools with strict schemas constrain the AI agent to produce well-formed arguments, improving reliability. Non-strict tools allow the agent to pass under-constrained arguments, which can cause errors.
Naming — Tool function names should follow snake_case convention (lowercase letters, digits, and underscores). Non-standard naming can reduce reliability because LLM function-calling is optimized for snake_case names.
Steps
Each workflow step is reviewed across several dimensions below. Findings name the step they are about and link straight to it in the planning view.
Human-in-the-loop
Reports whether the step requires human intervention — through approval gates, manual assignment, manual start, or tools that need approval. This is informational, not a pass/fail check.
Scheduled
Reports whether the step has a recurring schedule configured. This is informational.
Detected Intents
Shows what the review system detected the step is doing based on its instructions. A step may have multiple intents, a single intent, or none. Possible intents include:
SendMessage — The step sends a message to an external party via a communication channel (email, chat, or conversation property)
ReceiveMessage — The step receives or waits for a response from an external party via a communication channel
ReadFromStorage — The step accesses a file from an external storage system (Google Drive, OneDrive, SharePoint)
WriteToStorage — The step uploads or creates a file in an external storage system
WebSearch — The step searches the web for information
The current set of detected intents is limited but will grow in future updates to cover more workflow patterns. These intents drive the Tool Configuration checks below.
Bindings
Checks whether the step's input and output property bindings are justified by its instructions. The review classifies the connection between each bound property and the step's instructions into one of six evidence types:
name — The property name appears literally in the step instructions (case-insensitive, flexible whitespace, hyphen-insensitive). For example, "Contact Email" matches "contact email" or "ContactEmail"; "Move-In Checklist" matches "move-in checklist" or "move in checklist". This is the strongest evidence and is determined programmatically before the LLM is consulted.
description — The step instructions closely match the property's description, but the property is not mentioned by name. For example, instructions that say "update the qualification status" match a property described as "Whether the lead is qualified."
entity-reference — The property name combines an entity with an identifier suffix (e.g. "Company Name", "Document Title", "Order ID") and the step instructions reference that entity (e.g. "the company", "the document", "the order") without using the full property name. The property is needed to identify the entity being discussed.
implicit — The step instructions imply the use of this property, but connecting them requires at least one reasoning step beyond direct name, description, or entity-reference matching.
satisfies step intent — The property is not referenced in the step instructions, but it satisfies a detected step intent. For example, a Conversation property bound as output satisfies the SendMessage intent even if the instructions don't mention the conversation property by name.
not justified — No connection found between the property and the step instructions, and the property does not satisfy any detected intent. These bindings are flagged as potentially unnecessary.
Only bindings the review could not connect to anything are reported, and each one names the property and its direction (input or output). A binding that is not reported was justified by one of the connections above.
Note that the accuracy of this check depends on the clarity of your step instructions. Vague or ambiguous instructions may result in false positives — a property binding flagged as unnecessary when it is actually needed. If you see a binding finding that you believe is incorrect, consider whether the language in the step instructions pertaining to that property could be made clearer. Using the exact property name in your instructions is the most reliable way to ensure the connection is recognized. A false positive is often an opportunity to improve the step's instructions so the agent (and the review) can better understand the relationship between the instructions and the bound properties.
Extra Properties
Flags any step that uses the "Extra Properties" catch-all property in its input or output bindings. Extra Properties is a fallback for data that doesn't have its own explicit property — its use suggests the data model should be refined with dedicated properties.
Data flow
Checks that every input property is available when the step runs. An input property must be either a workflow input (provided at the start) or an output of an earlier step. If a step tries to read a property that no prior step has produced, the data won't be there.
There are exceptions to this rule. For example, if a step is scheduled (runs on a recurring timer), it may legitimately read a property that it also writes — each scheduled execution reads the value from the previous run and updates it. The review accounts for this case and will not flag scheduled steps that use the same property as both input and output.
Retry safety
Checks whether automatic retry is safe for this step. Steps that send messages or write to external storage have side effects that would be duplicated on retry (sending the same email twice, creating duplicate files). If retry-on-error is enabled on such a step, this check flags it.
Tool Configuration
Checks whether the step has the connections it needs to do what its instructions describe. This is driven by the detected intents:
Intent requirements — For each detected intent, shows whether it is satisfied. For example, a step with the WriteToStorage intent needs a file storage connection (Google Drive, OneDrive, etc.) to be enabled.
Enabled Connections — For each enabled connection, shows which intent motivates it. Connections with no motivating intent may be unnecessary.
Target platform
Checks whether step instructions reference a specific cloud platform (by URL) that isn't enabled. For example, if instructions contain a Google Drive URL but only OneDrive is configured, this check flags the mismatch.
Instruction quality
Checks the style and structure of step instructions against best practices:
Sequential work — When a step involves multiple activities, they should be structured as numbered sections with descriptive titles, not written as unstructured prose.
Conditional clarity — Conditional logic should place the condition (antecedent) before the action (consequent). Patterns like "Only do X for Y" or "Do X when Y" place the action first, making it harder for the agent to follow.
Timeout handling — If instructions include timeout-related language, it should use a clear conditional pattern like "If you run out of time, finish the step and move on." Vague time pressure language ("try to finish quickly") is not actionable.